Subject: mail headers for announce

From: "Perry E. Metzger" <[email-masked]>
Date: 30 Oct 2002 16:38:54 -0500

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

---

From: "Perry E. Metzger" <[email-masked]>
Date: 30 Oct 2002 18:23:45 -0500

Dave Crocker <[email-masked]> 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.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 30 Oct 2002 17:05:29 -0700 (MST)

> ...

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

I see no Return-Path headers in some IETF traffic, including
<[email-masked]> 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-masked]

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 30 Oct 2002 17:01:00 -0800

<ahem> Or the IETF could simply start using its own Proposed Standard 
mechanism described in RFC 2919.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Perry E. Metzger" <[email-masked]>
Date: 30 Oct 2002 20:10:42 -0500

Vernon Schryver <[email-masked]> writes:
> 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.

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

---

From: Garrett Wollman <[email-masked]>
Date: Wed, 30 Oct 2002 21:45:32 -0500 (EST)

In article <[email-masked]> you write:

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Oct 2002 22:47:55 -0500

> 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

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Oct 2002 23:07:05 -0500

> 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

---

From: "Perry E. Metzger" <[email-masked]>
Date: 30 Oct 2002 23:12:53 -0500

Keith Moore <[email-masked]> writes:
> 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.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 31 Oct 2002 23:19:10 +0200 (EET)

> the best. I'm on a few hundred mailing lists so the matter is somewhat

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