Keith,
Regardless of the merits of this idea has it been introduced as
part of the original email model, I see several problems. At
minimum, I believe a future version should respond to them. At
worst, it turns this, on balance, into a Bad Idea:
(1) Most of the functionality, for most cases, appears to be
addressed by
Reply-to: address1, address2, address3,...
Now, while that has rarely been well-implemented, it has been in
the standard since 822 or earlier. It is hard for me to see an
argument that a newer set of headers would work significantly
better.
(2) Your legacy discussion fails to discuss the interactions
among a Reply-to field that is present and these new fields if
they are also present. It seems to me that could get
complicated.
(3) To the extent to which this and Reply-to overlap, it gives
us two different ways to do essentially the same thing. That is
rarely, if ever, a good idea.
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.
Since the -NoReply fields do not affect replies at all, I do not
see how they could interfere with Reply-To. In particular if a
recipient appears in both a Reply-To field and a -NoReply field,
a reply to that message would be exactly the same as if the
recipient appeared only in the Reply-To field.
I thought this was clear from what I wrote, but if not, I can certainly
add clarifying text.
(4) If these are sent out from a system that has no idea whether
the recipient will honor or ignore them, it seems to me that we
introduce the potential for huge levels of confusion and unmet
expectations. That isn't a showstopper, but argues against
this, IMO, unless it is really clear that there would be
significant benefits.
For a receiving MUA to "honor" the -NoReply fields merely requires
that they be displayed. They do not affect how replies are composed.
The reason that I designed the fields to work in this way (in contrast
to some other proposals) is to minimize the potential for confusion and
unmet expectations.
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.
Keith