Date:        Tue, 15 Sep 2020 15:37:31 +0200
    From:        Steffen Nurpmeso <stef...@sdaoden.eu>
    Message-ID:  <20200915133731.cpghp%stef...@sdaoden.eu>

Quoting RFC822:
  |  the presence of the  "Reply-to"  field  SUPERSEDES the sending
  | of a reply to the person named in the "From" field.

I suspect that this is where the "reply-to is a replacement for From"
idea originated - it kind of reads like that, but that is never what
it meant.   All that was saying is that when there is a Reply-To the
>From field is not (by default anyway) used in the reply.  It just doesn't
explicitly say that the Reply-To contents are supposed to be the entire list
of addresses to use for the reply, but that is the only thing that really
makes sense (the author can add as many addresses as they want to the
Reply-To, if they want addresses from the To or Cc added, they can be
included - but if the replier includes all those addresses automatically,
there's no way left for the author in the header to say not to do that.

  | makes me realize that the BSD Mail codebase and my fork still do not
  | support the group address list syntax shown here.

This is one I wouldn't lose any sleep over, while useful sometimes,
its use normally appears when the addresses in the group are elided,
so what the recipient receives is something like

        To: The Committee: ;

in which case there is simply nothing to use.   Using the group syntax
when the addresses are listed adds very little of any value, so in practice
no-one ever does that.   (It has always been supported in MH though).

In any case, this isn't something that we need be concerned with here.


  | So this is why DMARC and the way mailman deals with the things
  | destroy the infrastructure,

Agreed.

  | and this is why i hate them.  Why not, let's just hate them,

I'd also ignore them - that is, simply refuse to pander to that nonsense.
Anyone who wants to participate ought to be able to find a rational e-mail
system to use.

kre


              • ... 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
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to