#27 granularity compatibility - suggestion by dkim-deployment

[Jason Long]

The draft-ietf-dkim-deployment makes a compatibility suggestion,
perhaps it could be incorporated into Mail::DKIM.

http://tools.ietf.org/id/draft-ietf-dkim-deployment-11.txt

A.1.2.3. DNS Selector Key Records

The format of the DNS key record was intentionally meant to be
backwardly compatible between DK and DKIM, but not necessarily
upwardly compatible. DKIM has enhanced the DK DNS key record format
by adding several optional parameters, which DK needs to ignore.
However, there is one key difference between DK and DKIM DNS key
records: the definitions of the g fields:

g= granularity of the key In both DK and DKIM, this is an optional
field that is used to constrain which sending address(es) can
legitimately use this selector. Unfortunately, the treatment of
an empty field ("g=;") is different. For DK, an empty field is
the same as a missing value, and is treated as allowing any
sending address. For DKIM, an empty field only matches an empty
local part.

v= version of the selector It is advised that a DKIM selector have
"v=DKIM1;" at its beginning, but it is not required.

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.

[Jason Long]

FYI- the dkim-milter and "OpenDKIM" implementations have this feature available as a configurable option, off by default.

Also, the above recommendation is now part of RFC5863.