[milters] Archive

Lists Index Date Thread Search

Article: 1314
From: Diffenderfer, Randy
Date: 2006-11-30 10:48:14 -0500
Subject: Re: [SPAM] White list this list...

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support

You might consider getting the list manager folks to update their

RFC 2369 & 2919 describe standards track mailing list headers...

-----Original Message-----
From: milters-bounce@milter.info [mailto:milters-bounce@milter.info] On
Behalf Of Anthony Howe
Sent: Thursday, November 30, 2006 4:01 AM
To: milters@milter.info
Subject: [milters] Re: [SPAM] White list this list...

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support

Grant Taylor wrote:
> On 11/21/06 02:35, Anthony Howe wrote:
>> I've noticed several members of this list appear in the daily MLM 
>> bounce reports I get. The MLM is set to a low bounce threshold before

>> it auto-unsubscribes a user. Since this list talks about anti-spam 
>> tools and thus may make reference to spammy looking examples and test

>> cases etc. users should white list this mailing list through their 
>> spam filters.
> What address should be white listed?  According to the headers each 
> message comes from the original senders email address.  According to 
> MTA logs, the message is from "milters-bounce@milter.info".

You want to white list the SMTP envelope address in Sendmail:

	From:milters-bounce@milter.info		OK
	From:milter.info			OK

In SpamAssassin you'll probably also want:

	whitelist_from milters-bounce@milter.info
	whitelist_from *@milter.info

> Is there a reason why the messages in to the mailing list are not 
> cleaned up a bit as far as removing (unneeded) headers?

Huh? What you mean? What headers are unwanted? I use Ecartis MLM, which 
typically doesn't alter many headers and added the X-List-* headers.

> Is there a reason why the message is not cleaned up to appear to be 
> directly from the mailing list manager verses maintaining the original

> received headers?  Specifically, when I send this message, it will 
> appear as if your server is sending messages from my domain, which my 
> SPF records indicate that your server is not authorized to do.

How are you performing the SPF checks? milter-spiff or SpamAssassin 
test/plugin? Here are the headers from your post with my comments [ACH] 

Return-Path: <milters-bounce@milter.info>

[ACH]	Sendmail inserted envelope sender. SPF should be using
	this address in combination with the Received header below.
	The SPF domain to check is "milter.info"

	root@mx# dig +short txt milter.info
	"v=spf1 redirect=snert.net"
	root@mx# dig +short txt snert.net
	"v=spf1 ip4: ip4: mx -all"

Received: from mx.snert.net (localhost.snert.net [])
	by mx.snert.net (8.13.8/8.13.8) with ESMTP id kAU7HiYV026686;
	Thu, 30 Nov 2006 08:17:45 +0100 (CET)

[ACH]	The HELO and IP information found in the above Received header
	should be the info used for SPF. How that information is found
	depends on who is doing the SPF checking. milter-spiff has this
	information at hand, while SpamAssassin would have to dig for
	it and be sure to select the correct received header. Now the
	example here might not be the best, since Ecartis is delivering
	to my account on the same machine via localhost.

Received: with ECARTIS (v1.0.0; list milters); Thu, 30 Nov 2006 08:15:49

+0100 (CET)
Received: from rti02.co-lo.riverviewtech.net 
(rti02.co-lo.riverviewtech.net [])
	by mx.snert.net (8.13.8/8.13.8) with ESMTP id kAU74sM6011491
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256
	for <milters@milter.info>; Thu, 30 Nov 2006 08:05:03 +0100 (CET)
Received: from [] (n61-116-152-206.tranquility.net 
	(authenticated bits=0)
	by rti02.co-lo.riverviewtech.net (8.13.8/8.13.8) with ESMTP id 
	for <milters@milter.info>; Thu, 30 Nov 2006 01:04:50 -0600
Message-ID: <456E7E04.6070503@riverviewtech.net>
Date: Thu, 30 Nov 2006 00:45:24 -0600
From: Grant Taylor <gtaylor@riverviewtech.net>

[ACH]	Original From header unmodified by Ecartis.

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: 
Gecko/20061025 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: milters@milter.info
Subject: [milters] Re: [SPAM] White list this list...

[ACH]	Ecartis modifies this header with the list name "[milters]".

References: <4562BA58.6050403@snert.com>
In-Reply-To: <4562BA58.6050403@snert.com>
Content-type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Scanned-By: milter-spamc/1.11.379.379 (mx.snert.net []); 
Thu, 30 Nov 2006 08:05:04 +0100
X-Scanned-By: milter-spiff/0.9.19 (rti02.co-lo.riverviewtech.net 
[]); Thu, 30 Nov 2006 01:04:51 -0600
Received-SPF: Pass (sender authenticated); 
receiver=rti02.co-lo.riverviewtech.net; client-ip=; 
Received-SPF: Pass (sender authenticated); 
receiver=rti02.co-lo.riverviewtech.net; client-ip=; 
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on

[ACH]	The following are inserted by Ecartis.

X-archive-position: 1302
X-Approved-By: achowe@snert.com
X-ecartis-version: Ecartis v1.0.0
Sender: milters-bounce@milter.info
Errors-to: milters-bounce@milter.info
X-original-sender: gtaylor@riverviewtech.net
Precedence: bulk
Reply-to: milters@milter.info
X-list: milters

Note the Sender header. RFC 2822 describes how Sender and From headers 
relate to each other. Ecartis is saying IT sent the message. So 
SpamAssassin should be either using the Return-Path or the Sender header

for an SPF check when present, otherwise From header. I won't even get 
into the issue of Resent-From headers. Essentially doing SPF checks on 
message headers gets very tricky, even unreliable, if certain 
information is not added by the delivery MTA. For this reason 
milter-spiff and other SMTP time based SPF checking is better suited.

Now from what I can see there is no envelope sender rewriting being done

by Ecartis, its a complete replacement of the envelope sender address 
with the mailing list address, which is correct IMO, because the message

will come from milters-bounce@milter.info and so should pass SPF. If it 
ain't then something ain't right with the process on your system as far 
as I can tell, otherwise I'm over looking something.

On the flip side, Sender-ID (Caller-ID) solution uses header 
information, which is signed I think much like DKIM. IMO DKIM is better 
than Sender-ID and SPF Classic is better than Sender-ID. Just remember 
though that DKIM is a post-DATA solution and SPF Classic is a pre-DATA 
solution; both have their pros and cons.

Anthony C Howe          Skype: SirWumpus                    SnertSoft
+33 6 11 89 73 78         AIM: SirWumpus    Sendmail Milter Solutions
http://www.snert.com/     ICQ: 7116561

Lists Index Date Thread Search