spf-discuss
[Top] [All Lists]

Re: SPF+SRS vs. BATV

2005-07-05 11:01:58
On Tue, 5 Jul 2005, John Hinton wrote:

Ahhh... but in the 'real' world of 'delivering email to clients', we 
have to sometimes deal with these busted systems. I two weeks ago, had 
one client lose $600.00 because their client didn't have reverse DNS. I 
have rejects set up for that, only because I know 90% or so of the rest 

That is actually a poor choice of standards to enforce.  The problem is
that the domain owner has no direct control over their reverse DNS
records.  All they can do is keep bitching at their ISP - which is
likely a monopoly in their area and typically has no clue themselves about 
reverse DNS.

of the world rejects on that, too. I'm constantly placed between the 
rock and the hard spot. Knowing there are hoards of methods for rejects 
for non-RFC compliant mail systems... accepts postmaster, acceptance of 
NULL sender, .... and blah blah blah... , but at the same time, I know 
there are actually very few domains with proper DNS on systems that are 
correctly configured. And too many people who simply 'don't know', sign 
up for these poor services. So, I'm placed between block spam and 
deliver all good email. My clients are primarily in the innkeeping 
business. Most of them claim over 80% of their business comes directly 
from the internet. Email is critical to us all, but I seem to be in a 
very hot seat.

All too true.  I sympathize.  My clients have many customers in the
3rd world that have poorly configured systems, but where email is critical.
I find that accepting email with any *one* thing done right is a very practical
policy.  For instance, if they have a compliant PTR, or if they have a
compliant HELO, or if they have an SPF record that doesn't fail, then I accept
the mail.  For some clients with *really* hard up customers, I also accept mail 
that fails all of the above, provided the purported sender will accept
a DSN explaining the problems.

I too had a -all record set up on one domain for 6 or 8 months. I did 
get several rejects. I made contact with some of these sysadmins to 
explain to them their errors. In about 50% of the cases, they didn't 
even know what it was, apparently it was just a 'on/off switch' to them, 
which looked like a good spam filter. I think there are going to be a 
LOT of these broken mailservers in the next year or so.

One strategy for dealing with recipients with broken forwarding aliases is to
get the target address from the bounce, and change the recipient from the alias
to the real recipient when it leaves your MTA.  All this requires is a map
for recipients that you add to as broken forwarders are encountered.
However, after a year of publishing -all for many domains with over
100,000 messages/day total, I still haven't encountered these hypothetical
broken forwarders.  (Although I can see how it could easily happen.)
Most mail admins that are savvy enough to try checking SPF at this relatively
early stage, are savvy enough not to start rejecting mail right off the bat.  I
didn't start rejecting mail right off the bat.  At first, I just added
Received-SPF records to messages, providing extra tokens for the bayesian
filter.  Only with a few months of logs under my belt did I start rejecting
fails.  Now, I even reject NEUTRAL and SOFTFAIL for domains that are
heavily forged.

First, simply deciding on 'where' to begin. I think I will need to plan 
'?all' first and remain fluid as the standard evolves into a working 

The first step is to keep sending policy and receiving policy separate.

On the receiving end, start checking SPF, but don't reject anything at first.
Just add the Received-SPF header.   The big task for an unsecured
receiving domain is to identify all authorized forwarders and relayers.
For a large ISP or company domain, this may involve a receiving policy
that depends on the recipient.  You will need to whitelist forwarders
that do not use SRS or otherwise rewrite the MAIL FROM.  The best way
to whitelist a forwarder is via the SPF record for the domain they
send from (the domain they *ought* to be using in MAIL FROM).  
In other words, if the MAIL FROM fails SPF, then try substituting the
domain of an authorized forwarder and see if that passes.

If there is no SPF record for a domain, then provide a local
substitute for whitelisting purposes.  I distribute local SPF records to all my
MTAs via DNS.  For instance, if a sender has no SPF record, then try
senderdomain.com._spf.mydomain.com instead.

On the sending end, start with ?all first, as you have already figured
out.  The big task for an unsecured sending domain is to identify 
all those roaming users that send from hotel rooms or their home ISPs
and don't use SMTP AUTH.  When you think that all your authorized
senders are now using your authorized MTAs, then change to ~all.  This will
cause many recipients to send DSNs for SOFTFAIL, and should not cause
any recipient to reject your mail (unless you are a heavily forged
domain like AOL.COM).  When you haven't had any DSNs due to some 
remote user you missed for a while, then change to -all.

Otherwise, I will volunteer time and efforts towards what would be most 
helpful on the site, although I'm not so sure I know enough about the 

A tutorial with a step by step of how to safely implement SPF is
sorely needed.  Something like the above, but with more scenarios
and more explanations.  Also, the above doesn't mention specific
configuration options for specific popular SPF checking implementations.  

workings of SPF to actually do much in the way of creation. One idea I 
have, like was mentioned above, is FAQs, but we need a system very much 
like FAQs only perhaps called 'Scenarios', an FAQ based layout, with a 
menu of things like 'I have all my mail forwarded through my ISP', 'I 
send all my mail to my mailserver' and for each provide an explanation 
and an example record. Ultimately trying to cover all the 'Scenarios'.

Good idea.

-- 
              Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.