Bug 3428 - Use MTA generated SPF headers if present
Summary: Use MTA generated SPF headers if present
Status: RESOLVED DUPLICATE of bug 5239
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (Eval Tests) (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: PC Linux
: P5 enhancement
Target Milestone: Future
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-05-24 23:11 UTC by Graham Murray
Modified: 2007-02-25 15:07 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 Graham Murray 2004-05-24 23:11:25 UTC 
Where a local MTA has already performed SPF checks it seems wasteful for
SpamAssassin to run them again. Plus, as someone posted in the user mailing
list, SPF checks are skipped if the mail has passed through a trusted system. 

So where the MTA has already run SPF at SMTP time, it would be better for
SpamAssassin to score against the SPF header inserted rather than running SPF
again. Also, (and this may just be subjective as I have no actual counts) the
SPF HELLO checks seem almost worthless as many spams pass that test.

I suppose one problem may be to ensure that the SPF was run on the local or
trusted system and the spammers have not pre-inserted the header. But this
should not be too much of a problem as SPF inserts the name of the system on
which it is run and Spamassassin should be able to check that, possibly with a
configuration option to indicate 'local MTA SPF' to guard against spammers
inserting the header on systems which do not run SPF in the MTA.
Comment 1 Daniel Quinlan 2005-03-30 01:08:21 UTC 
move bug to Future milestone (previously set to Future -- I hope)
Comment 2 Scott Kitterman 2007-02-24 08:35:40 UTC 
This bug is a dupe of 5239 which has been implemented for SA 3.2.
Comment 3 Daryl C. W. O'Shea 2007-02-25 15:07:53 UTC 
Thanks Scott.

*** This bug has been marked as a duplicate of 5239 ***