From: Anthony Howe
Date: 2006-11-30 04:01:25 -0500
Subject: Re: [SPAM] White list this list...
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 "email@example.com".
You want to white list the SMTP envelope address in Sendmail:
In SpamAssassin you'll probably also want:
> 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
How are you performing the SPF checks? milter-spiff or SpamAssassin
test/plugin? Here are the headers from your post with my comments [ACH]
[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
root@mx# dig +short txt snert.net
"v=spf1 ip4:22.214.171.124 ip4:126.96.36.199 mx -all"
Received: from mx.snert.net (localhost.snert.net [127.0.0.1])
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
Received: from 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 verify=NO)
for <firstname.lastname@example.org>; Thu, 30 Nov 2006 08:05:03 +0100 (CET)
Received: from [172.30.254.11] (n61-116-152-206.tranquility.net
by rti02.co-lo.riverviewtech.net (8.13.8/8.13.8) with ESMTP id
for <email@example.com>; Thu, 30 Nov 2006 01:04:50 -0600
Date: Thu, 30 Nov 2006 00:45:24 -0600
From: Grant Taylor <firstname.lastname@example.org>
[ACH] Original From header unmodified by Ecartis.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52)
Gecko/20061025 Thunderbird/184.108.40.206 Mnenhy/0.7.4.666
Subject: [milters] Re: [SPAM] White list this list...
[ACH] Ecartis modifies this header with the list name "[milters]".
Content-type: text/plain; charset=UTF-8
X-Scanned-By: milter-spamc/1.11.379.379 (mx.snert.net [220.127.116.11]);
Thu, 30 Nov 2006 08:05:04 +0100
X-Scanned-By: milter-spiff/0.9.19 (rti02.co-lo.riverviewtech.net
[18.104.22.168]); Thu, 30 Nov 2006 01:04:51 -0600
Received-SPF: Pass (sender authenticated);
Received-SPF: Pass (sender authenticated);
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on
[ACH] The following are inserted by Ecartis.
X-ecartis-version: Ecartis v1.0.0
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 email@example.com 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
Copyright 2009, 2012 by SnertSoft. All rights reserved.