On 10/13/10 1:03 PM, Barry Leiba wrote: > 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.
Clarifying question: What does "this situation" (in the last paragraph) refer to: the use of an empty "g=" value, or an empty "g=" value absent a "v=" tag? -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html