In <200701092135(_dot_)15176(_dot_)scott(_at_)kitterman(_dot_)com> Scott
Kitterman <scott(_at_)kitterman(_dot_)com> writes:
On Tuesday 09 January 2007 19:43, Julian Mehnle wrote:
Julian Mehnle wrote on spf-devel:
We were talking on #spf.
FYI, I brought up there the fact that Mail::SPF was generally RFC-
conforming except for one odd case:
| Currently, Mail::SPF ignores DNS errors on the SPF-type look-up but
| fully escalates them on the TXT-type look-up. So if "all look-ups
| that are made" get a DNS error (other than NXDOMAIN) or time out, then
| Mail::SPF does the right thing because the TXT look-up will throw a
| TempError.
|
| 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.
FYI, this has now been fixed with the 2.003 release of Mail::SPF. From the
changelog:
| * Fixed a very minor bug where a "TempError" result would incorrectly be
| returned in the very rare case when the SPF-type look-up succeeded but
| returned 0 records, and the following TXT-type look-up errored or timed
| out. Now a "None" result is correctly returned in that case as
| demanded by RFC 4408.
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?
To summerize what I said on IRC for the benifit of the rest of the crowd...
Before RFC 4408 AUth 48 we returned a TempError if _either_ of the lookups
yields an error RCODE or a timeout and a permerror if the returned content
was not identical. As a result, TXT = None and SPF = timeout was a
temperror. The problem we were trying to fix was brain damaged DNS servers
that can't deal with unknown RR types and just return nothing.
I haven't poked my head into #spf for a day or two and I'm already 80+
messages behind on spf-discuss so far this year, but...
Yeah, this is my recollection also.
The use of type99 SPF records must be optional, in order to maintain
backwards compatibility with existing implementations and
draft-mengwong-spf-0[01].
I had *hoped* that we had also made TXT records optional so that if
anyone is foolish enough to do it, they can insist on only checking
type99 records. I figured that would make the IETF DNS folks happy.
This leads to the obvious problem: What to do if the results of only
checking one type of RR will be different than only checking the other
RR type?
My hope is we left that undefined, but I haven't reviewed RFC4408 to
make sure.
I know that we got rid of the "must return an error if the TXT and
type99 RRs aren't the same" thing because of DNS caching skew problems
made it impossible to prevent this error from happening at least some
of the time. So, there are certainly cases where you could even get
an SPF Pass if you only check TXT records and an SPF Fail if you only
check type99 records.
For practical purposes, I would think trying to return the same result
as if you only checked TXT records would be most useful. I know that
RFC4408 conflicts with this idea in the case of TXT vs type99
mismatches though since any valid type99 record means that you have to
ignore the TXT record.
-wayne
-------
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