It's important to understand that the author sets followups. Let me
emphasize once again that reply-to munging is harmful; the question is
how to fix the message duplication _without_ reply-to munging.
In this case, there's no need for a Followup-To header field. The
existing Reply-To field (as defined in the current 822bis draft) is
sufficient to allow the author to specify his preference as to where
replies should go.
One could argue that Reply-To is broken because so many lists mung it,
and because so many UAs use it only as a replacement for the "From"
address, when doing a "reply to sender and recipients".
I don't really think there is a big need to allow a sender to
separately specify "reply to address-list X if you want to just reply
to me", and "reply to address-list Y if you want to followup". Even
for those times when this is needed, the author can use From for the
former, and Reply-to for the latter. (With Sender used to indicate the
author's "real" address)
And a followup-to like header is certainly not "the" only available
solution. For instance, UAs could suppress duplicate messages.
Suppressing duplicates is fine, if you can afford to do it securely, but
it solves only half the problem.
After a long sequence of followups---let's say a sequence of 500
messages from different contributors---there are, with current defaults,
501 recipient addresses in the header. Software breaks. Humans can no
longer read the header. Each new message takes ten times as much archive
space as it should. Every contributor is at risk of being a permanent
recipient of a neverending discussion; there is no escape.
The existing Reply-To header could be used to prevent such problems.
Why isn't it used that way more often? Because humans blindly reply
to their mail without checking the recipient list, or because UAs
don't encourage people to check the recipient list when forming
replies, or because UAs don't make it easy to change the recipient
list. None of these problems can be fixed by adding another frob to
the mail protocol.
Of course, people don't let the header grow so much. They trim it down
to just the list address. But this introduces some of the same problems
as reply-to munging; for example, it destroys cross-posted discussions.
There's a difference between a human making an intelligent choice
about where she wants her replies to go, and a list robot that blindly
(and often incorrectly) assumes that replies should go to the entire
And if a followup-to field were introduced, lists would add or mung
that field also, along with reply-to.
With a followup field, the solution is trivial: the MUA copies the
message's followup field into subsequent followups by default.
A UA that blindly copy followup-to to followups, creates much the same
problem as list robots that blindly mung reply-to.
Even if you only have reply, sometimes you want to reply to author
only, sometimes to author and all recipients, sometimes to author and
particular recipients, etc.
So what? Are you going to argue that we shouldn't have Reply-To since
people sometimes want followups instead?
Followups are an artifact of the netnews environment, where you have
separate address schemes for email and netnews. Depending on how you
look at it, this was a big mistake, or an accident of history, but
having two different address schemes creates lots of problems.
Propagating any of this mess into the email world is a Bad Idea.
People who have used netnews are accustomed to the notion of public
responses (aka "followups") as opposed to private responses (aka
"email"). So they may tend to think that their email UA should have a
"followup" button (and UAs for both email and news do have such a
button). But in the email world there's no inherent distinction
between "public responses" and "private responses" and it's silly to
pretend that there is one. You can define some notion of "followup"
for email using a followup-to header, but doing so doesn't add any new
services -- it just replicates services that already exist. It might
makes people feel better because there's something for the followup
button to do, but it's not useful purpose.
Add a followup-to
(wide-reply-to, group-reply-to whatever) field to the mix and it just
makes things more confusing.
Explanation, please. Who exactly would be confused?
Besides you? (sorry, that was too easy.)
Users will have a button for replies, just as they do now.
Users will have a button for followups, just as they do now.
Good UAs already have separate commands for reply-to-sender and
reply-to-sender-and-recipients. Ideally, users should be able to
override reply-to for those cases where they really want to send the
message somewhere else, so you need a way to do that. And users need
to be able to set their reply-to and from addresses on outgoing mail.
This is already getting confusing for most users -- who don't
understand why "reply" doesn't "do the right thing". (these same
users would never have such a problem with snail mail -- they'd simply
address the snail mail reply to whomever they thought should receive
Support for followup-to would require that UAs add other commands
("followup", "set followup-to") in addition to the set above. Users
who are confused by existing reply options would be even more confused
by the addition of followup options which basically do the same thing
as replies. They'll make more mistakes, there will be more variation
in behaviors between different UAs (thus confusing authors who expect
that their recipients' UAs work the same as theirs), and there will be
more calls to Tech Support.
What we haven't had is
agreement that such proposals, if adopted, would do more good than
Explanation, please. How exactly would a followup field hurt anyone?
I've already explained this.
We've already had proposals for a name.
I know. I don't think ``Wide-Reply-To'' will work. As you can easily
verify, ``wide reply'' is meaningless for a typical user. (``Does that
have something to do with the window size?'') Even when the MUA has a
``wide reply'' feature, most users have no clue what it does.
``Group reply'' is somewhat better (and apparently more common in MUAs),
but still not immediately clear to most users.
Any other suggestions?
First explain how "followup" would differ from "reply", beyond the
fact that it would use different header names and that it's not
supported by any of the installed base. Also please explain why it
would not suffer from the same problems that reply suffers from. Once
you have defined the new feature, convince people that the new feature
is worth implementing and supporting. *Then* worry about what to call
the header field.