Austin Group Defect Tracker

Aardvark Mark IV


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
related to 0001405Closed mailx header terminology needs to change to match RFC5322 

-  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.

In the capitalized form, respond to the first message in the msglist, sending the message to the author of each message in the msglist. The Subject header field shall be taken from the first message and the response shall be recorded in a file whose name is derived from the author of the first message. See also the Save and Copy commands and outfolder.

Both forms shall override the record variable, if set.
to:
The followup and Followup commands shall be equivalent to reply and Reply, respectively, except that:
  • They shall ignore the record variable.

  • The followup command shall record the response in a file whose name is derived from the author of the message.

  • The Followup command shall record the response in a file whose name is derived from the author of the first message in the msglist.

See also the save and copy commands and outfolder.

On page 2959 line 98082 section mailx, after applying bug 0001405 change:
Reply to a Message List

Synopsis:
R[eply] [msglist]
R[espond] [msglist]
Mail a reply message to the sender of each message in the msglist. The value for the Subject header field shall be formed by concatenating Re:<space> (unless it already begins with that string) and the value of the Subject header field from the first message. If record is set to a filename, the response shall be saved at the end of that file.

See also the flipr variable.

Reply to a Message

Synopsis:
r[eply] [message]
r[espond] [message]
Mail a reply message to all recipients included in the header of the message. The value for the Subject header field shall be formed by concatenating Re:<space> (unless it already begins with that string) and the value of the Subject header field from the message. If record is set to a filename, the response shall be saved at the end of that file.

See also the flipr variable.
to:
Reply to a Message or a Message List

Synopsis:
r[eply] [message]
r[espond] [message]
R[eply] [msglist]
R[espond] [msglist]
Mail a reply message to one or more addresses taken from certain header fields in the specified message or message list. If the flipr variable is unset, these commands shall behave as described below. If the flipr variable is set, commands in the lowercase form shall behave as described below for commands in the capitalized form, and vice versa; the synopsis forms shown above shall also be swapped accordingly.

The recipients of the reply message shall be determined by first constructing an initial list of recipients and then modifying it to form the list that is in effect when mailx enters input mode.

In the capitalized form, the initial list of recipients shall be taken from the header of each message in the msglist as follows:
  • If the header contains a Reply-To field, the address or addresses in that field shall be added to the list.

  • Otherwise, the address or addresses in the From field of the header shall be added to the list.

In the lowercase form, the initial list of recipients shall be taken from the header of the message as follows:
  • If the header does not contain a Reply-To field, all of the addresses in the From, To, and Cc fields shall be included in the list.

  • 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.

The initial list of recipients shall be marked for placement in the header fields of the reply message as follows. Recipient addresses taken from a From or Reply-To header field shall be marked for placement in the To field of the reply message. Recipient addresses taken from a Cc header field shall be marked for placement in the Cc field of the reply message. Recipient addresses taken from a To header field shall be marked for placement in either the To or the Cc field of the reply message. Implementations shall provide a way to place them in the To field. Implementations may, but need not, provide an implementation-defined way to place them in the Cc field.

The modifications applied to the initial list of recipients shall be as follows:
  • If the metoo variable is unset, addresses consisting of the login name of the user and any alternative addresses declared using the alternates command shall be removed from the list.

  • The set of recipients marked for placement in the To header field of the reply message shall have duplicates within that set removed.

  • The set of recipients marked for placement in the Cc header field of the reply message shall have duplicates within that set removed and may have recipients that are also marked for placement in the To field removed.

The values for the To and Cc header fields of the reply message shall be constructed from the addresses in the modified list of recipients that are marked for placement in each of those fields.

The value for the Subject header field of the reply message shall be formed from the value of the Subject header field of the message or the first message in msglist by prefixing it with Re:<space>, unless it already begins with that string.

The values of the To, Cc, and Subject header fields set as described above can be modified by the user after mailx enters input mode through the use of the ~t, ~c, ~s, and ~h command escapes.

If record is set to a pathname, the response shall be saved at the end of that file.


(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
Powered by Mantis Bugtracker