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]
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
> > 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
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
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
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
> 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
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]
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]
