Re: SPF and Upgrade to SA 3.1

[Ben Lentz <bl...@channing-bete.com>]

> Yes- I would rather have correct results than just results.
>
> Okay, so the problem is with my MTA moving the Return-Path header 
> below the Received headers. It's breaking spamassassin's ability to 
> check perfectly compliant SPF records. I'm using stock versions of 
> sendmail 8.13 on all my boxes, so I guess my only recourse is to go to 
> the sendmail folks and ask them why.
FWIW, a year later: My problem was that final (mailbox) delivery was not 
being made on the MTA that was running SA, so I had no Return-Path 
header at all. I understand that the Return-Path is supposed to be added 
only by the MTA that is doing final delivery. The fix for my MTA, 
sendmail 8.13, was to follow the instructions provided at 
http://wiki.apache.org/spamassassin/EnvelopeSenderInReceived, and to 
modify my sendmail configuration on the sending (MX) MTA, to add the 
envelope-from information in the received headers. For sendmail 
(sendmail.mc):
define(`_REC_BY_', `$.by $j (envelope-from $f) ($v/$Z)$?r with $r$. id 
$i$?{tls_version}')

My other problem, which was solved much earlier with Daryl's advice, was 
that the MTA running SA is not the initial recipient (MX) of an inbound 
email, either. So that's where properly defining trusted_networks for SA 
making sure to include the MX MTA in the address spec, *and* enabling 
always_trust_envelope_sender 1 becomes imperative.

This will make the result of the MAIL FROM: <> available to other MTAs 
in the chain, allowing SpamAssassin to look back at what this data was 
at a previous MTA hop, so long as it is trusted.

Hopefully this information will be useful to anyone else who wishes to 
use the SPF checks in SA on a non-"single-box" MTA configuration. I know 
it wasn't obvious to me, but then again, I'm not the brightest bulb in 
the box. ;-)

Things are working great now, but please let me know if I've messed up 
any of this information.
>
>
> It's probably not worth it- I'm really not in the mood to think about 
> recompliling sendmail at the moment.
>
> Thanks for your help.
>
> ----- Original Message -----
> *From:* "Daryl C. W. O'Shea" <sp...@dostech.ca>
> *Sent:* 09/29/2005 03:36:15 PM
> *To:* Ben Lentz <bl...@channing-bete.com>
> *Cc:* users@spamassassin.apache.org
> *Subject:* SPF and Upgrade to SA 3.1
>
>
>
>> Ben Lentz wrote:
>>
>>> _You_ are _welcome_.
>>>
>>> Get it moved? - Hmmm... Ala-kazamm! - Oh, that didn't work. Okay, so 
>>> magic isn't going to get it moved, and I'm all out of ideas.
>>
>>
>> I can only suggest starting another thread here or "somewhere else 
>> applicable" that asks "this is the software I'm using, why is my 
>> return-path being appended to the bottom and not prepended to the top?".
>>
>> If you're specific in the software you're using I'd be surprised if 
>> someone can't give you a reason why and how to fix it.
>>
>>
>>> I still don't understand why I used to get SPF_HELO_PASSes with 
>>> 3.0.4 and I don't with 3.1. The world hasn't changed, just my SA 
>>> version. I guess SA was doing it "wrong" before, but is doing it 
>>> "right" now? Is that the concrete explanation?
>>
>>
>> YES!  You'll continue to get SPF_HELO_PASSes with SA 3.1.0 too, for 
>> domains that fully implement the draft and publish SPF records for 
>> each host.  SA 3.0 did INCORRECTLY fire SPF_HELO_PASSes for domains 
>> it shouldn't have.  Surely you would prefer correct results and not 
>> just results.
>>
>> The fact of the matter, though, is that nobody really cares about 
>> SPF_HELO_* checks.  Some, usually smaller, domains publish them but 
>> that's about it.
>>
>> Heck, even SA doesn't care about SPF_HELO_PASS:
>>
>> score SPF_HELO_PASS -0.001
>>
>>
>> Also FWIW, I ran your test message through SA 3.0.4-r165054 and got 
>> the incorrect SPF_HELO_PASS result.  I did NOT get an SPF_PASS result 
>> though because:
>>
>> debug: Return-Path header found after 1 or more Received lines, 
>> cannot trust envelope-from
>>
>>
>>> The idea I'm obsessed with is that I moved to SA 3.1 to get 
>>> DomainKeys stuff, and I feel like I've lost the SPF stuff. 
>>> Technology vendors everywhere are telling me that if I implement SPF 
>>> and DK that the entire plannet will be spam free.
>>> http://www.ranum.com/security/computer_security/papers/a1-firewall/index.html 
>>>
>>
>>
>> I've actually got a few of those IPS tools in different sizes.  The 
>> work really nice, except for the one I use with aluminum.  Head the 
>> "copper only" warning.
>>
>> Anyway, obsession or not, I'm sure you'd rather have correct results 
>> over incorrect results.
>>
>>
>>> The subdomain thing is causing them to assume that people are 
>>> publishing SPF records for the MTA systems as well as the domains. I 
>>> realize now that this is the "right" way to do it, but to be honest, 
>>> I think most people fell asleep before reading that part of the 
>>> spec. I know I did, and apparently, so did the folks over at google.
>>
>>
>> I recall falling asleep at least once too.  It's certainly not the 
>> clearest draft I've ever read.
>>
>>
>>> And if google can't get it right, there's no hope for me.
>>
>>
>> Google's got it right.  The host records are OPTIONAL and are only 
>> referred to as RECOMMENDED in the draft.  Google has correctly 
>> implemented the mandatory parts of the draft.
>>
>>
>> Daryl
>>
>