John, The reported issue was about *mixed* TXT usage caused by wildcards. And it amounted to a large Domain Hosting vendor ONLY offering this for spf:
*.example.com IN TXT "v=spf1 .........." And that created mixed query results after adding DKIM related TXT records. The proposed correction text is a) reminder to avoid using them and b) for verifiers to be ready to deal with it. i.e. be able to parse for the right DKIM related text string. -- HLS John R. Levine wrote: >>> Forgive me if I repeat myself, but I still don't see anything wrong >>> with this: > >>> *._domainkey.example.com IN TXT "v=DKIM1; p=; n=revoked" > >> Do you have an actual use case for that sort of thing, or is it just >> an example to poke at the "thou shalt not wildcard" wording? > > That example above revokes all unknown keys. > > On this message, I've encoded a timestamp and the pid into the DKIM > signature selector, so I can use my DNS query logs to get an idea of > who's checking the signatures on what messages. > > These may not be fabulous uses of wildcards, but they are at worst > harmless. There's a lot of places in the DKIM spec where we say if you > do so-and-so, you'll be sorry. I'd like to avoid saying that unless we > have a good reason to do so, and I only see problems with wildcards > above the _domainkey label. > > Regards, > John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. http://jl.ly > > > ------------------------------------------------------------------------ > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
