Keith Moore wrote:
For better or worse, Reply-To has been nearly universally implemented
by MUAs as:
When composing a reply to a message for which the Reply-To field
exists, use the addresses in Reply-To as the addresses of the To
field of the reply. If the reply is a "reply to all", To and Cc
addresses from the subject message are also Cc'ed on the reply.
So with Reply-To as it is generally implemented, there's no way for
an author to include a recipient in a To or CC field without that
recipient getting replies to the message.
Sure there is; *only* "reply-to-all" goes to original message
To and Cc recipients -- normal replies only go to the address(es)
specified by the original message author in Reply-To.
I thought this was clear from what I wrote, but if not, I can certainly
add clarifying text.
I think removing obfuscating text is the answer; see below.
The biggest potential for unmet expectations that I see is for users of
legacy MUAs that (a) use "sendmail -t" and (b) allow message authors to
specify arbitrary headers. The potential exists for those users to
specify NoReply recipients who will not receive the message. The
document doesn't currently recommend that "sendmail" and similar
programs be upgraded to support NoReply fields, but that is probably
what should happen. Assuming that all "sendmail" and similar programs
would eventually be upgraded, this would further minimize the potential
for unmet expectations.
Such "upgrading" should probably involve a separate argument to handle
the NoReply fields, one that is currently unused, so that an MUA can
determine whether gathering recipient addresses from NoReply fields
(for the envelope) is supported by a particular instance of such a
program. Without at least some primitive method for "negotiating"
capabilities, there is potential for such issues of unmet
expectations. Note that it is possible to specify additional
recipient addresses when invoking sendmail (with or w/o -t).
Comments on the draft:
I think John is mostly right about existing use of Reply-To/To/Cc.
Certainly the two examples in the draft's introduction can be handled
readily. In the case of the first example, the "handshake" message
would have
To: C
From: B
Cc: A
Reply-To: A
when delegating followup to C. C's followup goes to A alone and
any further correspondence is between A and C unless one or the other
chooses to manually include B or other recipients.
The second example more vividly demonstrates problems with the NoReply
field in the scenario posited. With existing standard fields, at some
point either D or E realizes that they have gone off track and simply
drops Ccs to the list (or if neither does so, the list may be annoyed,
with or without NoReply fields). However, use of NoReply fields
requires either E or D to possess prescience about drifting off-topic;
while that may be predictable in the case of some specific instances
of a D or E, it is in general unrealistic to expect such predictability.
Perhaps the author can come up with an example that illustrates
some capability that cannot be handled by the existing standard
fields.
I believe that there may be an omission -- there should probably be
Resent- versions of the NoReply fields corresponding to the Resent-
versions of the existing standard recipient fields.
Section 3.1 makes a statement about how fields are presented by
(all) legacy MUAs, however at least some present all header fields
unless directed to hide particular field names, so NoReply fields
would be presented by default.
As an aside, RFC 2047's successor should probably clarify handling
of encoded-words in unrecognized extension fields (now that RFC
2822 has removed the distinction between extension and user-defined
fields).
Minor nits (typos, usage, spelling, etc.):
General comment: both "[Aa]n MUA" and "a MUA" appear in the draft.
I would prefer consistent use of "an MUA"; I don't feel strongly
about "a" vs. "an", but consistency would be an improvement.
2.2.5:
IMO eliding the comma and remainder of the first sentence would
improve clarity.
3.3:
explicit -> explicitly
may not -> might not
3.4:
elide the first "will"
3.5:
address headers -> address header fields (or simply address fields)
5.1 last paragraph, first line:
NoReply field do -> NoReply fields do