roberts@nimrod.wpd.sgi.com (roberts) (03/02/91)
As sendmail currently works, errors are sent to both the sender of a message, and to any addresses contained in an Errors-To: header. This seems incorrect to me. Shouldn't the address(es) contained in any Errors-To: header supercede any other addresses for receiving errors? Isn't that what the header was designed for? This would seem analogous to the Reply-To: header. Comments please. - Robert Stephens
moore@chili.cs.utk.edu (Keith Moore) (03/03/91)
In article <88419@sgi.sgi.com>, roberts@nimrod.wpd.sgi.com (roberts) writes: |> As sendmail currently works, errors are sent to both the sender |> of a message, and to any addresses contained in an Errors-To: |> header. This seems incorrect to me. Shouldn't the address(es) |> contained in any Errors-To: header supercede any other addresses |> for receiving errors? Isn't that what the header was designed for? |> This would seem analogous to the Reply-To: header. Comments please. |> |> - Robert Stephens Errors-to: is not officially sanctioned by the RFCs, which dictate that errors should be reported to the *envelope* From: address (which is supposed to be copied to the Return-path: header during final delivery). So just because sendmail recognizes the Errors-to: header and does something useful with it does not relieve it of its obligation to report errors to the envelope From: address. -- Keith Moore / U.Tenn CS Dept / 107 Ayres Hall / Knoxville TN 37996-1301 Internet: moore@cs.utk.edu BITNET: moore@utkvx
mib@wookumz.ai.mit.edu (Michael I Bushnell) (03/05/91)
In article <1991Mar2.212126.3567@cs.utk.edu> moore@chili.cs.utk.edu (Keith Moore) writes:
Errors-to: is not officially sanctioned by the RFCs, which dictate
that errors should be reported to the *envelope* From: address (which
is supposed to be copied to the Return-path: header during final
delivery). So just because sendmail recognizes the Errors-to: header
and does something useful with it does not relieve it of its
obligation to report errors to the envelope From: address.
Ack! No! The errors go to the Sender:, and if that field isn't there,
to the From:.
-mibmoore@cs.utk.edu (Keith Moore) (03/05/91)
In article <MIB.91Mar4160611@wookumz.ai.mit.edu> mib@wookumz.ai.mit.edu (Michael I Bushnell) writes: >In article <1991Mar2.212126.3567@cs.utk.edu> moore@chili.cs.utk.edu (Keith Moore) writes: > > Errors-to: is not officially sanctioned by the RFCs, which dictate > that errors should be reported to the *envelope* From: address (which > is supposed to be copied to the Return-path: header during final > delivery). So just because sendmail recognizes the Errors-to: header > and does something useful with it does not relieve it of its > obligation to report errors to the envelope From: address. > >Ack! No! The errors go to the Sender:, and if that field isn't there, >to the From:. > > -mib Okay, I'll elaborate to make myself clearer. RFC821 clearly says that any errors in message transfer should get reported to the argument to the SMTP MAIL FROM command, which is copied to the RFC822 Return-path header on delivery. Of course, this only applies to SMTP transfers. RFC822 does indeed say that errors should be reported to the address in the Sender header, if present. Therefore, if a Sender: address is present in the original message, that address should appear in SMTP's MAIL FROM command instead of the From: address. Similarly, when RFC822 style messages are used with other kinds of mail transport, the Sender address from the header, if present, should be copied to the envelope From: address (e.g. the UUCP "From " line) so that errors will be sent to whoever actually sent the message. MTAs (other than gateways) should probably not even look at headers, and should certainly not send error messages to header addresses. Keith -- -- Keith Moore / U.Tenn CS Dept / 107 Ayres Hall / Knoxville TN 37996-1301 Internet: moore@cs.utk.edu BITNET: moore@utkvx
lear@turbo.bio.net (Eliot) (03/05/91)
mib@wookumz.ai.mit.edu (Michael I Bushnell) writes: >Ack! No! The errors go to the Sender:, and if that field isn't there, >to the From:. You're wrong. See RFC 1123 section 5.3.3. Errors go to the sender, AS SPECIFIED IN THE ENVELOPE. They SHOULD NOT go to any address based on header information. This applies to the internet community, but should hold true for UUCP, as well. BITNET is another story. Here's the text: [...] If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message. This notification MUST be sent using a null ("<>") reverse path in the envelope; see Section 3.6 of RFC-821. The recipient of this notification SHOULD be the address from the envelope return path (or the Return-Path: line). However, if this address is null ("<>"), the receiver-SMTP MUST NOT send a notification. If the address is an explicit source route, it SHOULD be stripped down to its final hop. -- Eliot Lear [lear@turbo.bio.net]
david@twg.com (David S. Herron) (03/06/91)
In article <MIB.91Mar4160611@wookumz.ai.mit.edu> mib@wookumz.ai.mit.edu (Michael I Bushnell) writes: >In article <1991Mar2.212126.3567@cs.utk.edu> moore@chili.cs.utk.edu (Keith Moore) writes: > > Errors-to: is not officially sanctioned by the RFCs, which dictate > that errors should be reported to the *envelope* From: address (which > is supposed to be copied to the Return-path: header during final > delivery). So just because sendmail recognizes the Errors-to: header > and does something useful with it does not relieve it of its > obligation to report errors to the envelope From: address. > >Ack! No! The errors go to the Sender:, and if that field isn't there, >to the From:. > > -mib Aack! Aack! No! No! Like the gent said.. errors are supposed to be returned to the ****envelope**** From: address. If you're doing SMTP then that's the address in MAIL FROM:<>. If that address is empty then the error should be dropped on the floor. The RFC doesn't, as I recall, specify where to send errors if the envelope return address has been lost. However that usually only happens when the message is delivered and not a moment before... David -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future
roy@phri.nyu.edu (Roy Smith) (03/07/91)
moore@cs.utk.edu writes: > Errors-to: is not officially sanctioned by the RFCs, which dictate that > errors should be reported to the *envelope* From: address (which is > supposed to be copied to the Return-path: header during final delivery). The problem is that Errors-to: is a very useful thing to have, or at least it's useful to have the same functionality. If I send something to a mailing list, I certainly don't want to see dozens of error messages pouring back into my box about delivery errors to people I've never heard of just because they happen to be on the mailing list. What is the "right way" to set up the headers on mail resent from a mail reflector so that replies go back to the originator (and/or the whole mailing list) but that error messages get sent to the mailing list maintainer? -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy "Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"
urlichs@smurf.sub.org (Matthias Urlichs) (03/07/91)
In comp.mail.headers, article <8711@gollum.twg.com>,
david@twg.com (David S. Herron) writes:
<
< Like the gent said.. errors are supposed to be returned to the
< ****envelope**** From: address. If you're doing SMTP then that's
< the address in MAIL FROM:<>. If that address is empty then the
< error should be dropped on the floor.
<
I've found that dropping that error message into the local Postmaster mailbox
instead is a good way to catch various runaway errors.
< The RFC doesn't, as I recall, specify where to send errors if the
< envelope return address has been lost. However that usually only
< happens when the message is delivered and not a moment before...
<
It happens, esp. when gating to stupid BBS networks that don't distinguish
between header and envelope addresses.
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/tneff@bfmny0.BFM.COM (Tom Neff) (03/07/91)
In article <1991Mar6.172315.1112@phri.nyu.edu> roy@phri.nyu.edu (Roy Smith) writes: > What is the "right way" to set up the headers on mail resent from a >mail reflector so that replies go back to the originator (and/or the whole >mailing list) but that error messages get sent to the mailing list >maintainer? Try this: From: jblow@deadend.com (Joe Blow) To: thelist@listsite.org (The Mailing List) Subject: Whatever This Is About Reply-To: thelist@listsite.org Errors-To: thelist-request@listsite.org Sender: thelist-request@listsite.org with the "envelope from" field set to "thelist-request", and the "envelope to" fields set to the addresses of the individual recipients. If you want default replies to go to the submitter, omit Reply-To:.
moore@chili.cs.utk.edu (Keith Moore) (03/07/91)
In article <1991Mar6.172315.1112@phri.nyu.edu>, roy@phri.nyu.edu (Roy Smith) writes: |> What is the "right way" to set up the headers on mail resent from a |> mail reflector so that replies go back to the originator (and/or the whole |> mailing list) but that error messages get sent to the mailing list |> maintainer? There are several ways to mung list headers so that replies go to the entire list. One way is not to change them at all, if people's mailers are smart enough to be able to reply to all recipients of a message. Another way is to add a Reply-to header, but only if there's not one there already. This allows a list contributor to specify that replies should be sent to him/her rather than the entire list, if he/she supplies his/her own Reply-to address with the message. The error-message address isn't supposed to be determied by headers. You need to set the envelope from address. One way to do this with sendmail is to use the -f command-line option, but you may have to make sure you are running as a "trusted user". Since some non-Internet mail paths lose envelope information, you may find it useful to include an Errors-to header also, but its address should be the same as the envelope from address. -- Keith Moore / U.Tenn CS Dept / 107 Ayres Hall / Knoxville TN 37996-1301 Internet: moore@cs.utk.edu BITNET: moore@utkvx
roy@phri.nyu.edu (Roy Smith) (03/07/91)
lear@turbo.bio.net (Eliot) writes: > You're wrong. See RFC 1123 section 5.3.3. Errors go to the sender, AS > SPECIFIED IN THE ENVELOPE. They SHOULD NOT go to any address based on > header information. Can somebody explain to me the reason they made it this way? It seems counter-intuitive to "hide" information in the envelope, when the headers are a perfectly reasonable place to put everything you need to know. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy "Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"
jch@hollie.rdg.dec.com (John Haxby) (03/07/91)
In article <1991Mar7.012743.12895@phri.nyu.edu>, roy@phri.nyu.edu (Roy Smith) writes: |> lear@turbo.bio.net (Eliot) writes: |> > You're wrong. See RFC 1123 section 5.3.3. Errors go to the sender, AS |> > SPECIFIED IN THE ENVELOPE. They SHOULD NOT go to any address based on |> > header information. |> |> Can somebody explain to me the reason they made it this way? It |> seems counter-intuitive to "hide" information in the envelope, when the |> headers are a perfectly reasonable place to put everything you need to know. That's not a trivial question. To begin with, the content is (more-or-less) hidden from the envelope, not the other way around. When you send a message through the paper postal system, the content can't see the envelope because it is inside it, and vice versa. Similarly, the return address that you write on the outside of the envelope is the one that the letter will go back to when your ex- marks it "return to sender" (you may burst into song, if you must :-) The way the physical postal system works is hardly a justification, but it provides some history. However, history is important because mail systems based around non-IDA sendmail treat the envelope and content almost identically. However, IDA-based sendmail systems and other mail systems (the ones I know of) *do* treat the envelope and content differently. Specifically, the return address (MAIL FROM:<...>) on the envelope is modified to reflect the message's path across the continent; the idea being that any rejection will follow a guaranteed path to the originator, that is, back the way it came. Addresses on the content, however, are supposed to be nice and readable, they are also supposed to work, but may not for strange reasons. If I think about this long enough, I can think of all sorts of other reasons why the content and envelope should be different. For an example, consider UUCP-style routing. The trouble with this is that you wind up with very long return addresses, I'm sure you've seen examples. The snag with these long return addresses is that, whilst they almost always work, they are equally almost always inefficient and whilst they will probably work for the next few days, they may not work a few weeks or few months hence because machine connectivity changes. The usual policy here is to knock off leading components of the route until you get to the last known host. If you then try to use this as an address to send errors to, you can come badly unstuck because, for example, the (different) route that you choose to send the return address to may not be available for a few days. There is this possibility when you send a message back along the route it came, but, typically, the error is winging its way back within a few hours or a few minutes of the original optimistically winging its way out. With all that to think about, the short and snappy answer is that the envelope sender address is more reliable than the header sender address for the purposes of error messages. The other answer, which I haven't mentioned, that other mail systems may give, is that the envelope sender address is validated whereas the content header sender address isn't (I don't believe this for sendmail-based mail systems and, to a lesser extent, for SMTP/RFC822-based mail systems). -- John Haxby, Definitively Wrong. Digital <jch@wessex.rdg.dec.com> Reading, England <...!ukc!wessex!jch>
tneff@bfmny0.BFM.COM (Tom Neff) (03/07/91)
In response to my suggested header suite for articles distributed via mailing list, Eliot Lear sez >Leave the user's headers alone (if you must add Errors-to, that's the >least offensive). DON'T change the default semantics of the >recipient's MUA. Doing so will cause embarrassing situations, with >private mail being posted to a public list or to the -request address, >*depending on the mailer*. Follow RFC-1123. After a few years playing with it, I have decided that where wideband public mailing lists are concerned, reliable distribution takes precedence over the sanctity of headers. This is a matter of competing paradigms. Where the goal is reliable one-to-one mail transmission, all the carefully worked out RFC strictures should indeed apply. But a worldwide mailing list is a different beast. It is more like an electronic periodical for public discussion of selected topics. Its priority should be to make continuing the discussion as easy as possible, while filtering out as much noise as possible. Unfortunately the RFC encoded notion of a "mailing list" is much closer to a corporate in-house memo distribution. Instead of just messaging Joe in Sales, we want to be able to distribute the weekly report to {Joe in Sales, Ann in Marketing, Ed in Administration, and Renee on Mahogany Row}. Everyone can reasonably be expected to be addressed the same way, errors and other garbage can be fixed by picking up the phone, and anyone who wants to "reply" to my weekly report does so to me, not to the list as a whole. This is not how it's worked out in the real world. Despite the growth of Netnews, big mailing lists are still thriving, with members scattered on strange networks all over the planet. When hard working moderators try to play by all the nice RFC rules and handle huge mailing lists "by the book," the results are simple: Stuff bounces like crazy, replies fail by the hundreds, discussion languishes more than necessary, and an unacceptable portion of the moderator's time ends up being spent babysitting others' balky mailers instead of devoting creative time to whatever beloved hobby or topic inspired the mail list in the first place. My approach is different. If you send private mail to someone at, from or through my site, you get all the virtuous RFC mandated behavior, as it should be. But if you send something to one of my mail list addresses, you are in effect submitting a piece for publication, and I reserve the right to massage it into conformance with my delivery structure. If it looks like administrivia or a mailer hiccup, I sideline it pending moderator intervention. If it's a legitimate article, I repost it in multiple versions -- one each for Internet, UUCP, BITNET, CompuServe, MCI Mail, and so forth. Each version has a customized header designed to help it survive its journey to subscribers' mailboxes, while routing replies to the list and errors to me. In this way everything connects. I choose to handle subscription requests manually, in order to make sure weird stuff doesn't get into the rosters. But in exchange, I can take two weeks off when I want to without having to shut down the lists.
Craig_Everhart@TRANSARC.COM (03/08/91)
I'll guess that the headers as specified in RFC 822 are meant for UA-to-UA communication, and that the envelope was seen as being the province of the MTA. Seems clean enough. Certainly there are enough UA (user agent) concerns with the meanings of the various headers that you shouldn't overload automatic MTA processing onto them as well. Unfortunately, people do. (Some of them advocate changing all applicable headers on message redistribution, too, which I think is a bad idea.) Craig
lear@turbo.bio.net (Eliot) (03/08/91)
[In reply to referenced article by Tom Neff.] Leave the user's headers alone (if you must add Errors-to, that's the least offensive). DON'T change the default symantics of the recipient's MUA. Doing so will cause embarrassing situations, with private mail being posted to a public list or to the -request address, *depending on the mailer*. Follow RFC-1123. -- Eliot Lear [lear@turbo.bio.net]
lear@turbo.bio.net (Eliot) (03/08/91)
roy@phri.nyu.edu (Roy Smith) writes: > Can somebody explain to me the reason they made it this way? It >seems counter-intuitive to "hide" information in the envelope, when the >headers are a perfectly reasonable place to put everything you need to know. The information is only hidden in the sense that it is not used to route information. Some mailers do in fact expose that information to the user in the form of "From ", Return-Path:, et al. The information cannot be solely used to route because it would be impossible to have replyable mailing lists. Also, imagine, Roy, a list with 200 recipients at various hosts. Imagine what the To: line would look like. Finally, it is often times desirable to hide information from the recipients. -- Eliot Lear [lear@turbo.bio.net]
lear@turbo.bio.net (Eliot) (03/08/91)
tneff@bfmny0.BFM.COM (Tom Neff) writes: >After a few years playing with it, I have decided that where wideband >public mailing lists are concerned, reliable distribution takes >precedence over the sanctity of headers. After a few years of dealing with this issue, and after having chase down a number of embarrassing messages before they were widely distributed, I've come to the opposite conclusion. Indeed I would argue that this is a failing of the Internet mail system, that it has not made clear the distinction between wide replies and replies to senders. >This is not how it's worked out in the real world. Despite the growth >of Netnews, big mailing lists are still thriving, with members scattered >on strange networks all over the planet. I would agree that even with netnews, big mailing lists will be with us for a while. Nevertheless, changing the behavior in the MUAs from that of what both the sender and receiver expect is something that mailing list moderators should not be doing. By whacking the headers that you describe, you inhibit the sender's ability to redirect replies as he deems appropriate (like maybe to a return account). By redirecting those replies to a public list, you risk causing novice users to broadcast private mail. That's a tradeoff the IETF considers too expensive. In fact, because some networks use address as the errors-to address (bad practice), mailing list loops can develop as a result of setting the reply-to address automatically tom the list. Nothing pisses off members of a mailing list more than a mailing list loop. -- Eliot Lear [lear@turbo.bio.net]
tneff@bfmny0.BFM.COM (Tom Neff) (03/09/91)
(This discussion is wandering around between groups -- I'll try to corral it together again.) In article <Mar.7.16.48.39.1991.4929@turbo.bio.net> lear@turbo.bio.net (Eliot) writes: >tneff@bfmny0.BFM.COM (Tom Neff) writes: >>After a few years playing with it, I have decided that where wideband >>public mailing lists are concerned, reliable distribution takes >>precedence over the sanctity of headers. > >After a few years of dealing with this issue, and after having chase >down a number of embarrassing messages before they were widely >distributed, I've come to the opposite conclusion. OK, but wait. Let's talk about accidental distribution of "embarassing messages." There are several kinds of that animal. One kind is misdirected administrivia, like "UNSUB joe@foo.com" being sent to the list, or almost anything that fits in one line (I find, empirically). We see this all the time on BITNET lists and such. My response is to **FILTER** anything that looks suspicious. It's not hard to do. Anything matching a list of trigger phrases, or anything shorter than about three nonempty lines, or anything from daemons, roots or other such entities, goes right into my hold box. I prefer to err on the side of discretion, but over time I have refined what does and doesn't pass. Another type of "embarassing message" is original text, not self evidently administrivia, from a poster who actually meant it to go somewhere else than the whole membership, e.g., misdirected private replies. This is a bit more complex, since the judgment whether something's misdirected can take some careful reading. Nevertheless, simple filters can be of help here too: peeling off anything with a secondary /^To:/ buried in the text, or anything asking someone to 'call me at', etc. Once a mail list membership gets USED TO an environment where only public discussion is delivered to their desks, they tend to cast their replies in discussion form rather than assuming that private replies are the norm. That cuts significantly down on the number of interventions I have to do. I can and do also filter for "problem members" with a record of questionable submissions; their stuff goes into hold just for safety's sake until I can look it over and wave it through. I also make it a point to let new members KNOW what the rules are, and where replies go by default. I also tell people that if they need to make an exception, as with a club formation announcement where the poster really wants replies to go directly to him rather than to the list, it's very easy for me to accomodate. All the poster need do is send his message to the -request address, with a cover note. That should be the exceptional message, not the norm. >I would agree that even with netnews, big mailing lists will be with >us for a while. Nevertheless, changing the behavior in the MUAs from >that of what both the sender and receiver expect is something that >mailing list moderators should not be doing. When someone submits a piece to one of my lists, *I* am the receiver, so never mind what I expect. What the sender expects should be entirely conditioned by the ground rules explained when they joined. Again, I am not talking about private mail here. That goes through in fine RFC821/1123 style. In exchange for asking me to perform the service of broadcasting their words to hundreds of readers worldwide, I ask readers to bear with me as I manage the headers. And I have had zero complaints from the membership. > By whacking the headers >that you describe, you inhibit the sender's ability to redirect >replies as he deems appropriate (like maybe to a return account). What I inhibit is the sender's ability to siphon discussion away from the list _automatically_ by including some header line in his submission. I deem this in the list's interest, and an acceptable risk given the noise filters in place. Any member with a legitimate need for a posting whose replies will be directed back to him, or elsewhere, need only send the message to -request with a cover note. > By >redirecting those replies to a public list, you risk causing novice >users to broadcast private mail. That's a tradeoff the IETF considers >too expensive. Considering the many megabytes of verbiage IETF has churned out, I am genuinely impressed when it decides something is "expensive"! >In fact, because some networks use address as the errors-to address >(bad practice), mailing list loops can develop as a result of setting >the reply-to address automatically tom the list. Nothing pisses off >members of a mailing list more than a mailing list loop. Prevented by a filter, which however hasn't recorded an actual instance of this in eighteen months. In article <8bpwIu70BwwO8_5kwe@transarc.com> Craig_Everhart@TRANSARC.COM writes: >I think I've had this discussion with Tom Neff already. Sigh. My apologies for being slow to realize that this issue had already taken its place on the planetary "It's OK, Craig's Discussed It" honor roll! :-)
rlk@think.com (Robert Krawitz) (03/09/91)
[This discussion is going on in header-people, too].
In article <Mar.7.16.48.39.1991.4929@turbo.bio.net>, lear@turbo (Eliot) writes:
]I would agree that even with netnews, big mailing lists will be with
]us for a while. Nevertheless, changing the behavior in the MUAs from
]that of what both the sender and receiver expect is something that
]mailing list moderators should not be doing. By whacking the headers
]that you describe, you inhibit the sender's ability to redirect
]replies as he deems appropriate (like maybe to a return account). By
]redirecting those replies to a public list, you risk causing novice
]users to broadcast private mail. That's a tradeoff the IETF considers
]too expensive.
With all due respect, this is not the IETF's decision to make, but
rather it should be left in the hands of the people who maintain lists.
A large mailing list has more in common with a bulletin board than a
private discussion, and the ground rules (whether it's appropriate to
respond to the list at all, whether it's appropriate to respond
personally to someone not on the list) need to be determined on a case
by case basis. I claim that the sender has only a secondary right to
direct replies, and that the moderator has the right to determine the
primary reply policy (which of course can be overridden by the
recipient).
]In fact, because some networks use address as the errors-to address
](bad practice), mailing list loops can develop as a result of setting
]the reply-to address automatically tom the list. Nothing pisses off
]members of a mailing list more than a mailing list loop.
...which is unfortunate, but true. Another reason why list maintainers
need the freedom to set up headers as they (we) see fit.
--
ames >>>>>>>>> | Robert Krawitz <rlk@think.com> 245 First St.
bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142
harvard >>>>>> . Thinking Machines Corp. (617)234-2116lear@turbo.bio.net (Eliot) (03/10/91)
tneff@bfmny0.BFM.COM (Tom Neff) writes: >OK, but wait. Let's talk about accidental distribution of "embarassing >messages." [... You didn't mention the case where a representative of a funding agency posts confidential information, accidentally. This has happened. Even with the bionet side of the mailing lists, we see little goofs like these all the time (about once a month); this because (among other things) the lists are redistributed by LISTSERV in some places, which whacks Reply-to and Sender. >Once a mail list membership gets USED TO an environment where only >public discussion is delivered to their desks, they tend to cast their >replies in discussion form rather than assuming that private replies are >the norm. That cuts significantly down on the number of interventions I >have to do. I can and do also filter for "problem members" with a >record of questionable submissions; their stuff goes into hold just for >safety's sake until I can look it over and wave it through. In other words, each mailing list will have different Reply symantics, and that's a nightmare. If a user is subscribed to half a dozen mailing lists, they'll never remember the ``rules''. >I also make it a point to let new members KNOW what the rules are, and >where replies go by default. I also tell people that if they need to >make an exception, as with a club formation announcement where the >poster really wants replies to go directly to him rather than to the >list, it's very easy for me to accomodate. All the poster need do is >send his message to the -request address, with a cover note. That >should be the exceptional message, not the norm. This means that the sender cannot expect the appropriate behavior of his mail message, sometimes, given whatever ``list rules'' are in effect. So the end result is that the sender is stripped of the functionality of a reply-to mechanism. Maybe we *really* need a followup field in RFC-822 messages, for purposes of posting to the list. Thus both the sender and the mailing list coordinator could be accommodated. >When someone submits a piece to one of my lists, *I* am the receiver, so >never mind what I expect. Bull. It is the behavior of the MUAs used by the hundreds of users you serve that you are mucking with. To be perfectly honest with you, I *myself* get quite frustrated with you adding a followup-to line, because you are modifying my reader's default behavior (the reason it bothers me is that you are fragmenting discussion). AND HERE the paradigm is established and accepted!!! >What the sender expects should be entirely >conditioned by the ground rules explained when they joined. Again, I am >not talking about private mail here. That goes through in fine >RFC821/1123 style. First of all, RFC-821 has to do with the envelope, so it's not really envolved. Second, while RFC-1123 deals with mailing lists, it makes no mention of the Sender: or Reply-to: headers. So your statement is in error. >In exchange for asking me to perform the service of broadcasting >their words to hundreds of readers worldwide, I ask readers to bear >with me as I manage the headers. And I have had zero complaints from >the membership. Obviously you should be pushing netnews a lot more than you are. I've been doing so with molecular biologists for the past several years, and have had very good success. >What I inhibit is the sender's ability to siphon discussion away from >the list _automatically_ by including some header line in his >submission. In doing so, you are modifying the recipient MUA's default behavior for reasons not intended by neither the original implementors, the sender, or the recipient. >I deem this in the list's interest, and an acceptable risk >given the noise filters in place. Any member with a legitimate need for >a posting whose replies will be directed back to him, or elsewhere, need >only send the message to -request with a cover note. And again, you are modifying the default behavior of every recipient's MUA; causing it to do something that most mailing lists don't do. That is extremely bad (again). >[unsubstantiated, silly, ad hominem attacks against the IETF deleted] >>In fact, because some networks use address as the errors-to address >>(bad practice), mailing list loops can develop as a result of setting >>the reply-to address automatically tom the list. Nothing pisses off >>members of a mailing list more than a mailing list loop. >Prevented by a filter, which however hasn't recorded an actual instance >of this in eighteen months. And the amount of filters you run on your machine would bring mine to its knees; that machine does mail for a living. In order to remove such duplicates, you would have to compare the text of the new message with the text of recent messages (within several days), and you'd better pray to your local email deity that the text hasn't been munged by the offending mailer. This had happened to us, thanks to a LISTSERV about once every three months. -- Eliot Lear [lear@turbo.bio.net]
lear@turbo.bio.net (Eliot) (03/10/91)
rlk@think.com (Robert Krawitz) writes: >With all due respect, this is not the IETF's decision to make, but >rather it should be left in the hands of the people who maintain lists. This attitude completely forgets what the user will have to go through, once subscribed to more than a handful of lists. Such large bulletin boards should be moved to netnews. Large number of them have; more should be. The more that do, the more people will join the net (admittedly not always viewed as a good thing). With any reasonable MUA (and even most unreasonable ones), the users have the ability to reply to the mailing list. *Don't* make them jump through hoops to communicate with individuals. -- Eliot Lear [lear@turbo.bio.net]
vixie@decwrl.dec.com (Paul A Vixie) (03/10/91)
>>With all due respect, this is not the IETF's decision to make, but >>rather it should be left in the hands of the people who maintain lists. >This attitude completely forgets what the user will have to go >through, once subscribed to more than a handful of lists. [...] A pity we can't just depend on users to look at the autogenerated "To:" and "Cc:" headers on their replies. I guess we'll have to solve this one with technology and specification, darn it. -- Paul Vixie DEC Western Research Lab <vixie@pa.dec.com> <paul@vixie.sf.ca.us> Palo Alto, California, USA ...!decwrl!vixie ...!vixie!paul
tneff@bfmny0.BFM.COM (Tom Neff) (03/11/91)
In article <Mar.9.15.26.06.1991.16205@turbo.bio.net> lear@turbo.bio.net (Eliot) writes: >tneff@bfmny0.BFM.COM (Tom Neff) writes: >>OK, but wait. Let's talk about accidental distribution of "embarassing >>messages." [... > >You didn't mention the case where a representative of a funding >agency posts confidential information, accidentally. This has >happened. Fine, let us mention it. Say we create NY-ARTS, mailing list devoted to the arts in New York State. We might very well get people from funding agencies like NYSCA on the list. If one of them posts confidential data publicly, am I to blame? They're not supposed to discuss that kind of thing via network mail of ANY kind, except their own in-house system. Anything you send out over the Internet ought to be assumed to be publicly readable. If someone is too lazy to look where their reply is going (it says right on the editing screen), and too irresponsible to keep confidential information off email networks where it has no business being, I'm not going to work up crocodile tears for them. >>Once a mail list membership gets USED TO an environment where only >>public discussion is delivered to their desks, they tend to cast their >>replies in discussion form rather than assuming that private replies are >>the norm. That cuts significantly down on the number of interventions I >>have to do. I can and do also filter for "problem members" with a >>record of questionable submissions; their stuff goes into hold just for >>safety's sake until I can look it over and wave it through. > >In other words, each mailing list will have different Reply symantics, >and that's a nightmare. If a user is subscribed to half a dozen >mailing lists, they'll never remember the ``rules''. It would be very hard to make EACH mailing list have different reply semantics: there are only two or three different things you can possibly do with replies, and there are hundreds of mailing lists out there! If you assiduously subscribe AND contribute to a lot of lists, you will soon run into each of these two or three kinds of reply semantics. If the semantics for each list are chosen for its intended use, there should be no "nightmare" involved, unless it is your intention as a reader to systematically confound such intended uses. If, for instance, a Daguerrotype hobby discussion list defaults replies to the list for everyone's edification -- BUT it is your intention as a reader to reply privately to everyone, regardless of the moderator's wishes -- BUT you're too ignorant to know how to configure your mail software in accordance with such a curmudgeonly whim -- THEN you will have trouble under my system! Life sure is tough sometimes. >>I also make it a point to let new members KNOW what the rules are, and >>where replies go by default. I also tell people that if they need to >>make an exception, as with a club formation announcement where the >>poster really wants replies to go directly to him rather than to the >>list, it's very easy for me to accomodate. All the poster need do is >>send his message to the -request address, with a cover note. That >>should be the exceptional message, not the norm. > >This means that the sender cannot expect the appropriate behavior of >his mail message, sometimes, given whatever ``list rules'' are in >effect. So the end result is that the sender is stripped of the >functionality of a reply-to mechanism. The sender cannot expect the ORDINARY, one-to-one mail behavior of his mail message to obtain. That is correct. A list submission is a different animal. If I mail you about something, I expect headers to be retained, semantics obeyed, and in general nothing messed with. If I submit something to RISKS or SIBERRY or NEW-LIST or 3D or TELECOM, I yield responsibility to the list maintainer to run things as he or she needs to in order to keep things sane. As long as my piece appears along with my address so that NON-fluffbrains can reach me, I am happy. > Maybe we *really* need a >followup field in RFC-822 messages, for purposes of posting to the >list. Thus both the sender and the mailing list coordinator could be >accommodated. It's an interesting idea, if you also add a Followup command to all the MUA's. Eventually you reinvent netnews with a different distribution scheme. Which wouldn't be bad -- a _local_ mail list to newsgroup gateway could be a popular piece of software. >>In exchange for asking me to perform the service of broadcasting >>their words to hundreds of readers worldwide, I ask readers to bear >>with me as I manage the headers. And I have had zero complaints from >>the membership. > >Obviously you should be pushing netnews a lot more than you are. I've >been doing so with molecular biologists for the past several years, >and have had very good success. Yes, but I reach more networks. Netnews doesn't go everywhere. >>What I inhibit is the sender's ability to siphon discussion away from >>the list _automatically_ by including some header line in his >>submission. > >In doing so, you are modifying the recipient MUA's default behavior I am doing no such thing! The recipient MUA's default behavior is whatever it is. I can hardly patch the receipient's software. Instead, I tailor postings to *accommodate* the default behavior of many MUAs, within the overall design of the lists. >for reasons not intended by neither the original implementors, the >sender, or the recipient. Whose intentions would not override mine even if they were spelled out, which they are not. >And the amount of filters you run on your machine would bring mine to >its knees; that machine does mail for a living. For list submissions only? I doubt it. They're not that expensive anyway, a little parsing. And ordinary mail goes through unmolested. The overhead for proper list filtering is very small. > In order to remove >such duplicates, you would have to compare the text of the new message >with the text of recent messages (within several days), and you'd >better pray to your local email deity that the text hasn't been munged >by the offending mailer. This had happened to us, thanks to a >LISTSERV about once every three months. If you look at the headers of error messages, you can characterize them as such, which is what I do. Text comparison isn't necessary.