This is a comment on the new section 3.6.1.1, "Compatibility Note for
DomainKeys", that suggests a different interpretation of the g= tag in
the key record if the v= value is not present at the beginning of the
record. The section says:
If a v= value is not found at the beginning of the DKIM key record,
the key record MAY be interpreted as for DomainKeys [RFC4870]. The
definition given here is upwardly compatible with what is used for
DomainKeys, with the exception of the "g=" value. In a DomainKeys
key record, an empty "g=" value would be interpreted as being
equivalent to DKIM's "g=*".
For about the past year, I have been monitoring Cisco's DKIM
verification and have collected data on verification and on verification
errors. An early summary of that effort is at
http://blogs.cisco.com/security/common_errors_causing_dkim_verification_failures/
Between June 1 and September 1, 2010, Cisco received invalid signatures
from 632 domains with "inapplicable keys" (meaning a g= mismatch). For
comparison, during that same period we received valid signatures from
33054 domains. Of these 632 domains, 390 use the same selector name,
which corresponds to the name of an email sending provider that has
gotten these domains to publish key records for its use. I have
contacted this email sending provider twice to make them aware of the
problem, but have apparently not succeeded in getting them to fix it.
All they need to do is remove the g=; tag from the selector records and
they will be compatible with both DomainKeys and DKIM.
Going back to the proposed change, it would create an ambiguity in the
spec: If a domain has a selector record with g=; and no v= tag, the
verifier MAY return a pass result. Or it MAY return a fail result. We
don't know what to expect; the result is undefined. Signers are not
well-served by mechanisms that don't consistently work.
I'm not in favor of creating an ambiguity in the specification in order
to accommodate a limited number of domains that can make a very simple
correction to their key records. Especially when the majority of these
domains are represented by a single email sending provider that
obviously hasn't even taken the trouble to see whether their signatures
verify.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
