From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/13924 Path: main.gmane.org!not-for-mail From: Jason R Mastaler Newsgroups: gmane.emacs.gnus.general Subject: Re: Mail-Followup-To Date: 11 Feb 1998 14:48:14 -0700 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1035153202 11887 80.91.224.250 (20 Oct 2002 22:33:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 22:33:22 +0000 (UTC) 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 NAA04487 for ; Wed, 11 Feb 1998 13:56:48 -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 PAA19492 for ; Wed, 11 Feb 1998 15:53:28 -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 QAN14747; Wed, 11 Feb 1998 16:29:26 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 11 Feb 1998 15:51:54 -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 PAA18615 for ; Wed, 11 Feb 1998 15:51:45 -0600 (CST) Original-Received: (qmail 6423 invoked by uid 504); 11 Feb 1998 21:51:40 -0000 Original-Received: (qmail 6420 invoked from network); 11 Feb 1998 21:51:40 -0000 Original-Received: from camel14.mindspring.com (207.69.200.64) by claymore.vcinet.com with SMTP; 11 Feb 1998 21:51:40 -0000 Original-Received: from ashanti.mastaler.com (ip174.albuquerque.nm.pub-ip.psi.net [38.11.185.174]) by camel14.mindspring.com (8.8.5/8.8.5) with ESMTP id QAA08680 for ; Wed, 11 Feb 1998 16:51:37 -0500 (EST) Original-Received: (from jason@localhost) by ashanti.mastaler.com (8.8.5/8.8.5) id OAA06395; Wed, 11 Feb 1998 14:48:15 -0700 (MST) Original-To: ding@gnus.org In-Reply-To: Lars Magne Ingebrigtsen's message of "10 Feb 1998 20:21:46 +0100" Original-Lines: 51 X-Mailer: Quassia Gnus v0.23/XEmacs 20.5(beta24) - "Kaghani" Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:13924 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:13924 To add to the discussion, here is an argument against Mail-Followup-To from Keith Moore that appeared on the nmh list today. ------- Forwarded Message Date: Wed, 11 Feb 1998 14:20:25 -0500 From: Keith Moore To: Richard Coleman cc: nmh-workers@math.gatech.edu, exmh-users@sunlabs.eng.sun.com, moore@cs.utk.edu Subject: Mail-{Reply,Followup}-To considered harmful 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. Reply-To is widely misinterpreted as the replacement for the From field in replies, in such a way that "reply all" goes to Reply-To + To + Cc if Reply-To is present and From + To + CC if no Reply-to field is present. RFC 822 has language that appears to support this view. But a careful reading of RFC 822 reveals that this prose does not apply to Reply-To with respect to a "reply all" function, but only with the use of Reply-To in a "reply to author" function. This leaves us with the situation where the author of a message is unable to specify the complete destination for replies. Even if the author specifies a Reply-To field, if the recipient uses "reply all", addresses from the To and CC field are still included. This is the behavior implemented by almost every UA in existence, but it's almost always the wrong thing to do. And RFC 822's examples make it clear that Reply-To is intended as the *complete* destination for replies, not merely a replacement for the From field. The right way to fix this is to correctly interpret Reply-To - not as simply the replacement for the From field in replies, but as the reply destination preferred by the author of the subject message. Adding new headers doesn't fix the problem. It only makes the situation more complex. -- Keith Moore http://www.cs.utk.edu/~moore/ Citizen of cyberspace, currently residing in Knoxville, TN, US, Earth. ------- End of Forwarded Message