Subject: Bug (ID 3X126): REPOST: From: header not well generated by Pine 3.91

From: Gildas PERROT <[email-masked]>
Date: Wed, 30 Aug 1995 14:52:06 -0400 (EDT)

Hi,

I am using Pine 3.91 since 1 year and I still have a problem I can
solve. It's about 'From:' field in outgoing mail. This one contains
the hostname of my mail exchanger, 'Pinuche' :
[email-masked]. I would like to get just the domainame
: [email-masked]. I have correctly configured my sendmail.cf on
my hosts in order to remove hostname from 'From:' when using 'mail' or
'Mail' but with pine, I still have this problem. However, I have the
lines in pine.conf :

user-domain=grbb.polymtl.ca
use-only-domain-name=no

I tried to use :
user-domain=
use-only-domain-name=yes 

but with no more success. I checked that my .pinerc doesn't have
another configuration.

I ask SGI technical support, and they also receive my email with a
wrong "From:" header. They said that 'From:' is generated by 'pine'
and not by 'sendmail'. They suggested me to force pine not to generate
the 'From:' or to force pine to generate a 'From:' header with
username and domainame by modifying the sources. 

Any idea how to do that ?				 Gildas.

# Gildas PERROT, Associe de recherche # Ecole Polytechnique          
# Institut de Genie Biomedical        # C.P. 6079, Succ. Centre-Ville    __o
# e-mail: [email-masked]      # Montreal H3C3A7, Canada   -----_ \<,_
# Tel: (514) 340-4184, local:A630.5.5 # Fax: (514) 340-4611    ------ (_)/ (_)

# Gildas PERROT, http://www.grbb.polymtl.ca/~perrot/gildas.html
# Ecole Polytechnique, Genie Biomedical # C.P. 6079, Succ. Centre-Ville   __o
# e-mail: [email-masked]        # Montreal H3C3A7, Canada  -----_ \<,_
# Tel: (514) 340-4184, local:A630.5.5   # Fax: (514) 340-4611   ------ (_)/ (_)
========== struct pine * ==========
ui:	login = perrot, full = Gildas PERROT
	home = /Berthy/people/perrot
home_dir=	/Berthy/people/perrot
hostname=	Berthy.grbb.polymtl.ca
localdom=	grbb.polymtl.ca
userdom=	grbb.polymtl.ca
maildom=	grbb.polymtl.ca
cur_cntxt=	/Berthy/people/perrot/Mail/[]
cur_fldr=	INBOX
actual mbox=	/var/mail/perrot
msgmap: tot=2, cur=1, del=1, hid=0, exld=0, slct=0, sort=Arrival
inbox is mail_stream
term type=xterm, ttyname=/dev/ttyq2, size=24x80, speed=normal
======= Current_val options set =======
        personal-name : Gildas PERROT
              user-id : perrot
          user-domain : grbb.polymtl.ca
          nntp-server : news.polymtl.ca
           inbox-path : /var/mail/perrot
   folder-collections : /Berthy/people/perrot/Mail/[]
     news-collections : *{news.polymtl.ca/nntp}[]
          default-fcc : ""
     postponed-folder : /Berthy/people/perrot/POST
       mail-directory : mail
  read-message-folder : /Berthy/people/perrot/Mail/RECEIVED
       signature-file : /Berthy/people/perrot/.signature
  global-address-book : /disk3/lib/addressbook
         address-book : .addressbook
         feature-list : enable-alternate-editor-cmd
                      : expanded-view-of-folders
                      : expanded-view-of-addressbooks
                      : enable-tab-completion
                      : save-will-advance
                      : delete-skips-deleted
                      : enable-mail-check-cue
                      : enable-bounce-cmd
                      : enable-jump-shortcut
                      : enable-alternate-editor-implicitly
                      : compose-sets-newsgroup-without-confirm
                      : delete-skips-deleted
                      : enable-full-header-cmd
                      : enable-mail-check-cue
                      : enable-tab-completion
                      : expanded-view-of-addressbooks
                      : expanded-view-of-folders
                      : save-will-advance
                      : enable-bounce-cmd
                      : enable-flag-cmd
                      : enable-jump-shortcut
                      : enable-unix-pipe-cmd
                      : news-post-without-validation
  saved-msg-name-rule : by-sender
        fcc-name-rule : default-fcc
             sort-key : arrival
   addrbook-sort-rule : fullname-with-lists-last
        character-set : ISO-8859-1
               editor : /disk3/system/shell/emnw
         image-viewer : /disk3/bin/xv
 use-only-domain-name : no
              printer : recode Latin-1:flat | lp -depson
 personal-print-comma : recode Latin-1:flat | lp -depson
     standard-printer : lp
 last-time-prune-ques : 95.8
    last-version-used : 3.91
        bugs-fullname : Pine Developers
         bugs-address : [email-masked]
       elm-style-save : no
      header-in-reply : no
        feature-level : sapling
      old-style-reply : no
       save-by-sender : no
