-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
William Leibzon wrote:
Julian Mehnle wrote:
The more important problem (as I discussed in my last mail in this
thread from 5 minutes ago) I think is what to do if both types are
queried but the DNS queries' statuses differ.
Local preference of the system doing the check - they must choose either
of the record. If there were errors in checking one of the records, I'd
choose the one that did not cause an error. If one of the records
resulted in fail (as in ip address not in the list of sources that send
email for given domain) and other is pass on the safe side its probably
better to choose pass. Its possible that complex-enough anti-spam system
that does not make immediate reject/accept decisions (unlike mail server
doing test right after MAIL FROM) could use result from both TXT and
TYPE99 when they differ in it spam score computation structure. All of
those are of course corner-cases.
You are missing the point that this discussion is particularly about one
query returning RCODE 0 but no "v=spf1" records and the other query
returning RCODE != 0/3 or timing out. In that case there is no usable SPF
record.
Clearly this whole subject has had a lot of thought, so I am not
going to second-guess the judgements on this list. The current spec
has a workable solution, and is implemented and deployed in numerous
places.
That said, it always makes me queasy to "fix" something to allow for
old mistakes. If there is brain-dead DNS out there, the preferred
solution is to get those DNS servers fixed. If the implementation/spec
of SPF causes those domains served by broken DNS to get incorrect results,
AND it results in an incentive to fix the DNS server, then that's
goodness. Having SPF return "bad" results on broken DNS servers
only is bad if it appears to be a problem with SPF per-se, and/or would
result in some ugly problem (like servers randomly rejecting all email)
If the result of SPF not allowing for the broken DNS is otherwise
"harmless", I would counsel doing it "right", instead,
and let/expect the admins of the broken DNS to fix them.
For instance, if the broken DNS server ultimately caused SPF not to return
useful results for domains on that server that publish SPF, that would not
interfere with anyone's e-mail delivery, but in theory would provide
incentive to those using the server to get it upgraded/fixed.
When we promulgate a spec with return codes that are "non-obvious", we
push the "brain dead" behavior out into all the code that has to deal
with the non-obvious return codes. At least to me, returns of:
none = I got through - there are no SPF records
tempErr = I didn't get through. Try again later.
It is not wise to attach meanings to the return codes that will
require intimate familiarily with the spec to handle properly. Ultimately
this will result in a reluctance to implement as developers struggle with the
"strange behavior" of SPF.
Again, I see that this has been hashed out at length, so I want to defer
to the wisdom represented on the list, but
I always hate to see this sort of compromise, if a slightly cleaner
solution is possible.
-dgl-
-------
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