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.
for many people, "reply to all" is "normal". "reply to author" is the
special case. at any rate, this is a recipient decision, not one made
by a message author.
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,
well, the legacy submission program would have to fail if it were given
the currently unused argument, so that the new MUA could test to see
whether that feature were supported by the submission program. given
that this kind of submission interface isn't standardized, and that
there are multiple programs which implement something like this
interface, I think it would be difficult to rely on such a test. also,
if the MUA is going to be modified to perform such a test, it seems like
it would be almost as easy, and much more reliable, to modify the MUA to
just extract the recipient list and supply that on the command line.
(granted, it would have to do Bcc processing also).
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.
that's a good point - if we can solve the problem with existing fields
then the example is not a justification for new fields. so I'll need to
come up with a better example :)
(many years ago I wrote down a list of every problem I could identify
with "reply" given the current header definitions. I haven't yet taken
the trouble to look at that list in the context of the current
discussion, but it will be interesting to re-examine that list with an
eye to how NR fields might or might not help with those problems)
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.
I don't think that's quite right. All that's really needed is for the
author of a message to realize that certain recipients probably don't
need to receive replies to the message currently being composed.
It may be that the most likely cases are
a) for an author to realize that he doesn't want to receive replies to
the message currently being composed.
(which is solved with "Reply-To: nobody:;")
and
b) a recipient to realize that he doesn't want to receive any more
copies of messages to that thread
(a problem which NR fields do not address)
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.
interesting idea.
in general, thanks for the careful review and comments.
Keith