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

Reply via email to