Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA28857; Sun, 26 Oct 1997 15:58:11 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.7); Sun, 26 Oct 1997 15:56:24 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id PAA28766; Sun, 26 Oct 1997 15:56:23 -0500 (EST) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id PAA28755; Sun, 26 Oct 1997 15:56:20 -0500 (EST) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id PAA22542; Sun, 26 Oct 1997 15:56:23 -0500 (EST) Message-Id: <199710262056.PAA22542@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Eric S. Raymond" cc: drums@cs.utk.edu, moore@cs.utk.edu Subject: Re: REPLY problem list (draft #1) In-reply-to: Your message of "Sun, 26 Oct 1997 13:07:25 EST." <19971026130725.62133@snark.thyrsus.com> Date: Sun, 26 Oct 1997 15:56:23 -0500 Sender: moore@cs.utk.edu > > And if you accept that, then you also can't write down any general rules > > about what mailing lists are, or are not, allowed to do either, as there's > > no clear dividing line between what is a mailing list and what is a user, > > Sorry, I don't really buy this -- at least, not in the context of this > argument. Messages have an origin point (operationally, where their > message-ID and From header was generated). Everything after that is a > relay. > > I know it used to be relatively common for Internet relays to mung > From headers. We don't do that anymore, the tsuris got to be too > awful. What I'm suggesting is that Reply-To ought to be considered > "sacred" in the same way From is, and for the same reasons. About MUST vs. SHOULD: The thing is, there are still things out there that need to mung From and Reply-to. For instance, there are lists that anonymize their submissions and have to mung From and Reply-To to function at all. And there are probably lists that do munging for other good and worthwhile reasons. Maybe these are exceptional cases, but they're going to continue to exist. If we say "mailing lists MUST NOT mung From or Reply-To", then these exceptional things will start calling themselves something besides mailing lists, and therefore outside of the purview of 822bis. If we say "mailing lists SHOULD NOT mung From or Reply-To", where SHOULD is as defined in RFC 2119, then the exceptional things can claim that they have a reason to make an exception to this rule, as long as they comply with other portions of 822bis. Using SHOULD NOT can be more effective than using MUST NOT, because even if a particular list takes exception to one or two rules, it has to justify that doing so is a special case. And the list will still try to comply with the other rules. It's also possible to say things like "SHOULD NOT do X, and MUST NOT do X for reason Y". About lists and Reply-To: While I'm sympathetic to not the idea that lists should not mung Reply-To, I think we need to consider the transition issues. Assuming that: a) the goal for headers is clear labelling of who sent the message, where the message was sent, and who wants what kind of reply behavior, so that the recipient or his UA can make an informed choice about where the reply goes, and b) lists currently use Reply-To more often than people do, and c) such lists usually (certainly not always) do "the right thing" The reply needs to go where the list says it should go in more cases than not, and people who use the list have created an etiquette for that list to which assumes that behavior for replies, and d) if we tell the lists to do things a different way, which requires support in UAs, and that support doesn't exist yet, and won't exist for some time, they'll continue to use reply-to for many more years. then we'll get a smoother and faster transition if we define a new author-specified-reply-to field for use by the author,. and perhaps also a list-specified-reply-to field for use by lists, but continue to allow both authors and lists to use Reply-To for backward compatibility with existing UAs. ("smoother transition" = it won't get worse before it gets better.) the drawback of this approach is that we end up with a slightly more complex message header for many years until plain old reply-to can be deprecated. Keith