======= Command_line_val options set =======
======= User_val options set (/Berthy/people/perrot/.pinerc) =======
          user-domain : grbb.polymtl.ca
         feature-list : enable-alternate-editor-implicitly
                      : compose-sets-newsgroup-without-confirm
                      : delete-skips-deleted
                      : enable-full-header-cmd
                      : enable-mail-check-cue
                      : enable-tab-completion
                      : expanded-view-of-addressbooks
                      : expanded-view-of-folders
                      : save-will-advance
                      : enable-bounce-cmd
                      : enable-flag-cmd
                      : enable-jump-shortcut
                      : enable-unix-pipe-cmd
                      : news-post-without-validation
               editor : /disk3/system/shell/emnw
 use-only-domain-name : no
              printer : recode Latin-1:flat | lp -depson
 personal-print-comma : recode Latin-1:flat | lp -depson
 last-time-prune-ques : 95.8
    last-version-used : 3.91
======= Global_val options set (/usr/local/lib/pine.conf) =======
          user-domain : grbb.polymtl.ca
          nntp-server : news.polymtl.ca
           inbox-path : /var/mail/$USER
   folder-collections : ~/Mail/[]
          default-fcc : ""
     postponed-folder : ~/POST
       mail-directory : mail
  read-message-folder : ~/Mail/RECEIVED
       signature-file : ~/.signature
  global-address-book : /disk3/lib/addressbook
         address-book : .addressbook
         feature-list : enable-alternate-editor-cmd
                      : expanded-view-of-folders
                      : expanded-view-of-addressbooks
                      : enable-tab-completion
                      : save-will-advance
                      : delete-skips-deleted
                      : enable-mail-check-cue
                      : enable-bounce-cmd
                      : enable-jump-shortcut
  saved-msg-name-rule : by-sender
        fcc-name-rule : default-fcc
             sort-key : arrival
   addrbook-sort-rule : fullname-with-lists-last
        character-set : ISO-8859-1
               editor : /disk3/bin/emacs
         image-viewer : /disk3/bin/xv
 use-only-domain-name : no
              printer : lp -depson
 personal-print-comma : lp -depson
     standard-printer : lp
        bugs-fullname : Pine Developers
         bugs-address : [email-masked]
       elm-style-save : no
      header-in-reply : no
        feature-level : sapling
      old-style-reply : no
       save-by-sender : no
======= Fixed_val options set (NO pine.conf.fixed) =======
========== Feature settings ==========
  no-assume-slow-link
  no-auto-move-read-msgs
  no-auto-open-next-unread
  no-compose-rejects-unqualified-addrs
     compose-sets-newsgroup-without-confirm
     delete-skips-deleted
  no-disable-config-cmd
  no-disable-keyboard-lock-cmd
  no-disable-password-cmd
  no-disable-update-cmd
  no-enable-aggregate-command-set
     enable-alternate-editor-cmd
     enable-alternate-editor-implicitly
     enable-bounce-cmd
     enable-flag-cmd
     enable-full-header-cmd
  no-enable-incoming-folders
     enable-jump-shortcut
     enable-mail-check-cue
  no-enable-suspend
     enable-tab-completion
     enable-unix-pipe-cmd
     expanded-view-of-addressbooks
     expanded-view-of-folders
  no-expunge-without-confirm
  no-include-attachments-in-reply
  no-include-header-in-reply
  no-include-text-in-reply
  no-news-approximates-new-status
     news-post-without-validation
  no-news-read-in-newsrc-order
  no-preserve-start-stop-characters
  no-quell-user-lookup-in-passwd-file
  no-quit-without-confirm
  no-save-will-quote-leading-froms
  no-save-will-not-delete
     save-will-advance
  no-select-without-confirm
  no-show-selected-in-boldface
  no-signature-at-bottom
  no-use-current-dir
  no-use-function-keys

