spf-discuss
[Top] [All Lists]

Re: John Levine says: SPF Loses Mindshare?

2005-08-04 06:53:40
* > In <87acjy10p6(_dot_)fsf(_at_)deneb(_dot_)enyo(_dot_)de> Florian Weimer 
<fw(_at_)deneb(_dot_)enyo(_dot_)de> writes:


Ok, yeah, check_host() returns None, 

I don't think this follows from the specification.  "None" is only
returned when the name server returns NXDOMAIN, but not for the
(artifical) NODATA failure (no error, empty answer section).

The spec says that check_host() returns "none" in the following cases:

* When the domain is invalid, malformed or non-existent (Section 4.3)

* When no SPF records are returned (Section 4.5)

NODATA will return no records, and therefore will return "None".

Okay, fair enough, I was a bit confused.

There are two authoritative name servers for example.net,
ns1.example.net and ns2.example.net.  Assume that ns2.example.net has
not been updated yet (there's always some propagation delay for
updates).  A client resolves the example.net/IN/TXT from
ns.example.net, parses it, and looks up the referenced record
spfv1.example.net/IN/TXT.  The resolver decides to fetch this record
From ns2.example.net for load-balancing purposes, and gets a NXDOMAIN
error.  Hence the SPF check returns PermError, even though this is
just a tempoary error condition.

Well, don't do that.

This is hard to avoid.

If you are concerned about this kind of thing, make sure that the
target of the include: is defined and well propogated before you use
it.

The difference that a wrong MX record doesn't cause mail to bounce as
long as there are other, valid MX records.  Consequently, you can
migrate your mail servers by listing old and new ones temporarily.

In contrast, SPF does not seem to allow this.

The same kind of problem can happen with MX records pointing to new
hosts.  This really isn't an SPF specific problem.  Hmmm... I guess
the example of MX records can trigger a problem with something like
"v=spf1 mx -all" also.

Indeed.  I'm not sure what the exact implications are, I'll have to
think a bit about this.  Because of the propagation delays, DNS-driven
policy has nasty side effects, some of them are quite well-known
(e.g. MX-based relaying opt-in).