> 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?
The latter, the "can't tell" situation. We can tweak the text to make that clearer, if the WG wants this change. Barry On Wed, Oct 13, 2010 at 5:34 PM, Jim Fenton <fen...@cisco.com> wrote: > 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