I can see where this might not be desired. The fix for this that I
would suggest would be to put something in the key record saying that
the key can't sign for subdomains. Is this worth doing?
Hi, I'm back with another proposal that completely contradicts my
previous message.
I observe that generally speaking, the mailbox user(_at_)example(_dot_)com is
not
the same as user(_at_)sub(_dot_)example(_dot_)com(_dot_) And even if those two
happen to be
the same, they're probably not the same as
user(_at_)sub2(_dot_)example(_dot_)com(_dot_)
(There was an era when it was common to configure a cluster of
workstations to put the workstation name as a subdomain in your
outgoing return address, but that era only existed because of a widely
used but poorly configured default sendmail.cf and it ended about a
decade ago.)
So my suggestion is to leave the key and signature formats alone, but
to change the interpretation accordingly.
In section 6.1.2, the verification process, add a sentence to step 6:
If the "g=" tag in the public key does not match the local part of
the "i=" tag on the message signature, the verifier MUST ignore the
key record and return PERMFAIL (inapplicable key). If the local part
of the "i=" tag on the message signature is not present, the g= tag
must be * (valid for all addresses in the domain) or not present
(which defaults to *), otherwise the verifier MUST ignore the key
record and return PERMFAIL (inapplicable key).
(new part)
If the "g=" tag in the public key is present and is anything other
than *, and the domains in the "i=" and "n=" tags in the signature
are not identical, the verifier MUST ignore the key record and
return PERMFAIL (inapplicable key).
(end new part)
Other than these tests, verifiers SHOULD NOT treat a message signed
with a key record having a g= tag any differently than one without;
in particular, verifiers SHOULD NOT prefer messages that seem to
have an individual signature by virtue of a g= tag vs. a domain
signature.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html