RE: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02
"william(at)elan.net" <[email protected]> Fri, 26 Aug 2005 16:20:14 -0700 (PDT)
| Newsgroups | gmane.mail.spam.spf.discuss,gmane.ietf.general,gmane.ietf.mxcomp |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 26 Aug 2005, Hallam-Baker, Phillip wrote: > As has recently been pointed out on the namedroppers list, the dual > track RR and TXT approach does not work. It leads to ambiguities when > the records do not match - which they will inevitably dur to the DNS > protocol. Actually what has been pointed out is that it is incorrect to make it a permanent error if the client when retrieving both RRs checks if they are the same and finds they are not because in some cases due to DNS caching the results would not be consistent even if on the server side it is (only a problem when record was recently updated). That does not mean you can't make it part of the spec that if both RRs are published they MUST be the same and that client should check SPF (type99) RR and if its not present then look for TXT RR. For those clients where algorithm like that is considered too slow (i.e. spamassasin which does all dns queries in parallel), then it will have to be that if SPF RR is received, its data is to be used (no matter if TXT RR as present or not). -- William Leibzon Elan Networks [email protected]