Subject: [spfbis] Fwd: [spf-discuss] SPF and SERVFAIL

From: Scott Kitterman <[email-masked]>
Date: Tue, 03 Jul 2012 20:17:25 -0400

Given where the WG stands on SERVFAIL (it's still a temperror with the option 
to escalate to a permerror) I thought this was worth forwarding to the group 
for consideration.

Scott K

----------  Forwarded Message  ----------

Subject: [spf-discuss] SPF and SERVFAIL
Date: Wednesday, July 04, 2012, 09:36:26 AM
From: Wayne Doust <[email-masked]>
To: [email-masked]

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....

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.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 3 Jul 2012 21:47:24 -0400

Hi,

No hat.

> to escalate to a permerror) I thought this was worth forwarding to the group 

SPF depends on DNS.  In the DNS, SERVFAIL means the server you are
talking to failed, for some reason, you don't know what, and therefore
you should probably try something else -- try again later, try one of
the other authoritative servers, whatever.  Servers return SERVFAIL
when DNSSEC validation fails, when they're still loading the zone,
when they've just crashed and are restarting, and all sorts of other
reasons.

Now, I have no difficulty if the WG wants to say that a SERVFAIL gives
you no knowledge.  So NEUTRAL might be all right.  But presumably,
that ought to be true for other DNS error codes other than 0 and 3,
also, no?  If you get (for instance) REFUSED or NOTIMP, shouldn't they
be the same as SERVFAIL?

Best,

A

> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Jul 2012 20:57:22 -0700

> also, no?  If you get (for instance) REFUSED or NOTIMP, shouldn't they
My preference would be to point out that SERVFAIL can happen for any reason
other than total success of the query's resolution.  The error could be
transient, or it could be something severe.  Unfortunately, there's no way
to tell.  SPF verifiers should be aware of this and respond accordingly.
So basically, give implementers the knowledge they need to pick an
intelligent course of action, but don't specify what that ought to be.

I'd probably be comfortable advising against outright rejection, but I'm
not sure I'd recommend a specific SPF result code or neutral+deliver vs.
temp-fail.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 04 Jul 2012 10:54:19 -0400

> not sure I'd recommend a specific SPF result code or neutral+deliver vs.

Currently we say this is temperror on the first instance (which is consistent 
with the 4408) and then give the option to convert recurrences from the same 
domain as permerror on the theory they won't go away.  What receivers should 
do with a permerror is left unspecified.  

I don't think it's unreasonable to treat REFUSED or NOTIMP similarly, I've 
just never seen those come up in practice.  Equally, I don't think it's 
unreasonable to convert to none instead of permerror.  I think we should leave 
the initial temperror both because theses things do go away sometimes and for 
compatibility reasons.  

I think none is preferable over neutral because when these cases occur on 
initial lookup we don't even know if the domain has an SPF record.

Scott K