Bug 3859 - SPF HELO false positives
Summary: SPF HELO false positives
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Plugins (show other bugs)
Version: 3.0.0
Hardware: PC Linux
: P5 normal
Target Milestone: 3.1.0
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-03 09:22 UTC by Cesar Eduardo Barros
Modified: 2005-06-01 10:04 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Cesar Eduardo Barros 2004-10-03 09:22:57 UTC 
The SPF plugin, when checking HELO, gets rid of the hostname and uses only the
domain:

# get rid of hostname part of domain, understanding delegation
$helo = Mail::SpamAssassin::Util::RegistrarBoundaries::trim_domain ($helo);

However, this causes problems when a host does a HELO as xxx.example.com and the
SPF record for example.com does not allow xxx.example.com (even if
xxx.example.com has a SPF record which would allow the sending host).

The SPF FAQ (http://spf.pobox.com/faq.html) implies one should add a SPF record
for every host, and the HELO checking should be based on the full hostname on
the HELO. The SPF Classic RFC also looks like only the FQDN should be tested.

The FP I got was with a host with no SPF record using its own hostname as both
the HELO and the MAIL FROM domain name, in a domain with a SPF record which
wouldn't allow it to send email as the domain (SPF_HELO_SOFTFAIL). A couple of
other rules pushed it over the limit. The right behaviour IMO would be for it to
act as if it had no SPF record at all (since it really has no SPF record).
Comment 1 Bob Menschel 2005-05-22 00:37:10 UTC 
Code here has not changed since the bug report, and there's been no discussion
re this suggestion. If Cesar's analysis is correct, it should at least be looked
at for 3.1, even if it's decided to push to a later version.
Comment 2 Justin Mason 2005-06-01 17:21:26 UTC 
this was by design, actually.  

in 99.99% of cases, hosts do not specify an SPF policy, but domains do, so
checking hosts provides no useful data.  in addition to that, the HELO rules are
purely non-standard heuristics we added. (the SPF spec later added HELO
checking, too, but we were there first ;)

it may indeed be worthwhile making this conform to the std now.
Comment 3 Justin Mason 2005-06-01 18:02:35 UTC 
ok, checking a recent set of ham and spam that hit on any SPF rule...

before:

  4.979   9.3178   0.3546    0.963   1.00    1.00  SPF_HELO_NEUTRAL
  1.288   2.4958   0.0000    1.000   0.67    1.00  SPF_HELO_SOFTFAIL
  3.176   5.4908   0.7092    0.886   0.00    0.41  SPF_HELO_FAIL

after:

  3.433   6.6556   0.0000    1.000   1.00    1.00  SPF_HELO_NEUTRAL
  0.858   1.6639   0.0000    1.000   0.33    1.00  SPF_HELO_SOFTFAIL
  2.747   4.4925   0.8865    0.835   0.11    0.41  SPF_HELO_FAIL

: jm 121...; wc -l ham.log spam.log
  568 ham.log
  605 spam.log

kind of cool that SPF_HELO_NEUTRAL becomes a 100% spamsign... I say we go for
it, since it brings us back in line with the std, too.
Comment 4 Justin Mason 2005-06-01 18:04:10 UTC 
applied; r179477.