Nathaniel Borenstein writes:
Most users don't have a very complex mental model about this stuff.
And experts are supposed to be an exception?
Sometimes I want my response visible to everyone who read the original
message. In standard USENET terminology, that's a ``followup,'' although
I'd call it ``respond'' in an MUA.
Sometimes I want my response visible only to the sender of the original
message. In standard USENET terminology, that's a ``reply,'' although
I'd call it ``respond only to sender'' in an MUA.
Those two cases cover almost every response I send. Yes, there are some
occasions where I want to do something more complicated, but those
occasions are rare enough that I don't mind handling them manually.
Of course, the followup address list and the reply address list are
based on information provided by the sender. (I can't expect to send my
message to the original Bcc addresses, for example!) This information is
provided through a protocol. Do the protocol details really matter? Yes,
they do:
* The sender has to be able to specify a followup address list that
doesn't include the reply address list. For example, the correct
followup address list for this message is ietf-822(_at_)imc(_dot_)org; the
correct reply address list is djb(_at_)cr(_dot_)yp(_dot_)to(_dot_)
Any protocol that doesn't allow this---for example, ``reply to
Reply-To||From; follow up to To+Cc+(Reply-To||From)'', which was
the de-facto standard---is inherently broken.
Of course, I can say ``Please take djb(_at_)cr(_dot_)yp(_dot_)to out of
the cc list
if you're sending mail to ietf-822(_at_)imc(_dot_)org(_dot_)'' Anyone
following up
can do this manually. But this human protocol is much less pleasant
than something handled automatically by the MUAs.
* There's a huge installed base of software that writes messages (and
of messages already generated by that software). There's also a
huge installed base of software that reads messages.
A protocol that has horrible effects when it interacts with today's
software---for example, ``reply to From; follow up to Reply-To''---
isn't broken per se but would impose huge transition costs. Yes,
the simplicity would be nice, but it's much more difficult to
deploy than other protocols.
* There's a small but noticeable installed base of mailing-list
software that inserts the list address as Reply-To. This breaks
``reply to Reply-To||From,'' among other things.
This software should be stamped out anyway, but in the meantime
it's helpful for a protocol to provide a workaround.
The protocol we're moving to---``reply to Mail-Reply-To||Reply-To||From;
follow up to Mail-Followup-To||(To+Cc+(Mail-Reply-To||Reply-To||From))''
---solves all of these problems. It allows the sender to specify an
independent followup address list; it doesn't hurt existing software;
and it provides a workaround to Reply-To insertion.
As a practical matter, my MUA inserts Mail-Followup-To:
ietf-822(_at_)imc(_dot_)org
into this message, since I told it a long time ago that I didn't want
copies of messages sent to ietf-822(_at_)imc(_dot_)org(_dot_) If you follow up,
and your
MUA supports Mail-Followup-To, then you'll be faced with the correct
To: ietf-822(_at_)imc(_dot_)org
rather than having to edit
To: ietf-822(_at_)imc(_dot_)org
Cc: djb(_at_)cr(_dot_)yp(_dot_)to
down to the desired address list. Nobody has presented any reasons that
the protocol should be modified; the bottom line is that it works.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago