Re: mail headers for announce
The recipient list is a pretty poor way to deal with things when you get mail sent to multiple lists you're on, and often the To: line ends up with nothing at all. The Return-Path: is generally the surest way to know which of the lists each of the messages was sent to. I've tried lots of things over the years, and Return-Path: is what works the best. I'm on a few hundred mailing lists so the matter is somewhat important to me. On the other hand, when someone replies to you on most mailing-lists (To: you, Cc: m-l), at least _I_ don't want those hundreds of messages in my inbox, rather in the respective folders (both direct mail and the mailing-list version with Return-Path:). some people want the personal copies, some don't. I like to maintain reliable archives of the lists to which I subscribe, and having a separate address for each list works well for that. but it does mean that if a message is cross-posted to multiple lists to which I subscribe, I get a separate copy of the message from each list, in addition to any personal copies I might have received. duplicate suppression is best done on the recipient end. unfortunately for the cause of duplicate suppression there is a trend toward lists munging messages more and more (adding trailers or frobs to subject lines). I have a fair number of filters to remove those frobs from subject lines - not only do they alter the messages, they make one-line-per-message summaries (e.g. from/date/subject) harder to read. Keith
Re: mail headers for announce
Perry, Wednesday, October 30, 2002, 1:38:54 PM, you wrote: Perry As I use Return-Path: headers to filter my mail, this has gotten Perry annoying, Yes, I can indeed kludge around it, but is there a Perry particular reason for this being done? Using return-path is a bit like paying attention to what mailbox a postal letter is dropped into. looking for ietf-announce in the recipient list works better. d/ -- Dave Crocker mailto:dave;tribalwise.com TribalWise http://www.tribalwise.com t +1.408.246.8253; f +1.408.850.1850
Re: mail headers for announce
Dave Crocker wrote: Using return-path is a bit like paying attention to what mailbox a postal letter is dropped into. Or perhaps what post offices it went through on the way. -- /===\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: mail headers for announce
On 30 Oct 2002, Perry E. Metzger wrote: Dave Crocker [EMAIL PROTECTED] writes: Wednesday, October 30, 2002, 1:38:54 PM, you wrote: Perry As I use Return-Path: headers to filter my mail, this has gotten Perry annoying, Yes, I can indeed kludge around it, but is there a Perry particular reason for this being done? Using return-path is a bit like paying attention to what mailbox a postal letter is dropped into. looking for ietf-announce in the recipient list works better. The recipient list is a pretty poor way to deal with things when you get mail sent to multiple lists you're on, and often the To: line ends up with nothing at all. The Return-Path: is generally the surest way to know which of the lists each of the messages was sent to. I've tried lots of things over the years, and Return-Path: is what works the best. I'm on a few hundred mailing lists so the matter is somewhat important to me. On the other hand, when someone replies to you on most mailing-lists (To: you, Cc: m-l), at least _I_ don't want those hundreds of messages in my inbox, rather in the respective folders (both direct mail and the mailing-list version with Return-Path:). The approach looks suitable if one is relatively passive on the mailing lists. -- Pekka Savola Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
mail headers for announce
There are now apparently TWO servers sending out ietf-announce mail, with different envelope senders. This started happening today. As I use Return-Path: headers to filter my mail, this has gotten annoying, Yes, I can indeed kludge around it, but is there a particular reason for this being done? -- Perry E. Metzger[EMAIL PROTECTED]
Re: mail headers for announce
Dave Crocker [EMAIL PROTECTED] writes: Wednesday, October 30, 2002, 1:38:54 PM, you wrote: Perry As I use Return-Path: headers to filter my mail, this has gotten Perry annoying, Yes, I can indeed kludge around it, but is there a Perry particular reason for this being done? Using return-path is a bit like paying attention to what mailbox a postal letter is dropped into. looking for ietf-announce in the recipient list works better. The recipient list is a pretty poor way to deal with things when you get mail sent to multiple lists you're on, and often the To: line ends up with nothing at all. The Return-Path: is generally the surest way to know which of the lists each of the messages was sent to. I've tried lots of things over the years, and Return-Path: is what works the best. I'm on a few hundred mailing lists so the matter is somewhat important to me. -- Perry E. Metzger[EMAIL PROTECTED]
Re: mail headers for announce
Dave Crocker [EMAIL PROTECTED] writes: ... Using return-path is a bit like paying attention to what mailbox a postal letter is dropped into. That analogy is quite good, and cuts both ways. While you cannot rely completely on envelope or header return addresses or postmarks, in practice they are almost always right and generally good enough. The majority of spam that does carry return addresses pointing to other than the spammer's obvious address is not forged in the sense that the spammer has no legitimate claim on the address. For example, if you read the fine print in the announcements of terminated addresses from Hotmail, you'll notice that Hotmail says that those forged addresses were once owned by the spammers. The laws against header forgery in various jurisdictions and the interest of many (but not all) spammers in collecting bounces to clean their lists are likely sounding reasons for the low rate of true header forgery. In other words, when was the last time you saw spam carrying genuinely forged @ietf.org header or envelope from addresses? When you really need to care about forgery, I trust you use industrial strength mechanisms. looking for ietf-announce in the recipient list works better. While that may be work for ietf-announce and other IETF lists, it simply does not work for other mailing lists. It also is in general a worse way to filter spam than watching return addresses, because many spammers include various strings in the To and Cc headers. They can't get in trouble for doing that, they don't lose any bounces, and it does get around some filters. From: Perry E. Metzger [EMAIL PROTECTED] The recipient list is a pretty poor way to deal with things when you get mail sent to multiple lists you're on, and often the To: line ends up with nothing at all. The Return-Path: is generally the surest way to know which of the lists each of the messages was sent to. I've tried lots of things over the years, and Return-Path: is what works the best. I'm on a few hundred mailing lists so the matter is somewhat important to me. I see no Return-Path headers in some IETF traffic, including [EMAIL PROTECTED] as it appears in my mailbox. Instead I see an old UNIX-style From_. RFC 2822 seems to say the some of the envelope should also be in the Received: header. In any case, while maintaining the hundreds of entries in the sample white list in the Distributed Checksum Clearinghouse source, I've found that many mailing lists use too many systems to readily track. That's why that sample white list contains other marks for some sources. (see http://www.dcc-servers.net/dcc/ ) Vernon Schryver[EMAIL PROTECTED]
Re: mail headers for announce
ahem Or the IETF could simply start using its own Proposed Standard mechanism described in RFC 2919. --Paul Hoffman, Director --Internet Mail Consortium
Re: mail headers for announce
Vernon Schryver [EMAIL PROTECTED] writes: I see no Return-Path headers in some IETF traffic, including [EMAIL PROTECTED] as it appears in my mailbox. Instead I see an old UNIX-style From_. That's because Return-Path: is frequently added at final delivery. My MTA adds that, some other don't. (Many Unix MTAs use the From_ line). My point is just that some of us filter on envelope sender (as expressed by Return-Path:), which for modern mailing lists is almost always unique and distinguishing. The few for which it is not, I use tricks. In any case, while maintaining the hundreds of entries in the sample white list in the Distributed Checksum Clearinghouse source, I've found that many mailing lists use too many systems to readily track. Yup. It is annoying. I mostly hand-maintain my splitting filters. The mail that falls into the other box is generally all the spam plus whatever list decided to change its MTA or list manager software that week. Having all the spam in one place reduces the time it takes to kill it by a big factor, which is important when you get a huge number. -- Perry E. Metzger[EMAIL PROTECTED]
Re: mail headers for announce
In article [EMAIL PROTECTED] you write: The recipient list is a pretty poor way to deal with things when you get mail sent to multiple lists you're on, and often the To: line ends up with nothing at all. I filter on envelope recipient. This seems to work very well, although it does cause problems with certain obnoxious lists and list-manager programs (I won't mention any names) which are unable or unwilling to deal with people sending mail using a different address from the one they receive it at. It also lets my MTA do all the work of sorting things for me. (In the case of the IETF list, I just gateway it into a local newsgroup, which works even better since the two people who still remember how to use netnews here do not need to receive separate copies. This also has the salutary effect of running the list traffic through my news server's spam filter. I presently have 93 such lists so gatewayed, although only a tiny number are of any interest to me personally.) -GAWollman -- Garrett A. Wollman | [G]enes make enzymes, and enzymes control the rates of [EMAIL PROTECTED] | chemical processes. Genes do not make ``novelty- Opinions not those of| seeking'' or any other complex and overt behavior. MIT, LCS, CRS, or NSA| - Stephen Jay Gould (1941-2002)
Re: mail headers for announce
I see no Return-Path headers in some IETF traffic, including [EMAIL PROTECTED] as it appears in my mailbox. Instead I see an old UNIX-style From_. That's because Return-Path: is frequently added at final delivery. My MTA adds that, some other don't. (Many Unix MTAs use the From_ line). Note that the ones that don't add return-path are in violation of over 20+ years of mail specificatons. See RFC 821 (top of page 22), RFC 1123 (section 5.3.3 among others), and RFC 2821 (section 4.4). However there's no guarantee that Return-Path is either consistent for all messages sent to a list, nor that it is uniquely associated with a list. The few standards that apply to lists only require that the return-path address serves the purpose of informing the list maintainer (perhaps a robot) of nondelivery reports. Keith
Re: mail headers for announce
The recipient list is a pretty poor way to deal with things when you get mail sent to multiple lists you're on, and often the To: line ends up with nothing at all. I filter on envelope recipient. This seems to work very well, although it does cause problems with certain obnoxious lists and list-manager programs (I won't mention any names) which are unable or unwilling to deal with people sending mail using a different address from the one they receive it at. It also lets my MTA do all the work of sorting things for me. I do the same thing, and it works extremely well for me also. FWIW, my bulk_mailer code has a fuzzy address matching algorithm that is designed to recognize when the sender of a message is using a similar-but-somewhat-different address (via subaddresses or slightly different domains) than the one to which he/she is subscribed. Authors of other list software are welcome to crib from it. Keith
Re: mail headers for announce
Keith Moore [EMAIL PROTECTED] writes: Note that the ones that don't add return-path are in violation of over 20+ years of mail specificatons. See RFC 821 (top of page 22), RFC 1123 (section 5.3.3 among others), and RFC 2821 (section 4.4). However there's no guarantee that Return-Path is either consistent for all messages sent to a list, nor that it is uniquely associated with a list. In practice, however, both are true, almost 100% of the time. Even when various bounce schemes are used, simple regexps almost always catch them. -- Perry E. Metzger[EMAIL PROTECTED]