---

From: David L Miller <[email-masked]>
Date: Wed, 30 Aug 1995 12:07:52 -0700 (PDT)

Your message arrived here with the address you want in the From:
header, as shown below.  Either configuration you listed will generate
this address.  I don't know where the header is getting re-written,
but it is leaving Pine correctly.

|\ |  |\/|  David L. Miller    [email-masked]  (206) 685-6240
|/ |_ |  |  Software Engineer, Pine Development Team   (206) 685-4045 (FAX)
University of Washington, Networks & Distributed Computing, JE-20
4545 15th Ave NE, Seattle WA 98105, USA

On Wed, 30 Aug 1995, Gildas PERROT wrote:

> Date: Wed, 30 Aug 1995 14:52:06 -0400 (EDT)
> From: Gildas PERROT <[email-masked]>
> To: Pine Developers <[email-masked]>, [email-masked],
>     [email-masked]
> Subject: Bug (ID 3X126): REPOST: From: header not well generated by Pine 3.91
>
> Hi,
>

---

From: Gildas PERROT <[email-masked]>
Date: Wed, 30 Aug 1995 15:20:26 -0400 (EDT)

Hi,

No. Pine is defining the 'From:' header with 'Pinuche' in it and I
don't want this. As I said, SGI tech support and my recipient (my
account in another university) are receiving a 'From:' header with
'Pinuche' in it. As far as I know, you are really the only one
receiving my 'From:' header correctly.  Furthermore, 'Mail' utility
which uses 'sendmail' to generate 'From:' header doesn't create this
problem. Finally, SGI tech support said me that they could see by the
position of the wrong 'From:' header (I think they received my email
with 2 'From:' headers) that this one was created by Pine.

Maybe the best thing is to not define 'From:' in Pine and leave
sendmail doing that. Do you know how to modify sources to do that ?

Thanks in advance.				  Gildas.

---

From: Michael Joswig <[email-masked]>
Date: Wed, 30 Aug 1995 21:59:19 +0200 (MET DST)

Gildas,

wy don't you try to use "Reply-To: <address>" in the "Customized-hdrs"? That will workaround 
the problem.

Ciao,
 Michael Joswig

> > > # Tel: (514) 340-4184, local:A630.5.5   # Fax: (514) 340-4611   ------ (_)/ (_)

================================================================
Michael J. Joswig              [email-masked]

---

From: Gildas PERROT <[email-masked]>
Date: Wed, 30 Aug 1995 16:09:28 -0400 (EDT)

Hi and thanks for your answer. I don't need "Reply-To: <address>" to
workaround the problem since even if the email address contains a
hostname in it, email arrives to the right place. However, I don't
want to see a hostname in my "From:" header.

Gildas.

---

From: Terry Gray <[email-masked]>
Date: Wed, 30 Aug 1995 14:17:41 -0700 (PDT)

Gildas,
My goodness, you do seem sure of yourself!  But I'm equally sure that you
are wrong: you have not substantiated the claim that "Pine is defining the
'From:' header with 'Pinuche' in it"

I say that because in previous correspondence with us you've confirmed
that the messages Pine stores in your sentmail folder have the *correct*
From: address.  This means that the problem is not in Pine, but outside.

Also, it is a fact that Pine does not send a different From: to different
recipients, so if some recipients are seeing one From: address and others
are seeing another, it is guaranteed that some software outside of Pine is
modifying the header in one of those cases.

The fact that messages from "mail" do not exhibit the problem is a
red-herring, since "mail" relies on sendmail to create the From: line,
and the fact that sendmail creates From: lines as you want them says
nothing about what it does with pre-existing From: lines.

I guess you believe that the messages we see here in Seattle with the
correct From: address are somehow modified by our own sendmail to make
them look correct?  Alas, for as long as you believe the SGI tech support
person, you will be on an endless quest.

-teg

---

From: Gildas PERROT <[email-masked]>
Date: Wed, 30 Aug 1995 17:28:38 -0400 (EDT)

