On Tuesday 09 January 2007 23:02, Don Lee wrote:
On Wed, 10 Jan 2007, Julian Mehnle wrote:
| If at least one record is returned by the SPF-type look-up, no
| TXT-type look-up is performed (so nothing can go wrong with the
| TXT-type look-up in the first place).
|
| However, if the SPF-type look-up succeeds and returns 0 records, and
| the following TXT-type look-up errors or times out, then Mail::SPF
| throws a TempError even though it shouldn't.
I fixed this tiny bug already. Because it is so tiny, I won't make
another release immediately just for that.
...
While I'm sure this is what the spec requires, I'm no longer sure this
is a sensible behavior. Which means that there is probably a bug in the
spec.
Any comments?
Not knowing the details of the implementation, nor the spec all that well,
I have little right to an opinion. However, in principle, it is
very important to be able to tell the difference between an error
caused by data that was returned, and an error caused by a failure to
return a response.
Does the spec remain true to that idea?
As an example, I look up an A record for a domain name. I need to know
the difference between a response that says "no data" (I contacted a
server and there is no A rec
for that name) and an error that says "no response". (For some reason, I
could not get a response)
The former tends to be "perm" and the latter tends to be "temp". SPF
should follow this "principle of least surprise".
The reason the spec says to use the non-error response if you get an error for
one RR type and a non-error for the other RR type is that some DNS servers
will never answer for unknown RR Types. So these DNS servers will always
return a timeout (which is an error) for type SPF.
If we left it to return temperror for every DNS error regardless of RR type,
then domains using this type of non-responding DNS server who had never even
heard of SPF, let alone published records, would get a temperror.
The current approach is true to the notion that SPF is opt-in, which is, I
think, consistent with your concern.
Scott K
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735