Getting a little caught up... I don't think this is the right direction to go with this. Even though it shows up in many of the DomainKeys examples, there isn't any reason I can think of to include an empty g= tag in a DomainKeys key record. This proposal adds additional logic to the verifier to handle this case, and will need to be included in order to be standards-compliant long after DomainKeys is, practically as well as formally, historical.
Also, this proposal would immediately make nearly all existing DKIM verifiers non-compliant until they incorporate the additional logic (the "should be interpreted" would really need to be a "MUST be interpreted" in order to make the spec appropriately normative.) Unless someone can suggest a reason that DomainKeys records need to include g=;, I suggest that instead there be a Compatibility Note for DomainKeys that recommends against the use of the g= tag in key records except when the intent is to match the local-part by using a non-null value. -Jim Tony Hansen wrote: > I just filed another errata against 4871. It reads as follows. > > Tony > > Section 3.6.1 says: > > N/A (see Notes below) > > It should say: > > Add text similar to the following: > > Compatibility Note for DomainKeys > > If a v= value is not found at the beginning of the DKIM key record, > the key record should be interpreted as for DomainKeys [4870]. 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 should be interpreted as being > equivalent to DKIM's "g=*". > > Notes: > > There should be a note added somewhere to section 3.6.1 saying > that if a v= is not found at the beginning of the DKIM key > record, the DNS key record should be interpreted as for DomainKeys > and described in RFC 4870. In addition, a note should be added > about the difference in the interpretation of an empty "g=", > which is the only incompatible tag. > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
