No hat. On Tue, Aug 20, 2013 at 05:16:56PM -0400, Phillip Hallam-Baker wrote: > >From a pure protocol point of view the SPF record does have one major > advantage over TXT and that is in the use of wildcard records. This is an extremely interesting point, and I'm ashamed to admit I hadn't really thought about it from quite this perspective. I say that even though the draft contains some text that attempts to deal with wildcards and the WG discussed the issue from a slightly different perspective. I think it is worth considering. Note, however, that … > This has not been much of a problem because most of the other TXT overloads > don't have a use for a wildcard. There is not much point in a wildcard DANE > record. But it could be an issue. …it wouldn't be an issue for most of the cases where TXT is overloaded, because (partly due to the mess that SPF caused) most of the TXT overloads we see are now scoped using underscore labels, where the wildcard at a superordinate place in the FQDN isn't going to matter. Phill's is still a valuable observation, and one I think the WG actually didn't consider in every dimension. > The criteria to use to decide is not the proportion of SPF records > published as TXT vs SPF but what the validators look for. The WG had a hard time coming up with really good data about what validators look for, but to the extent we were able to draw conclusions about that the evidence was that virtually nobody is looking for SPF records. This is mentioned at the end of section 3.1 of RFC 6686. If someone else with some busy nameservers wants to provide different evidence now, it wouldn't hurt. We were unable to find anyone among the participating validators in the SPFBIS WG who was willing to argue in public that they felt the SPF lookup was more valuable to them, but we did have some large participants who said they did _not_ do the TYPE99 lookup except under unusual circumstances (the draft author, who is also the maintainer of an important SPF library, has already made this point elsewhere in this thread). Best regards, A -- Andrew Sullivan ajs@xxxxxxxxxxxxxxxxxx