Re: [Asrg] List Detection

Scott Nelson <> Wed, 14 May 2003 04:40 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id AAA09788 for <>; Wed, 14 May 2003 00:40:19 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h4E46dU28116 for; Wed, 14 May 2003 00:06:39 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h4E46dB28113 for <>; Wed, 14 May 2003 00:06:39 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id AAA09784; Wed, 14 May 2003 00:39:49 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19Fo5I-0002NL-00; Wed, 14 May 2003 00:41:44 -0400
Received: from ([] by ietf-mx with esmtp (Exim 4.12) id 19Fo5H-0002NI-00; Wed, 14 May 2003 00:41:43 -0400
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h4E45BB28045; Wed, 14 May 2003 00:05:11 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h4E44VB27997 for <>; Wed, 14 May 2003 00:04:31 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id AAA09770 for <>; Wed, 14 May 2003 00:37:41 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19Fo3D-0002Mz-00 for; Wed, 14 May 2003 00:39:35 -0400
Received: from ([] by ietf-mx with smtp (Exim 4.12) id 19Fo3D-0002Mw-00 for; Wed, 14 May 2003 00:39:35 -0400
Message-Id: <aT5vaIe86J8qbrFTB02@x>
From: Scott Nelson <>
Subject: Re: [Asrg] List Detection
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
List-Archive: <>
Date: Tue, 13 May 2003 21:41:41 -0700

At 09:24 AM 5/13/03 -0400, Eric Dean wrote:
>I've started a new thread to discuss list detectiom just to be search engine
>There seem to be a variety of methods that lists use including preserving
>the original sender as well as sending witht the list's email address.  This
>particular list sends with the list's email address.  For C/R systems, this
>often works fine because you often have to send to a list-subscribe in order
>to join the list.  A C/R will then send a challenge to the list and
>subsequently get denied.
>For lists that preserve the sender's email address, a C/R system can be a
>bit unfriendly.  However, we have seen that most list's use a "Sender"
>header somewhere inside the message body.  for example, this list sends:
>If we encounter such a header, we will then not challenge the sender but
>will require the user to take an action.  I'm not trying to have another C/R
>discussion but rather am interested in the various list detection methods
>available.  I've sorted through procmail to see what methods are available
>to that source and the above was the best I could come up with.

Spamwolf checks for these headers.
    "precedence: bulk",
    "precedence: list",
and it also checks for "(LISTSERV-" anywhere in any header -
though really one should check only in Received headers.

The "(LISTSERV-" check is necessary because versions of that software
written before the RFC recommending the list-* headers do not add them, 
for obvious reasons.  And yes, there is anchient listserv software 
still in operation.  Fortunately, all new mailing list software seems 
to contain one or more of the others (at least, all that I've seen so far.)

The "mailing-list:" header is deprecated, but again, still in use.

The Spam Assassin checks are more complex, but it's checking for
a particular mailing list program to do more refined "spaminess" checks.
There's no harm in checking for "List-Post:" but all lists (I know of)
which have List-Post: also have either list-help or list-unsubscribe.

Another recommendation made by some (but not me),
is "don't respond unless you're named in the To: field."
It doesn't really identify a mailing list,
but rather a message one should arguably not auto-respond to.
Identifying your own email address is harder than it seems
(for your mail client) so while this test sounds good, 
it's actually difficult to implement in practice.

A lessor but easier to implement variant is 
"don't respond if there's more than one recipient.".
It doesn't catch as much, but it's far more practical to implement.
(i.e. it's better than nothing, so why not?)

Scott Nelson <>

Asrg mailing list