[milters] Archive

Lists Index Date Thread Search

Article: 1315
From: Taylor, Grant
Date: 2006-11-30 11:51:51 -0500
Subject: Re: [SPAM] Re: [SPAM] White list this list...

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

Anthony Howe wrote:
> You want to white list the SMTP envelope address in Sendmail:
> 
> 	From:milters-bounce@milter.info		OK
> or
> 	From:milter.info			OK
> 
> In SpamAssassin you'll probably also want:
> 
> 	whitelist_from milters-bounce@milter.info
> or
> 	whitelist_from *@milter.info

*nod*

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

/*
** <put something here>
*/

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

I'm running milter-spiff.  SpamAssassin may be (by old config that I don't 
remember at the moment) SPF checking as well.  However seeing as how SA is 
being run as a milter, I'd think it would be just ask ok as milter-spiff as 
far as the information is passed to it.

> 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:193.41.72.72 ip4:82.97.10.34 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)

*nod*  This is all standard enough.

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

Milter-spiff does indeed have the correct information.  I'm running 
SpamAssassin with spamass-milter (so that I can pass the full recipient 
email address to SA per previous thread) so I would think that it has access 
to the correct information.  If SA is not being passed the correct 
information, then it may indeed be pulling the wrong information.  I'll have 
to do some checking.

> 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 [206.152.114.68])
> 	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 <milters@milter.info>; Thu, 30 Nov 2006 08:05:03 +0100 (CET)
> Received: from [172.30.254.11] (n61-116-152-206.tranquility.net 
> [206.152.116.61])
> 	(authenticated bits=0)
> 	by rti02.co-lo.riverviewtech.net (8.13.8/8.13.8) with ESMTP id 
> kAU74lK1031503
> 	for <milters@milter.info>; Thu, 30 Nov 2006 01:04:50 -0600

It is my (personal) belief that posts to the mailing list are sent to the 
mailing list manager as a singular entity.  Then the mailing list manager as 
that singular entity will then send a new message to the mailing list 
subscribers.  In this case, the above two Received: headers would (should) 
not be in the new message created by the mailing list manager to your inbox. 
  Rather I see it as the mailing list manager creates a new message and 
sends it to everyone on the mailing list with its own content that it 
derived from messages sent to it.  This content should be the body of the 
message (sans headers) that has possibly been reformatted (HTML to text, 
scrubbed attachments, etc).

Again, this is personal belief based on a different view of email than most 
have.  This view is based on a few key points:

1)  The original sender did not send the message to any mailing list 
subscriber, bur rather to the mailing list manager.
2)  The mailing list manager sends messages to subscribers.
3)  It is not uncommon at all, especially on large mailing lists, for 
subscribers to not even know about the existence of other subscribers, much 
less personally know, or even less communicate with each other.
4)  Milter-Date will get some what unhappy if it sees a Received: header 
from the message from the original poster to the mailing list manager that 
has malformed time  / date stamps in it.  If the mailing list manager is a 
responsible administrator and has decided to accept a message (deemed it to 
be ham and not spam), why do I need to filter it again, possibly 
incorrectly, verses trust the mailing list administrator to be responsible 
and diligent in his / her job / role.
*)  (Other similar filtering problems (that check message / header content) 
that escape me at the moment.)  The problem arises from the lack of ability 
for mailing list subscribers filtering systems not being able to correctly 
determine which headers are from the message from the original sender to the 
mailing list verses which headers are from the mailing list manager to the 
subscriber.  If you can not clearly indicate which headers are from the 
original sender, then you can not correctly filter the headers that are from 
the mailing list manager.

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

This is more a personal preference.  I believe that there should be a 
Reply-To: header to direct all replies to go back to the mailing list while 
maintaining the From: header so that the subscribers do have access to the 
senders email address if they need it.

> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) 
> Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.666
> MIME-Version: 1.0

I do not believe these headers from the original sender need to be in the 
message that is sent to mailing list subscribers.  Rather, I believe these 
headers should reflect the mailing list manager.

> To: milters@milter.info
> Subject: [milters] Re: [SPAM] White list this list...
> 
> [ACH]	Ecartis modifies this header with the list name "[milters]".

*nod*

> 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 [82.97.10.34]); 
> Thu, 30 Nov 2006 08:05:04 +0100
> X-Scanned-By: milter-spiff/0.9.19 (rti02.co-lo.riverviewtech.net 
> [206.152.114.68]); Thu, 30 Nov 2006 01:04:51 -0600
> Received-SPF: Pass (sender authenticated); 
> receiver=rti02.co-lo.riverviewtech.net; client-ip=206.152.116.61; 
> envelope-from=<gtaylor@riverviewtech.net>
> Received-SPF: Pass (sender authenticated); 
> receiver=rti02.co-lo.riverviewtech.net; client-ip=206.152.116.61; 
> helo=[172.30.254.11]
> X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on
> 	rti02.co-lo.riverviewtech.net

I do not believe that the X-Scanned-By: and Recived-SPF: headers should be 
passed on to mailing list subscribers.

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

This is all standard enough.

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

Agreed.  This is also part of the reason(s) that I believe that such headers 
should be removed from the message that is sent to mailing list subscribers.

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

No, I think you are ok with that.

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

*nod*

I think I should state that I strongly believe that the message that is sent 
  by the original sender to the mailing list manager is a DIFFERENT message 
than what is sent by the mailing list manager to the mailing list 
subscribers and the two should NOT have close / identical information 
(headers) but rather similar content.  This belief is where / how I have 
come to the decisions / conclusions that I have stated above.  All of which 
are open for interpretation / opinion of course.  ;)




Grant. . . .

Lists Index Date Thread Search