Xref: utzoo comp.mail.misc:5023 comp.mail.sendmail:2829 comp.mail.headers:659 Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bfmny0!tneff From: tneff@bfmny0.BFM.COM (Tom Neff) Newsgroups: comp.mail.misc,comp.mail.sendmail,comp.mail.headers Subject: Re: Use of Errors-To: (LONG, how'd that happen?) Message-ID: <60419803@bfmny0.BFM.COM> Date: 11 Mar 91 08:14:57 GMT References: <4081344@bfmny0.BFM.COM> Reply-To: tneff@bfmny0.BFM.COM (Tom Neff) Followup-To: comp.mail.misc Lines: 125 In article 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.