[Mimedefang] Integrating SPF...

[Kelson]

James Ebright wrote:
> I am logging the returns from the
> module and now compare them to SA now that SA has SPF checks embedded, this is
> just what I noticed SA is doing with them: SPF_SOFTFAIL and speculated that
> many ISPs are just lazy in this regard or do not really know what they have
> out there and are not giving out a "FAIL" return in most every case and are
> abusing the softfail section. In other words... softfail should not be a
> permanent situation, but in many cases I have seen, the response has remained
> a softfail return for over a year..... go figure.

Well, if we were confident that all forwarders, greeting cards, mailing 
lists,  "send this page to your friends!" etc. would use their own 
envelope senders, we might use -all instead of ~all.  I'd love to cut 
down on the insane number of bounces we get for %RANDOM at speed.net by 
switching from SOFTFAIL to FAIL.  (Not that I expect many sites to 
handle FAIL results in a way that will do this.)

The thing is, people don't take kindly to false positives.  When you 
have a large number of users with varying connection types, network 
setups, OSes, email programs, email usage patterns, etc., you have to 
approach things like this cautiously.

This is *not* a short transition period, however much we'd all like it 
to be.  AOL has been publishing SPF records for over a year now, and 
even they still use NEUTRAL -- they haven't even gone to SOFTFAIL, never 
mind FAIL.

Anyway, onto SA's SPF checks:  If I'm reading the Plugin/SPF.pm code 
right, it looks like it converts an empty result to a softfail (line 
240, $result ||= 'softfail').  It should never happen -- 
Mail::SPF::Query returns "none" if there's no SPF record and "neutral" 
if the record explicitly uses "?" -- but it might increase the number of 
SPF_SOFTFAIL hits under certain conditions.

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>