I don't think using Reply-To is a viable solution, because:
* It requires UAs to restrict their reply-using-destination-fields
behavior when it is present. Sounds familiar, but in this case
it's worse, because it retroactively changes the interpretation of
reply-using-destination-fields for messages sent long ago.
Actually I believe that UAs should encourage people to *select* the
recipient list of *every* reply which would otherwise be addressed to
more than one recipient. Of course, they should make the recipient
(the one issuing the reply) aware of the sender's preference, as
expressed through the reply-to field from the subject message.
This requires a drastically different user interface than for most
existing UAs, but it's the only way I see to address *the* real
reply-to problem (as I define it): people don't stop to notice where
their email replies are going.
It's an open question as to whether UAs that encourage such behavior
can be successful in the market...users would probably rather be lazy
than aware, even if they occasionally get bitten for being lazy.
* Mailing lists must stop rewriting Reply-To. List managers are not
going to give up control over list policy (direct replies to the
list or away from it) and Reply-To is the only way to influence a
large number of existing user agents.
Old mailing lists are unlikely to change their policies, but new ones
can adopt new policies. And some list software can provide new
defaults for new subscribers, while retaining the same reply-to
munging settings for old ones. Both of these have happened before.
At any rate, I suspect we're going to end up with some sort of
List-Address or List-Reply-To header, along with List-Subscribe,
List-Unsubscribe etc. It's easy to do, and there was a lot of support
for it at the listhdr BOF at the Memphis IETF.
So it does seem that a new differentiator is necessary, but I don't think
`followup' is the obvious or correct one.
The claimed benefits of `followup' are:
* Gives control to the original author (but too much so).
* Easy to implement (maybe).
* Existing UAs support the concept (but they don't, really).
* No transition problem from current practice.
Here's an alternative which I think betters `followup' on every one of
those points: Define a `Reply-Cc' field, with the semantics that the
address(es) in the Reply-Cc field should be copied to the Cc field of
the reply; the semantics of all existing fields remain unchanged, except
of course that the presence of Reply-To does not exclude the Reply-Cc.
I don't think this solves the problem Dan was complaining about, which
is that people get multiple copies of a reply if multiple addresses
that reach them appear in the header of the subject message.
[ Apologies if the following proposal is like mail-copies-to. I
haven't seen a definition of that header, so I can't evaluate it.
If the thing is actually deployed, and someone knows how it works,
they might consider sending a description to Jacob Palme for
inclusion in the eventual successor to RFC 2076. anyway... ]
I thought about proposing a header of the form
Dont-Reply-To: <x(_at_)foo(_dot_)com> if-replying-to <y(_at_)bar(_dot_)com>
which essentially says: if you're sending a reply which would
otherwise be addressed to both X(_at_)foo(_dot_)com and address
y(_at_)bar(_dot_)com, leave
x(_at_)foo(_dot_)com out of the recipient list of that reply. So if person
X(_at_)foo(_dot_)com is a member of the list y(_at_)bar(_dot_)com, he could
include such a
header in his mail to y(_at_)bar(_dot_)com(_dot_) User agents would then know
to omit
X(_at_)foo(_dot_)com (from both header and envelope) in any reply containing
y(_at_)bar(_dot_)com, and x(_at_)foo(_dot_)com would only get one copy of the
reply -- the
one from the list.
pros/cons/{mis,}features:
+ It doesn't change the user interface for the guy issuing the
reply. He just says 'reply' or "reply to author" or reply to
author+to+cc or whatever he says now, and the user agent does
this, but leaving out the redundant addresses.
- It does require the sender's UA to be smart about when to add the
Dont-reply-to header on outgoing mail.
- It opens the possibility of loops: what does a UA do if it sees
Dont-reply-to: <x> if-replying-to <y>
Dont-reply-to: <y> if-replying-to <z>
Dont-reply-to: <z> if-replying-to <x>
In this case, it's safe to ignore all of the headers.
- There's nothing to stop lists from munging this header. Some
lists might want to be "smart" and add Dont-Reply-To headers for
any message sent from a list member. Some people would like this,
since they'd get the benefits of Dont-Reply-To without having
to change their UA. Some people (like me) wouldn't want the list
to add such a header.
Unless the Dont-Reply-To spec clearly stated whether lists could
mung the header, some would do so and others would not. (yeech)
- It doesn't solve the two-list problem (if you're a member of
two lists and a message is addressed to both lists, you'll still
get two copies). (Duplicate suppression at the recipient's
UA does tend to solve this problem, as long as neither list
mungs the message too much.)
- It doesn't solve the general reply-to problem: people don't notice
or think about where their replies are going.
Personally, I don't think it's worth it: there's not enough to be
gained for the trouble, and duplicate suppression is more effective
(solves the problem in more cases) and easier to deploy (only requires
support for the recipient who wants to suppress multiple messages, and
that recipient reaps the reward for his own effort). If more UAs had
duplicate suppression there would be very minimal additional gain to
be had from Dont-Reply-To or similar proposals.
(Dan claims that after enough replies from different people, the
recipeint lists get so long that mail sofware breaks. While this is
true in principle, I've never seen it happen in practice. I've seen
software break due to long recipient lists, but never because of a
recipient list created by too many replies to too many different
people. Even IETF list threads don't go on for that long. And its
easier to fix the mailers that break with long recipient lists than it
is to fix mailers to support some new header and/or new functionality.)
Keith