[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spamassassin-devel
Subject:    Re: [SAdev] added SPF support
From:       jm () jmason ! org (Justin Mason)
Date:       2003-09-29 19:56:17
[Download RAW message or body]


Graham Murray writes:
> jm@jmason.org (Justin Mason) writes:
> 
> > So I've just added support for SPF (http://spf.pobox.com/) to CVS, using
> > Meng Weng Wong's Mail::SPF::Query module.
> 
> I have encountered one problem. When receiving a mail from a domain
> for which I have set SPF DNS entries, spamd put out the following
> message
> "SPF: message came through >0 trusted relays, cannot use "
> The Recived: headers from the message are below. Looking at the other
> output, the problem seems to be that it considers 127.0.0.1 (on the
> sending host) as a trusted relay. In this situation, should the SPF
> not be checked?

Unfortunately not.   I ran into this with a mail in my own spool, where
MailMan had received the message and reinjected it using SMTP to 
localhost.

Since this was a *new* SMTP transaction, the Return-Path (ie. "MAIL FROM" used)
was changed to <list-admin@host.example.org> (correctly).  The headers were
then like:

    Return-Path: <list-admin@host.example.org>
  A Received: from localhost (heloname [127.0.0.1]) ...
  B Received: from externalhost (heloext [nnn.nn.nn.nn]) ...

If the Received-header parser was to skip localhost handovers -- as it
did previously -- it would ignore SMTP transaction A, and the first
one it would find would be the next one along.  This was *not* the SMTP
transaction that the Return-Path corresponded to.  As a result, the
SPF test would take place with Return-Path ==
<list-admin@host.example.org>, but using IP == B, which did not
correlate -- and therefore it failed.

So SPF requires that localhost-via-SMTP handovers be recorded so that it
will correctly check with Return-Path == <list-admin@host.example.org>,
and IP == A.

Note: if the handover below is *not* via SMTP, and therefore will not
change the Return-Path, we can just fix Received.pm to ignore it.  But
AFAICS it *is* an SMTP/ESMTP handover.

A better fix of course would be for Received headers to record the MAIL
FROM/RCPT TO metadata, along with the HELO -- so each step's MAIL FROM
string is visible in those headers.   This problem is fundamentally caused
by Return-Path/X-Envelope-From/etc. recording only the most recent MAIL
FROM metadata.

> Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204])
> 	by home.gmurray.org.uk (8.12.6/8.12.6/SuSE Linux 0.6) with ESMTP id h8TAEhM3012375
> 	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
> 	for <graham@gmurray.org.uk>; Mon, 29 Sep 2003 11:14:43 +0100
> Received: from gmdev.webwayone.co.uk (localhost [127.0.0.1])
> 	by gmdev.webwayone.co.uk (8.12.6/8.12.6/SuSE Linux 0.6) with ESMTP id h8TAEdxK027790
> 	for <graham@gmurray.org.uk>; Mon, 29 Sep 2003 11:14:39 +0100
> Received: (from graham@localhost)
> 	by gmdev.webwayone.co.uk (8.12.6/8.12.6/Submit) id h8TAEdvW027789;
> 	Mon, 29 Sep 2003 11:14:39 +0100

--j.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Spamassassin-devel mailing list
Spamassassin-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spamassassin-devel
[prev in list] [next in list] [prev in thread] [next in thread]