Date: Fri, 11 Sep 2020 15:59:26 +0100
From: "Geoff Clare via austin-group-l at The Open Group"
<austin-group-l@opengroup.org>
Message-ID: <20200911145926.GA7856@localhost>
| Although Andrew asked us to take this to the offtopic list, I would
| like instead to bring it back on topic, by making it about mailx.
I will reply (mostly) in kind...
| 1. Using "sender" incorrectly implies that if a "Sender:" header field
| is present it should be used instead of "From:".
I would assume that it was using "sender" more generically, rather than
referring to a specific field, but it certainly could be clarified.
| 2. If the person replying is one of the "recipients included in the
| header of the message", this text requires that the reply message is
| sent to them, contradicting text elsewhere which says that this should
| only be done if the metoo variable is set.
That should be fixed. Probably by something like "Whether the reply
sender's address is included, when it would seem to be required, or
not to be added, depends upon ..."
| 3. It requires that "Reply-To:" is ignored.
As should that, though Reply-To is regarded as an originator field, and
could be (part of) the "sender" as wrong as that is. The issue here
really seems to be that "all recipients included in the header of the message"
doesn't include the (generic) sender (who isn't necessarily a recipient,
though can be) - and obviously should.
| It does not contain an explicit statement either way, so your
| interpretation and mine are both possible.
You're looking at it backwards, concentrating upon how replies are
supposed to be generated (which isn't really specified at all, other
than that comment about where a reply SHOULD be sent if there is no
Reply-To field present).
The IETF don't care about that, that's not an interoperability issue,
software can do whatever it likes, what matters is the interpretation of
the fields, so one knows what they're for, and what data is appropriate
to be included. For that, what's in the RFC is exactly right, Reply-To
indicates the address(es) to which the author of the message containing
it requests that recipients send replies.
What the recipients do with it is up to them, what their MUA offers them
as the default "reply" address list, and/or how much it permits modifications
are all just quality of implementation issues.
Here (the Austin List), however, what the (standard) MUA does with the
various command it has - that is, what the users can rely upon happening,
is an appropriate topic.
| rfc2822 itself says much the same thing later on. In 3.6.3 after it
| describes how the destination fields should be set when creating a
| reply, it says this:
|
| Note: Some mail applications have automatic reply commands that
| include the destination addresses of the original message in the
| destination addresses of the reply. How those reply commands behave
| is implementation dependent and is beyond the scope of this document.
Exactly, what MUAs do with things is not the IETF's bailiwick.
| In particular, whether or not to include the original destination
| addresses when the original message had a "Reply-To:" field is not
| addressed here.
As that is a quality of implementation issue.
Note that my original postscript on the message about issue 1138, where I
mentioned this issue, wasn't about how any MUA handles any mail header fields,
when generating replies, it was about how the mailing list generates
a Reply-To (and mangles the From) field where that Reply-To field is not
indicating the sender's desires as to where replies should be sent. That
is the problem I was pointing out, not what any particular MUA might do
with it.
| Let that be an end to the discussion of how "Reply-To:" is (or was
| originally) intended to be used and whether various email clients
| are right or wrong to handle it the way they do.
WRT the latter, yes, please, because there is no answer to that. But if
you're going to discuss what the mailx (or Mail, or whatever POSIX calls it)
command does by default with its "r" and "R" commands, then the first
part of that might not be possible, as what Reply-To means has to be an
issue when deciding how and when it should be used.
| All that matters for fixing the mailx description is what existing
| mailx implementations do.
agreed.
| Of the ones I tried, with "r":
|
| Solaris uses "Reply-To:" to replace just "From:"
| (although it has "R" and "r" the wrong way round!)
The original BSD "Mail" did it that way, I have no idea when they
swapped cases, that is 'r' was a "small" reply, and "R" a "big" reply...
But almost everyone uses "big" replies all the time, replying only to
the author is a less common thing to do, and R is harder to type than r,
so I guess somewhere along the way, someone switched them.
| S-nail uses "Reply-To:" to replace just "From:" (although, unlike the
| others, it puts the recipients from "To:" into "Cc:").
That's another issue which isn't easy to decide - the distinction between
To and Cc has been largely ignored by all mail software, as there's no
rational way to automate it, and it makes no difference at all to e-mail
transmission or delivery - just how the recipients interpret the message
which can depend upon which header they see themselves on. Eg: I very rarely
reply to (non-list) messages I'm on the cc list of, my assumption is that I was
included just as a courtesy, whereas if I am on the To list, and a reply is
appropriate, I usually send one.
This is all easy to handle for composition of a new message - you just put
the addresses in the field the author says to put them in, but when
auto-generating a list of address, which to field to put them in is a
very hard decision to make.
| BSD mail (8.1 invoked as mailx on macOS) is bizarre. For "R" it ignores
| "Reply-To:" and uses "From:", which suggests it is conforming to the spec
| as written, i.e. ignoring "Reply-To:",
That's the right thing to do for a "reply to author" command, which is
what the standard says 'R' is (and is useful functionality) assuming
we interpret "sender" in the posix mailx page as "the author of the message"
and not anything related to the "Sender" field.
| but for "r" it uses "Reply-To:" as replacement for all recipients.
That's also the right thing to do, interpreting Reply-To correctly for
the common generic reply command.
Nothing bizarre there at all, aside from somewhat limited functionality
in that there are just those two options, and while it is fairly easy to
add extra addresses, my memory of mailx is that isn't nearly as easy to
delete addresses once they have been added.
| Does anyone have access to other implementations they could try?
Well, obviously...
NetBSD Mail (aka mailx) does
& r
To: rep...@example.com rep...@example.com
Subject: Re: test
& R
To: aut...@example.com
Subject: Re: test
There should really also be a test of what happens when there is no
Reply-To field in the message, so I just deleted that one, and:
& r
To: rec...@example.com rec...@example.com aut...@example.com
Subject: Re: test
Cc: c...@example.com c...@example.com
& R
To: aut...@example.com
Subject: Re: test
which is all totally consistent with 'r' being a generic reply, which
in the absence of guidance in the Reply-To header sends to everyone
(this behaviour is exactly as I have my MUA configured, it is the
ideal behaviour), and 'R' remains a "reply to the author" only.
| I expect other commercial UNIXes will be the same as Solaris, so
| the main thing that's missing is a more recent BSD mail, if there
| is one.
Not sure what the FreeBSD/OpenBSD versions do, but this seems to be just
the same as the MacOS version, and the ideal defaults, to me.
How you can manage to reconcile this in the standard, more precisely
that saying "the r and R commands reply to the current message, using
different, but otherwise unspecified, addresses obtained from the header
of the current message" (in better prose than that, one would hope), I
don't know, and that's not very useful to anyone.
| P.S. I know I said I would trim all the offtopic stuff, but I just
| want to make one small exception:
| > But I bet it will be deleted by the mailing list software, and
| > replaced by something different....
| It wasn't.
Yes, I saw... that's a definite improvement over what was there before,
when I first tested that soon after this new way of doing list processing
was enabled, it didn't work like that.
kre
