Ken Morley wrote: > According to my understanding of the way SPF works the following message > should not be failing. Can anyone tell me why this failed? > > > Here's the pertinent parts of the log: > -------------------------------------- > Apr 11 15:00:18 maildrop postgrey[2407]: request: > client_address=66.179.38.26 client_name=hamhock-outbound.hoovers.com > etrn_domain= helo_name=hamhock.hoovers.com > > <snip> > Apr 11 15:00:33 maildrop amavisd[32198]: (32198-06) SPAM, > <[EMAIL PROTECTED]> -> <[EMAIL PROTECTED]>, Yes, score=9.243 tag=3 > tag2=6.31 kill=6.31 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1.091, > HTML_MESSAGE=0.001, SARE_GIF_ATTACH=0.75, SPF_HELO_FAIL=10], > autolearn=no, quarantine pOlR15g8xTwO (spam-quarantine) > > Apr 11 15:00:33 maildrop amavisd[32198]: (32198-06) one_response_for_all > <[EMAIL PROTECTED]>: REJECTs, '554 5.7.0 Reject, id=32198-06 - SPAM' > > > Here's the SPF record for hoovers.com: > -------------------------------------- > hoovers.com text = "v=spf1 ip4:66.179.38.0/23 ip4:66.45.81.128/27 > ip4:66.45.81.160/27 ip4:66.179.85.192/27 ip4:216.234.248.64/26 > ip4:216.234.248.78 ip4:216.234.248.82 ip4:66.162.217.59 mx ptr > a:exchange.hoovers.com a:mail.eca.com include:dartmail.net ~all" > > > The sending server is hamhock-outbound.hoovers.com [66.179.38.26] and > that IP address is within the range listed in the first SPF entry. Why > did this fail?
First, this was SPF_HELO_FAIL, not SPF_FAIL. This rule by default has a score of zero, and is not really a proper way to test SPF. Why'd you raise it from 0 to 10? Since it was SPF_HELO_FAIL we need to look at the HELO, not the real host delivering the mail. According to your server logs, the HELO was hamhock.hoovers.com, not hamhock-outbound.hoovers.com. That said, from my perspective hamhock.hoovers.com resolves to 66.179.38.137, which should also match the first clause of the SPF record. Does hamhock.hoovers.com resolve to anything else on your spamassassin system? It's also possible that SA's trust-path auto-guesser is confused and it used the wrong Received: headers. But there's not enough information here to debug that. You'd have to take a copy of the message and run it through spamassassin -D to see how SA parsed the various Received: headers.
