RE: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02

["william(at)elan.net" <william at elan.net>]

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
william at elan.net

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf