On Tuesday, March 06, 2012 06:34:58 PM Alessandro Vesely wrote: > On 06/Mar/12 16:00, John R. Levine wrote: > >>> We seem to believe that the "D" part is deployed so that adding new > >>> "unknown" RRTypes is not an issue. > >> > >> I think this is correct, but OTOH someone recently asked about > >> possible issues in this area, and if I remember correctly, > >> received no response. > > > > Last month I ran into a guy on the dmarc list who complained that his > > server returns NOTIMP in response to queries for SPF records ("because > > it doesn't implement them") and clients were doing odd things. But > > it's been a long time since I've run into anyone else like that, so I > > agree, it's not an issue. > > Hm... I have no idea how such response gets cached. RFC 2136 says > that "an appropriate error will be returned to the requestor's caller" > when RCODE is SERVFAIL or NOTIMP. > > Is that the same case that Scott noticed when he wrote: > > Particularly when querying for SPF records of type SPF, persistent > 2 ServFail results are /not rare/. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00259.html > (emphasis added) > ? > > IIRC there was also a mirroring issue... > > At least, I think these issues will gradually vanish as the software > at the relevant servers gets upgraded. I don't think it's the same. It's been awhile since I had data because I simply stopped doing any type SPF queries in software I use or support due to issues with it (and there's no upside to go expend effort on revisiting the issue), but these were definitely SERVFAIL and not NOTIMP, but either would have had the same effect of a permanent "temporary error". Scott K _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf