Anonymous | Login | 2024-12-12 16:29 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
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 | 2024-06-11 09:08 | ||
Reporter | steffen | View Status | public | ||||
Assigned To | |||||||
Priority | normal | Resolution | Accepted As Marked | ||||
Status | Closed | ||||||
Name | Steffen Nurpmeso | ||||||
Organization | |||||||
User Reference | |||||||
Section | Vol. 3: Shell and Utilities, Issue 7, mailx | ||||||
Page Number | 2959 | ||||||
Line Number | 98093 | ||||||
Interp Status | --- | ||||||
Final Accepted Text | Note: 0005004 | ||||||
Summary | 0001401: reply command uses obsolete wording | ||||||
Description |
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 |
||||||
Desired Action |
On line 98093, change Mail a reply message to all recipients included in the header of the message. to Mail a reply message to the sender and all recipients included in the header of the message. |
||||||
Tags | tc3-2008 | ||||||
Attached Files | |||||||
|
Relationships | ||||||
|
Notes | |
(0005004) geoffclare (manager) 2020-09-28 09:28 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 |
(0005005) kre (reporter) 2020-09-28 14:16 |
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. To: 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 header field. That is for the purposes of assigning addresses to outgoing fields, mailx shouldn't be replying to a message that is From: addr1 To: addr2 cc: addr1 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)). |
(0005007) steffen (reporter) 2020-09-28 20:34 |
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. |
(0005008) geoffclare (manager) 2020-09-29 10:57 |
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. |
(0005009) kre (reporter) 2020-09-29 13:52 |
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. |
(0005010) steffen (reporter) 2020-09-29 16:00 |
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. |
(0005014) geoffclare (manager) 2020-10-01 10:44 |
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. |
Issue History | |||
Date Modified | Username | Field | Change |
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 |
2024-06-11 09:08 | agadmin | Status | Applied => Closed |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |