Keith says that users can control replies with Reply-To (in the absence
of reply-to munging). I agree. However, users currently have no way to
control followups.
Keith then suggests that there's no need for users to control replies
and followups separately. That's absurd. One of the big munging harms
discussed in http://www.unicom.com/FAQ/reply-to-harmful.html is the
user's inability to control replies.
Next Keith proposes using Sender in place of From, using From to control
replies, and using Reply-To to control followups. This is a massive
change from the RFC 822 Reply-To semantics supported by dozens of
existing clients. The transition would be a disaster.
There's a difference between a human making an intelligent choice
about where she wants her replies to go,
Here Keith is referring to people deleting recipients from followups.
The problem is that these people don't have the information they need:
are those recipients members of the mailing list? The result is that
non-subscribers are often accidentally removed.
And if a followup-to field were introduced, lists would add or mung
that field also, along with reply-to.
If Keith doesn't understand why Reply-To munging happens right now, he
should read http://www.unicom.com/BBS/bbs_forum.cgi?forum=replyto. The
more clients that support a followup field, the less motivation there is
for this type of munging.
A UA that blindly copy followup-to to followups, creates much the same
problem as list robots that blindly mung reply-to.
If Keith doesn't understand the harms caused by Reply-To munging, he
should read http://www.unicom.com/FAQ/reply-to-harmful.html.
Followups are an artifact of the netnews environment, where you have
separate address schemes for email and netnews.
Nonsense. Replies and followups are fundamentally different operations.
Practically every mailer supports both replies and followups.
This has nothing to do with the difference between mail addresses and
news addresses.
having two different address schemes creates lots of problems.
I agree. One solution is to integrate the newsgroup address space into
the mail address space. Here's a working example:
To: djb(_at_)koobera(_dot_)math(_dot_)uic(_dot_)edu,
sci(_dot_)crypt(_at_)pubnews(_dot_)demon(_dot_)co(_dot_)uk
It would be easy to set up a global usenet.news domain, configured
locally to talk to a nearby NNTP server.
Newsgroups are simply high-volume mailing lists with many entry points
and a fancy distribution mechanism.
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.
Every popular MUA supports both replies and followups.
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.
False. It provides a direct way to control followups; this feature does
not exist right now. MUAs will check the followup field before checking
From/To/Cc or Reply-To/To/Cc.
Many simple situations can be handled with the proposed Mail-Copies-To
field, which says whether to include the sender in followups, but a
followup field is a much more direct solution.
Explanation, please. Who exactly would be confused?
Besides you? (sorry, that was too easy.)
I find this comment rather amusing, given the number of ridiculous
statements that Keith has made in this discussion---claiming that the
followup field is for MLMs to set, claiming that the widely recognized
problem of duplicates doesn't exist, claiming that the problem is solved
by MUA duplicate elimination, etc.
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.
[ ... ]
Support for followup-to would require that UAs add other commands
("followup", "set followup-to") in addition to the set above.
Here Keith makes yet another stupid mistake: he seems to think that
followups are something different from the MUA's existing ``wide reply''
or ``group reply'' or ``reply to all'' feature.
One wonders how many times Keith needs to see the problem statement
before he understands it. Here it is again:
Right now, when someone _follows up_ to a mailing list message from a
subscriber, the subscriber and the mailing list are both in the
followup's recipient list by default.
The obvious fix is to let the subscriber override the default _followup_
target, omitting his own address.
Explanation, please. How exactly would a followup field hurt anyone?
I've already explained this.
Nonsense. Keith has explained bad consequences of two red herrings:
first, having MLMs munge the followup field; second, having followups
distinguished from reply-to-sender-and-recipients.
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.
Nonsense. It's supported by most, perhaps all, of the installed base.
It's even supported by Berkeley Mail.
What isn't standardized is the _name_.
Also please explain why it
would not suffer from the same problems that reply suffers from.
The motivation for reply-to munging is that, in its absence, a typical
user has no easy way to follow up without the problem of duplicates
discussed above.
If, on the other hand, his MUA supports a followup field, subscribers
suddenly have the ability to eliminate those duplicates.
Once the followup field is universally supported, the motivation for
reply-to munging will be gone.
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.
Is there anyone other than Keith who's confused about the function and
benefits of a followup field? I don't see Keith's self-imposed blindness
as a major problem here; MUA implementors have never paid much attention
to him in the past, and aren't likely to pay attention to him now. The
introduction of Mail-Copies-To in two MUAs indicates that other people
understand the problem here.
---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html