Dave CROCKER wrote:
>> Not only is it confusing, it's wrong. Wildcard records work just fine when
>> the
>> wildcard is below the _domainkey label, e.g. *.foo._domainkey.example. They
>> work
>> less fine in other cases.
>
> The modified text I offered is intended to handle several coverage problems
> with
> the original text, including the one you cite. Are you suggesting that it
> does
> not succeed? If so, what text do you instead suggest?
Dave,
I believe the text needs to include guidelines not just for DKIM
clients but for DNS software manager authors or administrators. This
issue started (by me) because a ISP vendor (one of the largest) that
did not offer a clear way in their web based "DNS Manager" for their
customers to add explicit DKIM TXT records and the method offered
lumped TXT records subdomains with wild cards. As a result, the
order was such that SPF records were returned as well.
So its not just about the DKIM clients being aware of multiple TXT
segments. The spec audience will probably include HOSTING sites people
that will look into how DKIM records is implemented and offered to
this customers.
I think text as simple as follows should be considered (note, I am
just providing a starter, not saying these are the exact words)
DNS hosting administrator and developers should offer the ability
to add DKIM records that will not conflict with another other DNS
(TXT?) query protocols and is not part of the wild card results.
PS: As I recall, the issue for the customer was resolved with the
vendor after the support incident was raised beyond the normal help
desk level. Keeping the same interface, a new undocumented input
format syntax was provided for adding the TXT subdomain record that
was not part of the wild card results.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
