spf-discuss
[Top] [All Lists]

Re: John Levine says: SPF Loses Mindshare?

2005-08-04 00:25:48
In <87zmry2rdw(_dot_)fsf(_at_)deneb(_dot_)enyo(_dot_)de> Florian Weimer 
<fw(_at_)deneb(_dot_)enyo(_dot_)de> writes:

Okay, what probably happened is that check_host() returned Neutral for
earthlink.net because they was no record, and "include:earthlink.net"
didn't match as a result.

check_host() should return PermError when there is an include: to a
domain that doesn't have an SPF record.  See section 5.2.

check_host() returns PermError when there's no SPF record for the
domain?  Interesting, so existing SPF implementations must have some
special case for the "no SPF record" case (see the comment about
SoftFail below).

I think this is a bug in the specification.  An "include" referencing
a domain without any SPF record should result in TempError, not
Neutral.

TempError is for things that will generally fix themselves without
manual intervention.  I don't think TempError is appropriate.

Unfortunately, we have no way of telling the two cases (permanent and
temporary inconsistency) apart.  IMHO, it's better to assume a
temporary inconsistency, especially since DNS does not prevent them at
a protocol level.  I guess existing standards try to make the
non-availability of DNS records a temporary error if this makes sense
at all.

If this is not changed, a very complex procedure is required for
updating SPF records which contain "include" mechanisms, at least if
you want to avoid bounces.

          This reduces the risk that legitimate mail is bounced
because the DNS is temporarily out of sync after a DNS update which
involves multiple zones.

(Note that single-zone updates are sufficient.  The situation is even
worse than I initially thought.)

The draft-mengwong-spf-0[01] drafts said that PermError (then called
"unknown") "indicates incomplete processing: an MTA MUST proceed as if
a domain did not publish SPF data."

I don't think this is unreasonable.

There were lots of objections to continuing this policy with many
people wanting to mandate rejection on PermError.

As a compromise, the current draft doesn't say anything about what you
should do when you get a PermError.

I believe there are still many implementations which treat this as
SoftFail and hence as Fail.