Well, this is something we were forced to do in our implementation
because of the number of sites that still have legacy DomainKeys key
records, are now deploying DKIM, and have not updated their key records
to cover both cases. The number of such sites was sufficiently large
that we felt we had to do it.
It seems that the knowledge about the g=; difference needs to be out
there somewhere. And since, face it, DomainKeys was out there first, I
felt that DKIM implementations need to be able to handle the situation.
It does not need to be a MUST, because failing the signatures is a
viable alternative.
I think we're actually quibbling about wording. Here's a suggested
alternative:
====
Compatibility Note for DomainKeys
The definition given here for the key record is upwardly compatible with
what is used for DomainKeys, with the exception of the "g=" value. In
DomainKeys, a key record empty "g=" value is equivalent to "g=*", while
DKIM treats that value as matching nothing. The value "g=*" means the
same in both DomainKeys and DKIM.
DomainKeys deployers are encouraged to at least switch their key records
to using the equivalent "g=*" value, which works equivalently for both
DomainKeys and DKIM.
A DKIM implementation MAY choose to use the lack of a v= value at the
beginning of the key record as an indicator that the key record is a
DomainKeys key record, and interpret an empty "g=" value as if it were
written "g=*".
====
This wording reinforces your recommendation to use "g=*", and provides a
mechanism for DKIM implementors to use if they choose to deal with the
situation.
Tony Hansen
[EMAIL PROTECTED]
Jim Fenton wrote:
> 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
