|Anonymous | Login||2023-12-05 11:38 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001401||[1003.1(2016/18)/Issue7+TC2] Shell and Utilities||Editorial||Enhancement Request||2020-09-19 18:35||2021-02-23 15:48|
|Priority||normal||Resolution||Accepted As Marked|
|Section||Vol. 3: Shell and Utilities, Issue 7, mailx|
|Final Accepted Text||Note: 0005004|
|Summary||0001401: reply command uses obsolete wording|
As has come up on the list, the included
Mail a reply message to all recipients included in the header of the message.
is based upon thirty and more years old code, which also always contradicted the email RFCs, from RFC 822 on.
BSD Mail has been corrected to use RFC 822 compatible handling with
Author: Craig Leres <leres>
AuthorDate: 1983-06-05 17:20:23 -0800
Commit: Craig Leres <leres>
CommitDate: 1983-06-05 17:20:23 -0800
Modified to use the "From:" line (if one exists) when replying rather
than the "From" line (i.e. the first line in the message).
Also the handling of Reply-To: (same standard) has been introduced even earlier (meaning that it replaced all recipients, not only the entries of From:)
Author: Kurt Shoens <kas>
AuthorDate: 1981-02-06 09:35:41 -0800
Commit: Kurt Shoens <kas>
CommitDate: 1981-02-06 09:35:41 -0800
Changed reply to send only to reply-to field if such given
On line 98093, change
Mail a reply message to all recipients included in the header of the message.
Mail a reply message to the sender and all recipients included in the header of the message.
edited on: 2020-10-02 16:07
The desired action only corrects the additional fourth problem raised on the mailing list after the initial three. Here is a proposal that corrects all four...
On page 2952 line 97834 section mailx (metoo variable), change:
Suppress the deletion of the login name of the user from the recipient list when replying to a message or sending to a group.to:
Suppress the deletion of the user's login name and any alternative addresses from the recipient list when replying to a message or sending to a group.
On page 2954 line 97918 section mailx (alternates command), change:
(See also the metoo variable.) Declare a list of alternative names for the user's login. When responding to a message, these names shall be removed from the list of recipients for the response. The comparison of names shall be in a case-insensitive manner. With no arguments, alternates shall write the current list of alternative names.to:
Declare a list of alternative addresses for the address consisting of the user's login name. When responding to a message or sending to a group, if the metoo variable is unset these alternative addresses shall be removed from the list of recipients. The comparison of addresses shall be performed in a case-insensitive manner. With no arguments, alternates shall write the current list of alternative addresses.
On page 2956 line 97996 section mailx (followup command), after applying bug 1405 change:
In the lowercase form, respond to a message, recording the response in a file whose name is derived from the author of the message. See also the save and copy commands and outfolder.to:
The followup and Followup commands shall be equivalent to reply and Reply, respectively, except that:
On page 2959 line 98082 section mailx, after applying bug 0001405 change:
Reply to a Message Listto:
Reply to a Message or a Message List
Re Note: 0005004
I would suggest swapping the order of the "The initial list of recipients"
and "The modifications applied to the initial list" paragraphs, the logical
order is to first collect the addresses, then remove any that should be
removed, and then place them in their appropriate outgoing fields.
The set of recipients marked for placement in each header field of the reply
message shall have duplicates removed.
I'd suggest adding
Where duplicate addresses originated from different header fields in
the original message(s) retain the copy that originated from any
Reply-To header field, and if none did, from the From header field,
and if none, from the To header field, and finally from the Cc
That is for the purposes of assigning addresses to outgoing fields, mailx
shouldn't be replying to a message that is
and constructing a reply with addr1 in the cc field, because that's
where it was seen when the duplicate from the From field was deleted.
Aside from that, this looks fine, though (unrelated to the issue in the
bug report) it might be better to be clearer in the text...
Mail a reply message to one or more addresses ...
that these commands don't simply mail a reply message, they construct a
template reply message, to which the user is expected to add the actual
reply, and after that's done, they mail the reply message (if it wasn't
aborted). This is hinted at with phrases like "after mailx enters input mode"
but nothing ever says why that would happen, or even that it should.
That should probably be somewhere generic (not part of the R/r command descr)
as it also applies to the "m" and "followup" commands, something perhaps like
When commanded to mail a message, mailx shall construct a template
message, and then prompt the user to complete it, by supplying the
body of the message, and optionally modifying the template header.
See [xref whatever section] for the commands available in input mode.
It may also be worth considering whether something should also be done with
the "followup" (fo/F) commands akin to what is being done with reply/respond.
(I didn't even know followup existed -- it has been about 40 years since I
last seriously used mailx (then just called Mail)).
I do not understand
Otherwise, it is implementation-defined whether all of the addresses in the Reply-To, To, and Cc fields are included in the list or only the address or addresses in the Reply-To field.
given that already RFC 822 states in 4.4.4 that Reply-To: is meant to replace the content of From:. The examples in A.2 ORIGINATOR ITEMS support this.
It is true this misuse of Reply-To: was advocated and such examples have been seen, i imagined because of missing standardization of the Mail-Followup-To: header which is meant to define an exclusive list of reply addresses, but given that already the email standard RFC 822 from 1982 was clear i would not standardize undefined behaviour in POSIX in 2020.
Software should follow the RFC.
Regarding metoo/alternates i have no time to look the next couple of days.
But it is clear that metoo processing historically _only_ applied to the login name of the user, not to alternates or even full email address matching.
Re Note: 0005007 As I pointed out in the mailing list discussion, RFC 5322 explicitly states that it does not require any particular behaviour here. It says (in 3.6.3 after it describes how the destination fields should be set when creating a reply):
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. In particular, whether or not to include the original destination addresses when the original message had a "Reply-To:" field is not addressed here.
Re Note: 0005007 - I agree with Geoff (Note: 0005008) - but aside from that
we should not be legislating here, so regardless of what the RFCs (or any
other standards from any other bodies) say, what this standard should
reflect is what the implementations actually do, unless they are clearly buggy.
For this, it is clear that there are differences in the ways that the
various mailx implementations treat Reply-To ... I wish there weren't
and that everyone used it properly, but they don't, so the standard
cannot pretend that they do.
Regarding metoo: neither in BSD Mail nor in Tenth Edition Research Unix is there any relationship in between metoo and alternates. metoo only control elimination of "myself" ($LOGNAME in POSIX) from alias expansions.
Having said that, it is much more useful if metoo is extended and covers the vaporisation of the user including any alternates and expanded aliases!
I think i will implement this when i have time.
Also, undocumented and non-standardized is the convention present in BSD-Mail and Research Unix mailx that a reverse solidus prefix of entries of alias lists prevents further alias expansion. I think i'll add an issue at times.
|I have updated Note: 0005004 to clarify the de-duplication requirement and allow cross-header de-duplication. It seemed simpler to specify this in terms of which outgoing header they are marked for placement in, instead of (as kre suggested) where they came from.|
|2020-09-19 18:35||steffen||New Issue|
|2020-09-19 18:35||steffen||Name||=> Steffen Nurpmeso|
|2020-09-19 18:35||steffen||Section||=> Vol. 3: Shell and Utilities, Issue 7, mailx|
|2020-09-19 18:35||steffen||Page Number||=> 2959|
|2020-09-19 18:35||steffen||Line Number||=> 98093|
|2020-09-25 11:14||geoffclare||Relationship added||related to 0001405|
|2020-09-28 09:28||geoffclare||Note Added: 0005004|
|2020-09-28 09:29||geoffclare||Note Edited: 0005004|
|2020-09-28 09:31||geoffclare||Note Edited: 0005004|
|2020-09-28 09:34||geoffclare||Note Edited: 0005004|
|2020-09-28 14:16||kre||Note Added: 0005005|
|2020-09-28 20:34||steffen||Note Added: 0005007|
|2020-09-29 10:57||geoffclare||Note Added: 0005008|
|2020-09-29 13:52||kre||Note Added: 0005009|
|2020-09-29 16:00||steffen||Note Added: 0005010|
|2020-10-01 10:42||geoffclare||Note Edited: 0005004|
|2020-10-01 10:44||geoffclare||Note Added: 0005014|
|2020-10-02 16:05||geoffclare||Note Edited: 0005004|
|2020-10-02 16:07||geoffclare||Note Edited: 0005004|
|2021-02-08 16:22||geoffclare||Interp Status||=> ---|
|2021-02-08 16:22||geoffclare||Final Accepted Text||=> Note: 0005004|
|2021-02-08 16:22||geoffclare||Status||New => Resolved|
|2021-02-08 16:22||geoffclare||Resolution||Open => Accepted As Marked|
|2021-02-08 16:23||geoffclare||Tag Attached: tc3-2008|
|2021-02-23 15:48||geoffclare||Status||Resolved => Applied|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|