Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:
I'm curious to know what people think of this idea.
I like the way it behave on legacy clients. In comparison,
Mail-Followup-To and Mail-Reply-To doesn't work if a client isn't
aware of those headers.
I dislike that it require modification to the "submission" phase. I
think one could argue that it is _more_ difficult to change submission
agents ("sendmail -t") AND all mail clients that do SMTP internally,
than it is to change only mail clients to support the MFT/MRT
approach.
Assuming
a) there are many more MUAs than MTAs that implement a "sendmail -t"
interface, and
b) the actual code changes are trivial, and the real barrier to
upgrading existing MUAs and MTAs is not in the coding or testing
but in pushing the new bits out to hosts
I think it's about the same amount of _effort_ either way. However,
Mail-{Followup,Reply}-To (MFT for short) appears to have a more
difficult/confusing transition phase. Most sending MUAs will make it
difficult for authors to generate NoReply fields until they're
upgraded to support them. And receiving MUAs will do more-or-less
the right thing with them anyway.
MFT also allows the author to specify bizarre behavior - so "reply to
all" can be specified so that only the author gets a reply, whereas
"reply to author" can be specified so that everyone gets a reply. With
NoReply fields, the reply-to-author recipients are always a subset of
the reply-to-all recipients. To me that seems like a desirable
property.
Further, either the proposal or I am missing something: How can the
sender of a messages indicate that she _herself_ doesn't want to
receive any further replies?
Reply-To: nobody(_at_)[]
(yes, I know it's ugly.) anyway, the premise behind NoReply fields is
that legacy MUAs can already do the right thing with them. I looked
at defining other kinds of fields that would cancel out the "reply-
ability" of other addresses, and decided that this wasn't the way to go.
OTOH if we wanted to standardize a convention like the above to allow an
author to specify "don't send replies to me", I wouldn't have a problem
with adding a section to the NoReply document that describes that
convention.
Keith