One of us should send in a separate technical erratum saying that DKIM
key records SHOULD be published only for SDID domains that have
corresponding MX or A records and can receive mail.
I believe your later posting on this retracted the suggestion, but this issue
strike me as one that is very easy (and common) to misunderstand. So it's
worth emphasizing. Might be worth adding tidbits to the Deployment draft?
The d= domain name is permitted to have /no relationship/ to any mail-sending
or mail-receiving domain name. Hence, no A, MX, or possibly /any(!)/ DNS
resource records for the name.
Right. You have to control the branch of the DNS tree where the d= domain
would exist, since you need that to be able to install the key records,
but the domain doesn't have to exist otherwise. Once you remember that
the big advance of DKIM over its predecessors is to separate the signing
domain from the domains in various other headers, this is clearly the
right way for it to work.
There might prove to be some benefits in choosing to have the d= name
match the name used for other purposes, but the design of DKIM does not
require it and it's essential that signers retain the choice.
The more I think about what it would mean to assert that an address in a
From: or other header is "real", the less I understand it. Sure, there
are trivial cases (that is, trivial semantics, not necessarily small
numbers of mailboxes) where an organization forces a 1-1 mapping between
mailboxes and people, but there's a whole lot of other ways that mail
works. What does it mean for the address sales(_at_)examp1e(_dot_)com to be
real
when there are 100 people in the sales department? Don't answer that,
just note that there is more than one possible answer.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html