> > 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.
That's certainly the case for me; reply-to-all is what I typically do.
> > 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).
Capabilities negotiation is the killer in this situations. When ESMTP was firt
proposed there was a tremendous amount of angst about how things like
per-recipient parameters could be dealt with in legacy submission interfaces.
It was eventually decided that having one place to do this was both necessary
and sufficient and that the upgrade path would be to abandon less capable
interfaces and move to SMTP. This eventually became one of the reasons SMTP
SUBMIT was developed.
Ned