Bug 5239 - use results from Received-SPF header where possible
Summary: use results from Received-SPF header where possible
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Plugins (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: Other other
: P5 normal
Target Milestone: 3.2.0
Assignee: Daryl C. W. O'Shea
URL:
Whiteboard:
Keywords:
: 3428 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-12-11 13:50 UTC by Daryl C. W. O'Shea
Modified: 2007-02-25 15:07 UTC (History)
2 users (show)


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 Daryl C. W. O'Shea 2006-12-11 13:50:29 UTC 
The SPF plugin should (optionally, on by default) use the results found in a
*trusted* Received-SPF header.  DKIM/DK probably have a standard header for
their results too.

Best way to implement it is to implement "$pms->get_trusted", which would return
only trusted headers.  A "$pms->get_untrusted" would be probably be useful for
other eval tests and header rules.  Pseudo-headers such as "ALL-TRUSTED" and
"ALL-UNTRUSTED" would act like the "ALL" pseudo-header.
Comment 1 Justin Mason 2006-12-11 14:29:52 UTC 
how will we know if a Received-SPF header was added by a trusted host, rather
than an untrusted one?
Comment 2 Daryl C. W. O'Shea 2006-12-11 14:52:49 UTC 
The headers are supposed to be inserted, rather than appended, so it's possible
that they'll appear above the last trusted relay's received header which means
they can be trusted.

The SPF guys claim that they know how to have libmilter insert a header above
the current relays received header, so this (header insertion described above)
should happen any time your MX checks SPF.  I haven't seen this actually work
(the insertion is always below the current relay's received headers since it is
added last), but it's something that I've been lobbying for (although way too
quietly to be effective).

Failing header insertion working as above, if the second last trusted relay
inserts the header (above or below it's received header) you'll be able to use
that one.

This is really only useful for large installations, but I think it's worthwhile.
 Blocking (in a large process like SA) on SPF checks is costly, even if you've
got the benefit of a DNS cache.
Comment 3 Daryl C. W. O'Shea 2006-12-14 01:22:58 UTC 
Sending        lib/Mail/SpamAssassin/Message/Metadata/Received.pm
Sending        lib/Mail/SpamAssassin/Message/Node.pm
Sending        lib/Mail/SpamAssassin/PerMsgStatus.pm
Sending        lib/Mail/SpamAssassin/Plugin/SPF.pm
Adding         t/data/nice/spf3-received-spf
Sending        t/spf.t
Transmitting file data ......
Committed revision 487146.
[dos@FC5-VPC trunk]$
Comment 4 Daryl C. W. O'Shea 2006-12-14 01:25:16 UTC 
[dos@FC5-VPC trunk]$ svn ci -m "bug 5239: add new test message to MANIFEST"
Sending        MANIFEST
Transmitting file data .
Committed revision 487147.
[dos@FC5-VPC trunk]$
Comment 5 Daryl C. W. O'Shea 2007-02-25 15:07:53 UTC 
*** Bug 3428 has been marked as a duplicate of this bug. ***