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
tony(_at_)att(_dot_)com
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