Please don't implement support for Mail-Reply-To and Mail-Followup-To
in nmh. Not only are they nonstandard, they're a poor fix for the
problem.
Well, everything is nonstandard until it becomes standard. The standards
only documented current practice. Since it appears (at least) several
people who develop mail clients are interested in this proposal, it should
be taken seriously.
Standards don't always document current practice, and sometimes
current practice is so harmful that it should not be standardized.
(Of course, standards aren't perfect either - some standards are so
bad that they should not be adopted.)
But yes, I do take the proposal seriously, which is why I go to the
trouble to argue against it...
I also believe this proposal is a good way of fixing this problem. The
problem is the existence or absence of a single header is not enough
information. That is the reason the Reply-To header is typically implemented
in a way that goes against RFC-822 in certain cases.
There are lots of different views of "the problem", or to put it
another way, there are lots of different problems. See
http://www.cs.utk.edu/~moore/reply-problem-list.txt for one attempt to
list the problems with reply.
Not all of these problems can be solved without adding new header
fields. But in general, you don't need new header fields to solve the
problems where replies go to the wrong place. The only way to solve
this problem is to build better user interfaces that help the
responder make an intelligent choice about where replies go. And you
can implement those user interfaces without adding new header fields.
(And as for the problems whose solutions do require new header fields,
Mail-{Reply,Followup}-To doesn't solve them.)
If every mail client is doing this, then it becomes the standard.
Perhaps, but that doesn't mean that the behavior is desirable.
My goal is not to change the behavior of everyone writing mail clients
(that's not possible). My goal is to write a mail client that inter-operates
nicely with the mail clients that other people are using.
Of course we want clients to interopreate. But the Reply-To issue
isn't so much one of interoperability with the installed base, as one
of building effective user interfaces.
I say this because at present Reply-To is so useless that there's very
little interoperability lost by this change in behavior. The two
cases where it's used seem to be:
A. The user of a multiuser system whose user agent automatically sets
From to be the address associated with his login (and perhaps the
user cannot change From to some other address). So he sets
Reply-To to force replies to go to a different address.
(Such users fall into two classes - customers of large timesharing
services, which tend to run nonstandard email systems anyway; and
users of a particular few UNIX user agents, which form a
vanishingly small part of the user population)
B. Mailing lists that want to force replies to go to the list
(a practice which is widely frowned upon)
Imagine a user interface that makes it easy for people to choose where
their replies go. It has two buttons: one labeled "Reply to Author"
and another labeled "Reply".
+ "Reply to Author" always defaults to the address(es) in the From
field. But the user interface also displays the address from any
Reply-To field (grayed out and thus disabled), and the responder can
click on a button to enable the Reply-To address and disable the From
address.
+ "Reply" always defaults to the address in the Reply-To field if there
is one present. If not, it uses the addresses in the From, To, and Cc
fields. But even if the Reply-To field was present, the addresses
from the From, To, and Cc fields are still visible (grayed), and you
can click on any address to toggle whether the message will be sent to
that address.
(Of course, you still need to be able to type in new addresses.)
This way, you could read a message, decide to Reply, and if you didn't
like the defaults you could change them with a couple of mouse clicks.
I've talked to a guy who did human factors studies with this kind of
email interface; he said it works quite well.
Of course, it's a bit more difficult to provide this functionality
with a command-line UI like mh has. But it's certainly seems possible
to improve on the current behavior.
Since the Reply-To header is interpreted differently by different people,
fixing this situation is impossible at this time. That is why the proposal
offers two new header fields "Mail-Reply-To" and "Mail-Followup-To".
Dan's proposal is intrinsically flawed. It incorrectly assumes that
the sender can reasonably anticipate the recipient's needs in replying
to the message, and that such needs can reasonably be lumped into
either "reply" or "followup". It doesn't solve the real problem,
which is that responders need to think about where their replies go.
Mail-Followup-To won't decrease the number of messages that go to the
wrong place.
If I sent out a message inviting people to a meeting, and want
"normal" replies (presumably accepting or declining the invitation) to
go to my secretary. Should I put my secretary's address in
"Mail-Reply-To" or "Mail-Followup-To"?
Say I put it in Mail-Reply-To and a responder wants to send a personal
reply to me, perhaps because it's sensitive in nature. So he hits
"reply to author" thinking that the message will go to me. Instead,
the message goes to my secretary. This is Bad.
Say I put my secretary's address in Mail-Followup-To and a responder
wants to send a message to the list of recipients of the original
message -- maybe that responder wants to let everyone know about cheap
airfares to the meeting. So the responder hits "reply to everyone"
thinking that the message will go to everyone. Instead, the message
goes to my secretary. This is not as bad as the other case, but it's
still not desirable.
So if some responses are neither "personal" nor "group" replies, why
not define an extensible reply header that would include not only the
address but the category of reply? Something like:
Labelled-Reply-To: secretary; jeeves(_at_)cs(_dot_)utk(_dot_)edu
Labelled-Reply-To: mailing-list; listname(_at_)foo(_dot_)com
It turns out that we already have most of this in RFC 822:
a. The 'phrase' before an address, or a comment, can identify
a person by name and/or role. The responder can use this
information to decide whether it's reasonable to send a reply
to that person. e.g.
Reply-To: (my secretary) <jeeves(_at_)cs(_dot_)utk(_dot_)edu>
b. Similarly, the 'phrase' before a group name can identify a group of
recipients, which can also be used by the responder. e.g.
Reply-To: Secretary: jeeves(_at_)cs(_dot_)utk(_dot_)edu ;,
The Gang: a(_at_)foo, b(_at_)bar, c(_at_)zot ;
(Unfortunately, phrases are so widely botched, that they probably
aren't usable for this.)
Summary:
1. The way to solve most reply problems is to encourage the responder
to actually think about where the message needs to go, and make it
easy for him to get the behavior he wants. (It also helps if people
use the RFC 822 'phrase' to label their header addresses.)
2. We can build interfaces that help the responder do this without
defining any new header fields.
3. Except for a very few cases, Mail-{Reply,Followup}-To doesn't help.
It only provides more opportunities for surprising behavior.
Keith