Robert Elz wrote in
 <21450.1600163...@jinx.noi.kre.to>:
 |    Date:        Mon, 14 Sep 2020 23:09:21 +0200
 |    From:        "Steffen Nurpmeso via austin-group-l at The Open Group" \
 |    <austin-group-l@opengroup.org>
 |    Message-ID:  <20200914210921.h1m8r%stef...@sdaoden.eu>
 |
 || This is of course very primitive handling and does not take care
 || for RFC 2822, no Sender: handling, etc.
 |
 |That it didn't take 2822 into account, in 199x (for any x) is hardly
 |surprising, as 2822 didn't appear until 2001 (though it was being worked
 |on for a few years before that - not as early as '96 though I don't think).

Yes, of course, Robert.

 |RFC822 was not nearly as clear, and while 2822 wasn't really intended to
 |change anything in this area, just clarify it (unlike other stuff where
 |lots was made obsolete, and a few new things added, to match what people
 |were actually doing with mail at the time) it is understandable that e-mail
 |MUA authors (the very few of them who ever read RFC822, or even knew it
 |existed ... most seemed to code by guesswork) might have not gotten things
 |exactly right.

RFC 822 is one of the wonderful old style RFCs, for example it says

             George Jones logs in as Jones on his  host.   His  secre-
        tary,  who logs in as Secy sends mail for him.  Replies to the
        mail should go to George.

            From:    George Jones <Jones@Group>
            Sender:  Secy@Other-Group

as well as

             George is a member of a committee.  He wishes to have any
        replies to his message go to all committee members.

            From:     George Jones <jo...@host.net>
            Sender:   Jones@Host
            Reply-To: The Committee: jo...@host.net,
                                     sm...@other.org,
                                     Doe@Somewhere-Else;

        Note  that  if  George  had  not  included  himself   in   the
        enumeration  of  The  Committee,  he  would not have gotten an
        implicit reply; the presence of the  "Reply-to"  field  SUPER-
        SEDES the sending of a reply to the person named in the "From"
        field.

which unfortunately contradicts how BSD Mail and Unix mail work on
`reply' time, no, and then makes me realize that the BSD Mail
codebase and my fork still do not support the group address list
syntax shown here.

RFC 5322 which POSIX now mentions says

   [.] The "Sender:" field specifies the
   mailbox of the agent responsible for the actual transmission of the
   message.  For example, if a secretary were to send a message for
   another person, the mailbox of the secretary would appear in the
   "Sender:" field and the mailbox of the actual author would appear in
   the "From:" field.  If the originator of the message can be indicated
   by a single mailbox and the author and transmitter are identical, the
   "Sender:" field SHOULD NOT be used.  Otherwise, both fields SHOULD
   appear.

which is the sucked mellow professional way of saying the same
thing i'd say.

      Note: The transmitter information is always present.  The absence
      of the "Sender:" field is sometimes mistakenly taken to mean that
      the agent responsible for transmission of the message has not been
      specified.  This absence merely means that the transmitter is
      identical to the author and is therefore not redundantly placed
      into the "Sender:" field.

   The originator fields also provide the information required when
   replying to a message.  When the "Reply-To:" field is present, it
   indicates the address(es) to which the author of the message suggests
   that replies be sent.  In the absence of the "Reply-To:" field,
   replies SHOULD by default be sent to the mailbox(es) specified in the
   "From:" field unless otherwise specified by the person composing the
   reply.

   In all cases, the "From:" field SHOULD NOT contain any mailbox that
   does not belong to the author(s) of the message.  See also section
   3.6.3 for more information on forming the destination addresses for a
   reply.

So this is why DMARC and the way mailman deals with the things
destroy the infrastructure, and this is why i hate them.  Why not,
let's just hate them, i do not know what these tanks had in mind,
really.

 |And except in extraordinary circumstances (and Mail having just 2 reply
 |variants doesn't have enough to ever get there) Sender isn't supposed to
 |be used (in almost any way at all) - certainly not in your average reply.

The BSD Mail clone i maintain (mis)uses Sender: by requiring
a *sender* variable to be set when From: (*from*) is set to
multiple addresses, aka by using these message members in the same
way.  I was sure this had historical precedence.

 |A really good MUA might have a "reply to sender" (though it might be
 |phrased differently so people don't just assume "sender" means the address
 |in the From field) as it can occasionally be useful, as in a "Did you \
 |really
 |intend to send that message to me?" reply, which is one kind of reply
 |where sending to the addr in the Sender: field (if there isn't one, From:
 |is used) is appropriate, another might be "you typo'd fred's address, you
 |should send another copy to the correct one" (just in case the bounce
 |message didn't get seen).
 |
 |With all of this we're also ignoring anything that we might want to be
 |able to do with the Resent-* fields, which are also not normally used by
 |typical replies, but sometimes can be the right thing to use.

True.  I do not retain them in the visual message representation
i use, i would suspect graphical MUAs have an easier task with
this, as they could "simply" present all such addresses as
a button or link for reply purposes, 'could even offer some place
to drag+drop (à la trash bin) them in addition for composition of
group replies, which would be begun when pressing the place as
such.

 |But as long as we're confining ourselves to what mailx's 'r' and 'R'
 |commands should do, both Sender and Resent-* are irrelevant.

But .. as above.  Now i lost myself in finding code in Plan9Port
UPAS.  Well.  Mail evolved, and maybe it would be easier to
provide polishing scripts to convert old mails then to have all
the old code in mailx.  Hm, so much to do, and so little time.

 |kre
 |
 |ps: Sorry Steffen, I know you're going to see this twice (or perhaps
 |3 times - but certainly twice) - I forgot this list's obnoxious
 |Reply-To (again!).   This time I still had the draft file when I
 |realised though, so this resend includes the list.

Oh please easy, Robert, thank you, and greetings to Thailand!
Ciao from Hessen/Germany on its last sunny midsummer day,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

            • ... Geoff Clare via austin-group-l at The Open Group
              • ... Steffen Nurpmeso via austin-group-l at The Open Group
            • ... Robert Elz via austin-group-l at The Open Group
              • ... Mark Harris via austin-group-l at The Open Group
              • ... Geoff Clare via austin-group-l at The Open Group
              • ... Steffen Nurpmeso via austin-group-l at The Open Group
              • ... Robert Elz via austin-group-l at The Open Group
              • ... Geoff Clare via austin-group-l at The Open Group
              • ... Steffen Nurpmeso via austin-group-l at The Open Group
              • ... Robert Elz via austin-group-l at The Open Group
              • ... Steffen Nurpmeso via austin-group-l at The Open Group
              • ... Robert Elz via austin-group-l at The Open Group
              • ... Steffen Nurpmeso via austin-group-l at The Open Group
      • Re:... Robert Elz via austin-group-l at The Open Group
        • ... Geoff Clare via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Garrett Wollman via austin-group-l at The Open Group
    • Re: [10... Robert Elz via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to