OK, OK. I believe you Terry ;-)

Seriously, why don't force pine to not generate the From: header and
leave sendmail doing the job since it seems to do it correctly for
Mail ?

Gildas.

---

From: Terry Gray <[email-masked]>
Date: Wed, 30 Aug 1995 14:35:07 -0700 (PDT)

Because it is entirely correct for the MUA to create the From: header, and
it is entirely incorrect for the MTA to change it!   (And I can assure you
that there are lots of places where the sendmail config would *not* put in
the correct From: address!)

-teg

---

From: Rahul Dhesi <[email-masked]>
Date: 30 Aug 1995 23:07:40 GMT

In <l-o-ooo-ng-message-id> [email-masked] (Terry Gray) writes:

>it is entirely incorrect for the MTA to change it! 

Correctness is a very dangerous goal to pursue.  Correctness is not a
well-defined property for such things as mail user agents (MUAs).
Unlike mathematics, where we can claim that a proof is 'correct', we
cannot in general make such an assertion for MUAs.

Rather than asking "Is it correct?" for mail software, we should ask,
"Does it work?"  The latter is an answerable question.  The former is
meaningless for most mail software and leads to nothing but flame
wars.

Those who are thinking of RFC-conformance are advised to ask "Does it
conform to RFC-xxx?" rather than "Is it correct?"  The former is an
answerable question.  The latter, as emphasized above, leads to nothing
but flame wars.

Here are two common ways of defining correctness for an MUA.

1. An MUA is 'correct' if it works as expected in its intended environment.
2. An MUA is 'correct' if it behaves in accordance with RFCs chosen as
   applicable by the software developer.

People who use the concept of 'correctness' for mail software seldom
specify which definition of correctness they are using.  Thus we have
arguments at cross-purposes between users (who normally use definition
1) and software developers (who often use definition 2).

It might not be easy to satisfiy both criteria at the same time, but
one should certainly try.  Attempting to satisfy only one of these two
defnitions of correctness while ignoring the other is probably unwise.

Going back to the quoted text:

>it is entirely incorrect for the MTA to change it! 

The RFC I am thinking of -- RFC822 -- does not separately talk about
the MUA and MTA.  The dividing line between MUA and MTA varies in
different environments.  No RFC can safely make any assumption about
where this dividing line lies.  Let's see what RFC822 says:

     4.4.1.  FROM / RESENT-FROM

        This field contains the identity of the person(s)  who  wished
        this  message to be sent.  The message-creation process should
        default this field  to  be  a  single,  authenticated  machine
        address,  indicating  the  AGENT  (person,  system or process)
        entering the message.  If this is not done, the "Sender" field
        MUST  be  present.  If the "From" field IS defaulted this way,
        the "Sender" field is  optional...

RFC822 is vague about who creates the From: field.  It talks about 'The
message-creation process'.

It is quite permissible and possible for the MTA to play the rule of
MUA, as in the following command given at the UNIX shell prompt:

     % sendmail [email-masked]
     please ignore Dhesi
     ^D

The above violates no RFC, because no RFC tells us what the MUA, or
MTA, or MUA+MTA combination, looks like.  All we can say is that
*before* the message is transported, the From: field 'should' exist,
and that if the From: field does not exist, then Sender: must exist.

So, I would rephrase the quoted text as:

   1. It is entirely correct for the MUA and initial MTA, acting as a
      cooperating entities, to create the From: header.  As a corollary,
      it is entirely correct for the MUA to create a From: header and
      for the initial MTA to change it, provided both entities act in
      cooperation and the final result is usable for replies in
      accordance with RFC822.

   2. It is entirely correct for the MUA to create the From: header if it
      is the intention of the administrators of the specific environment
      that the MUA do so or be permitted to do so.

   3. It is entirely incorrect for an MUA to create a From: header if it
      is the intention of the administrators of the specific environment
      that the initial MTA do so and not the MUA.

>...there are lots of places where the sendmail config would *not* put in

There are probably very few such places, but I'm sure there are some.
They would correspond to item 2 above.

It would be unwise to assume that all 'places' correspond to item 2.
-- 
Rahul Dhesi <[email-masked]>
"please ignore Dhesi" -- Mark Crispin <[email-masked]>