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=*".
...
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.
What, specifically would you like to have done with the text?
I propose removing section 3.6.1.1 in its entirety.
I thought we'd had this discussion before, and what's there was what
we decided to do. Search facilities are inadequate for easy checking.
I certainly think that pointing out the ambiguity issue is important,
so I, as a participant, wouldn't want to remove it entirely. Allow me
to suggest the following alternative text, and ask other participants
to weigh in on which you prefer:
3.6.1.1. Compatibility Note for DomainKeys
Key records for DKIM are backward-compatible with key records
for the now-obsolete DomainKeys [RFC4870], except in one
circumstance: DomainKeys interpreted an empty "g=" value to
match any signing address ("i=" in the signature). In DKIM, that
matching is done by "g=*", or by omitting "g=" and taking the
default behaviour. An empty "g=" value in DKIM will match only
empty "i=" values.
If a key record uses an empty "g=" value and also uses "v=",
the key record can be identified as belonging to DKIM, and the
DKIM interpretation will be used. Absent a "v=" tag, though,
the verifier cannot tell whether the signer intended the
DomainKeys interpretation or the DKIM one.
To avoid second-guessing in a security context, and because
DomainKeys is an obsolete protocol, DKIM verifiers MUST
interpret this situation in DKIM terms, matching only
empty "i=" values.
Barry, as participant
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html