Mark Martinec wrote:
The draft-ietf-dkim-deployment-11 says:
If a DKIM verifier finds a selector record that has an empty "g"
field ("g=;") and it does not have a "v" field ("v=DKIM1;") at its
beginning, it is faced with deciding if this record was
1. from a DK signer that transitioned to supporting DKIM but forgot
to remove the "g" field (so that it could be used by both DK and
DKIM verifiers), or
2. from a DKIM signer that truly meant to use the empty "g" field
but forgot to put in the "v" field. It is advised that you treat
such records using the first interpretation, and treat such
records as if the signer did not have a "g" field in the record.
For this to work, it requires one to provide an explicit "v=DKIM1"
when a empty "g=" is intentional. On the other hand, the RFC 4871
clearly marks the v tag as entirely optional (yet recommended).
While I agree that a recommendation on how a verifier should handle
empty g tag does not belong into RFC 4871 (but only in dkim-deployment),
I think that a 4871 section 3.6.1 on tag g (or v) should require that
a 'v' is mandated if an empty granularity 'g=' is (intentionally) used.
I guess I should be paying more attention to the dkim-deployment drafts.
RFC 4871 is very explicit about the meaning of the g= value. Last
paragraph of section 3.2:
Tags that have an empty value are not the same as omitted tags. An
omitted tag is treated as having the default value; a tag with an
empty value explicitly designates the empty string as the value. For
example, "g=" does not mean "g=*", even though "g=*" is the default
for that tag.
The semantics of g= has no dependency on the presence or absence of the
v= tag/value. One of the ways of revoking a DKIM key is to apply a null
g= tag (g=;) which makes it unusable. Coming up with a way of guessing
whether the signing domain really meant "g=;" is not a good idea and
contradicts the specification.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html