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