From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/13947 Path: main.gmane.org!not-for-mail From: Keith Moore Newsgroups: gmane.emacs.gnus.general Subject: Re: Mail-{Reply,Followup}-To considered harmful Date: Fri, 13 Feb 1998 01:37:07 -0500 Sender: owner-ding@hpc.uh.edu Message-ID: <199802130637.BAA01940@spot.cs.utk.edu> References: <199802112219.RAA12647@math34.math.gatech.edu> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035153221 12026 80.91.224.250 (20 Oct 2002 22:33:41 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 22:33:41 +0000 (UTC) Cc: nmh-workers@math.gatech.edu, exmh-users@sunlabs.eng.sun.com, ding@gnus.org, moore@cs.utk.edu Return-Path: Original-Received: from xemacs.org (xemacs.cs.uiuc.edu [128.174.252.16]) by altair.xemacs.org (8.8.8/8.8.8) with ESMTP id WAA01947 for ; Thu, 12 Feb 1998 22:40:13 -0800 Original-Received: from gizmo.hpc.uh.edu (gizmo.hpc.uh.edu [129.7.102.31]) by xemacs.org (8.8.5/8.8.5) with ESMTP id AAA05058 for ; Fri, 13 Feb 1998 00:38:54 -0600 (CST) Original-Received: from sina.hpc.uh.edu (sina.hpc.uh.edu [129.7.3.5]) by gizmo.hpc.uh.edu (8.7.6/8.7.3) with ESMTP id BAN20371; Fri, 13 Feb 1998 01:15:11 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 13 Feb 1998 00:37:33 -0600 (CST) Original-Received: from claymore.vcinet.com (claymore.vcinet.com [208.205.12.23]) by sina.hpc.uh.edu (8.7.3/8.7.3) with SMTP id AAA20659 for ; Fri, 13 Feb 1998 00:37:23 -0600 (CST) Original-Received: (qmail 14199 invoked by uid 504); 13 Feb 1998 06:37:18 -0000 Original-Received: (qmail 14196 invoked from network); 13 Feb 1998 06:37:17 -0000 Original-Received: from spot.cs.utk.edu (128.169.92.189) by claymore.vcinet.com with SMTP; 13 Feb 1998 06:37:17 -0000 Original-Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id BAA01940; Fri, 13 Feb 1998 01:37:08 -0500 (EST) X-URI: http://www.cs.utk.edu/~moore/ Original-To: Richard Coleman In-reply-to: Your message of "Wed, 11 Feb 1998 17:19:30 EST." <199802112219.RAA12647@math34.math.gatech.edu> Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:13947 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:13947 > > 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) 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