Re: Mail-{Reply,Followup}-To considered harmful

Re: Mail-{Reply,Followup}-To considered harmful

[Richard Coleman]

This topic is currently being debated on the exmh, nmh, and gnus list
at the same time.  I apologize if you see this more than once.  For those
who are just wandering into the discussion, we are talking about the
proposal at:

ftp://koobera.math.uic.edu/www/proto/replyto.html

> 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.

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.

> RFC 822 has language that appears to support this view.  But a careful
> reading of RFC 822 reveals that this prose does not apply to Reply-To with
> respect to a "reply all" function, but only with the use of Reply-To 
> in a "reply to author" function.
>
> This leaves us with the situation where the author of a message is
> unable to specify the complete destination for replies.  Even if
> the author specifies a Reply-To field, if the recipient uses 
> "reply all", addresses from the To and CC field are still included.  
> This is the behavior implemented by almost every UA in existence, 
> but it's almost always the wrong thing to do.
> 

If every mail client is doing this, then it becomes the standard.
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.

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".

> The right way to fix this is to correctly interpret Reply-To -
> not as simply the replacement for the From field in replies, but 
> as the reply destination preferred by the author of the subject message.
> 
> Adding new headers doesn't fix the problem.  It only makes the
> situation more complex.

-- 
Richard Coleman
coleman@math.gatech.edu

Re: Mail-{Reply,Followup}-To considered harmful

[Robert Elz]

    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

Re: Mail-{Reply,Followup}-To considered harmful

[Perry E. Metzger]

Richard Coleman writes:
> > 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.

Keith is the IETF applications area director, and used to chair the
DRUMS working group. I strongly agree with his statements.

> I also believe this proposal is a good way of fixing this problem.

The working group debated it at length and did not agree.

Perry

Re: Mail-{Reply,Followup}-To considered harmful

[Keith 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

Re: Mail-{Reply,Followup}-To considered harmful

[cwg-dated-4706b1d0ee55baea]

[-- Attachment #1: Type: text/plain, Size: 2021 bytes --]

[ Removed nmh-workers@math.gatech.edu ]

> From:  Keith Moore <moore@cs.utk.edu>
> Date:  Fri, 13 Feb 1998 01:37:07 -0500
...
> 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.

Well, seeing as how one of the two places that I'm reading this thread is on 
the exmh list, Is there anybody out there who's interested in implementing 
this for exmh?  If nothing else, it might be worth having a discussion of what 
it would look like in sedit.

Chris

-- 
Chris Garrigues                    O-              cwg@DeepEddy.Com
  Deep Eddy Internet Consulting                     +1 512 432 4046
  609 Deep Eddy Avenue
  Austin, TX  78703-4513              http://www.DeepEddy.Com/~cwg/



[-- Attachment #2: Type: application/pgp-signature, Size: 239 bytes --]