>> 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 [email protected] 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
