spf-discuss
[Top] [All Lists]

Re: Why Modified SPF is Working -- Implementation

2004-07-03 17:52:03
The complete list of changes I made is included below at the 
end.  Much of my experience developing this can be found in the 
June discussion archive.

It is  aggressive, but it could be converted into a more flexible 
product form with each mail recipient having control over the 
parameters for their mail.  Check-boxes could be created for 
things like the ?all -> -all translation.  'spf-milter' could 
lookup users preferences by envelope-recipient before calling 
Mail::SPF::Query.  The occasional false-positive can be mitigated
by creating a web-page to allow senders to whitelist themselves
after entering a blurry code from a graphic.

The hardest bit for a typical user is configuring "fallback" 
records.  I had to write three.  In particular, one may be 
representative of exceptions:  A correspondent firm of ours uses 
a third-party provider to handle their mail.  This fails the 
default test.  However, a variant of the default rule can be 
generated for non-technical users as long as they can figure out 
who the third-party ESP is:

   correspondent.com =>
   "v=spf1 a/24 mx/24 ptr a:esp.com/24 mx:esp.com/24 ptr:esp.com -all"

The envelope-sender whitelist would probably cover the rest of 
the exceptions for most people.  I've noticed that spammers 
don't forge corporate domains all that often (who wants IBM mad 
at them?).  Thus whitelisting entire domains in the 
envelope-sender whitelist is probably an acceptable trade-off 
for those who aren't up for writing SPF fallback rules.

BTW in answer to one of the other replies to this post, my 
false-positive rate has been a big fat O -- as in zerO.

In part, this is the result of my running 'spfquery' for old 
messages from everyone and making sure I didn't miss any 
necessary whitelist or fallback/override entries.  I use my 
non-SPF <@spamcop.net> address for miscellaneous e-mail (buying 
books from Amazon, reporting Fedora bugs, etc.) as it is 
totally immune from non-CAN-SPAM-compliant spam.  What I think 
ok as "cockroach spammers" wash this domain out of their lists 
as reliably as they forge sender info.  Finally, I feel I can 
live with a false-positive once in awhile.  My spam-to-ham ratio 
is about 50-to-1 on my business domains.  Telephones still 
exist.  Life is full of compromises.

Hope this is helpful!

David


1) Applied this default rule for domains that don't publish SPF:
"v=spf1 a/24 mx/24 ptr -all".  Fixed a minor bug that causes
'::Query' to not apply the default when non-SPF TXT records
exist.

2) Reinterpret "?all" "~all" and "+all" as "-all".

3) Added custom "fallback" and "override" records for my
important correspondents that don't fit the above default rule.

4) Modified 'spf-milter' to support 'access.db' "MAIL FROM:" 
whitelist entries of the form "SPF:user(_at_)domain(_dot_)tld OK". Added 
entries for a few of correspondents that use SPF-broken 
providers.  This modification is based on Paul Howarth's
"RCPT TO:" whitelist patch for 'spf-milter'.

5) Added a small number of RHSBL entries (three actually)
to 'access.db' for spammers that are SPF-compliant.

6) Treat any result other than a "pass" (such as "unknown",
"neutral", etc.) as a failure and block the message.


<Prev in Thread] Current Thread [Next in Thread>
  • Re: Why Modified SPF is Working -- Implementation, David Lawless <=