* Re: Mail-{Reply,Followup}-To considered harmful
1998-02-11 22:19 ` Mail-{Reply,Followup}-To considered harmful Richard Coleman
@ 1998-02-11 23:15 ` Robert Elz
1998-02-11 23:43 ` Perry E. Metzger
1998-02-13 6:37 ` Keith Moore
2 siblings, 0 replies; 5+ messages in thread
From: Robert Elz @ 1998-02-11 23:15 UTC (permalink / raw)
Cc: nmh-workers, exmh-users, ding
Date: Wed, 11 Feb 1998 17:19:30 -0500
From: Richard Coleman <coleman@math.gatech.edu>
Message-ID: <199802112219.RAA12647@math34.math.gatech.edu>
| 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.
Not that it really matters why, but I doubt this. RFC-822 on reply-to is
just almost hopeless. The reason people do what they do is more likely
because they saw someone else doing that, and imagined it was correct,
and copied - perhaps slightly varying things along the way.
| 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".
It is possible to write sensible useful semantics for a single reply-to
type header field (whatever it is called). They won't necessarily do
everything everyone wants, but sane and internally consistent and complete
they would be.
Two header fields only generates confusion. It tackles a different problem
and doesn't solve all of it. It would be OK if there truly were exactly
two different kinds of replies people might like to make, and while those two
may cover 90% of the cases, they don't cover all. That is, this solution
cannot be complete, it doesn't really solve any problem at all.
kre
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Mail-{Reply,Followup}-To considered harmful
1998-02-11 22:19 ` Mail-{Reply,Followup}-To considered harmful Richard Coleman
1998-02-11 23:15 ` Robert Elz
1998-02-11 23:43 ` Perry E. Metzger
@ 1998-02-13 6:37 ` Keith Moore
1998-02-13 16:00 ` cwg-dated-4706b1d0ee55baea
2 siblings, 1 reply; 5+ messages in thread
From: Keith Moore @ 1998-02-13 6:37 UTC (permalink / raw)
Cc: nmh-workers, exmh-users, ding, moore
> > 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@cs.utk.edu
Labelled-Reply-To: mailing-list; listname@foo.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@cs.utk.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@cs.utk.edu ;,
The Gang: a@foo, b@bar, c@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
^ permalink raw reply [flat|nested] 5+ messages in thread