Re: SPF and SERVFAIL

On Wednesday, July 04, 2012 09:36:26 AM Wayne Doust wrote:
> I perceive a 3-part problem with SPF and SERVFAIL.
> 
> 1) Most SPF implementations treat any failure in
> resolving/retrieving/parsing an SPF record as a TEMPFAIL and issuing
> 4xx. On the surface, this appears to be a reasonable approach - unless
> something in that process is broken....

I used to default temperrors to defer in software I maintain until I saw 
problems with exactly this kind of thing.  The problem is that there are 
actually lots of transient reasons that SERVFAIL can happen, so temperror 
actually appears to be the best result code for it (we discussed this in the 
IETF SPFbis working group that's chartered to bring SPF from experimental to 
standards track and that was the group's conclusion - I forwarded your mail to 
them, BTW).

> 2) Most mail sysadmins seem to have no idea on how to
> manage/tune/control their SPF mechanisms. They simply come bolted on to
> a mail filter appliance they own and they check the box that save "SPF
> Checking Enabled" and that's the end of the story. They also do not
> collect statistics; do no reporting and probably aren't aware of where
> (if any) log files are stored. This makes it difficult for them to
> resolve issues in part 1.
> 
> 3) The technical competence of the organisation or ISP seems to be
> inversely proportional to its size. This generally means the greater the
> effect on your organisation, the more difficult it is to get the remote
> organisation to even recognise a problem exists.
> 
> Over the past 12 months, I have had five incidences of remote mail
> servers rejecting email based on SERVFAIL. The problem has not been our
> DNS or our SPF record. It has been the problem of the remote mail server
> performing the SPF lookup and failing on "something". In most cases the
> other end has not been able to determine the cause and they have simply
> chosen to whitelist our domain - which IMO is not a solution and defeats
> the purpose of SPF.
> 
> One recent case involves a very large ISP in Australia. It has taken
> four weeks for them to recognise a problem exists.
> 
> That's four weeks of me calling them every day.
> 
> I suspect the problem lies in the lesser utilised features of SPF. Our
> record adds an IP4 netblock. Another domain has an include statement.
> These are the only two domains that have experienced problems with
> SERVFAIL. We don't use macros but I wonder how well some of the
> implementations will handle that?
> 
> IMO, the default and recommended response to an SPF SERVFAIL should be a
> NEUTRAL result. Ie treat the domain as if it had no SPF record at all.
> This would eliminate issues such as this which can only occur if the
> sending domain actually has an SPF record.

I see your record as "v=spf1 ip4:202.168.6.0/24 mx ptr ~all".  It's probably 
the ptr mechanism that is the source of your problem.  rDNS lookups can be 
quite problematic and it's possible to construct any SPF record you need 
without resort to it.  We've marked the ptr mechanism as "deprecated" and 
recommended people not use it in the RFC 4408bis draft we have in progress.

I suspect that without ptr, you'd be fine.  If there are authorized mail 
servers for your domain that aren't covered by ip4:202.168.6.0/24 mx, add them 
and then remove ptr.  If, as I suspect (because it's common), you added ptr 
just because a wizard of some sort suggested it, just remove it.

Scott K