On 10/23/2010 12:25 PM, Barry Leiba wrote:
No, not at all. While I think it was probably a mistake to make the
signing of ANY header fields "MUST" (we should have just put "From" in
with the other "SHOULD" fields), the fact that "From" MUST be signed
says, in itself, nothing about the *validity* of the address (nor the
display name) in that field. That's up to the signer.
It's all a question of what the signer is willing to sign.
It is, I think, quite easy to read that last sentence as contradicting the
With respect to the validity of information, it most definitely does NOT matter
what is signed.
The choice of what to sign affects the robustness of the "tatoo" in affixing
d= domain. That is, it affects how easy or difficult it is to re-purpose the
signature with modifications to the message.
I have two
submission domains that I use. One, gmail.com, which does DKIM
signing, will only allow me to use a "From" address after it has sent
a test message to that address and seen that I can access the test
message. So it's made *some* level of confirmation that I owned the
address at the time I set it up.
Well, this is a reasonably common type of example. I think it confuses the
difference between a signer's policies, versus DKIM semantics. It is certainly
true that different signers have wildly different meanings behind their signing
behavior. However there is nothing in DKIM that communicates a signer's
policies. (Obviously, ADSP is an example of a value-added semantic, but as we
all have been reminding ourselves, that's an additional function.)
The critical point, here, is the question: What can the verifier know? They
cannot know about differential policies and in particular the choice of what
parts of the message are covered by the signature communicates no additional
The other submission domain I sometimes use, which does not currently
DKIM-sign, will let me put anything at all that I like in the "From"
The fact is that probably 99% of their users just use the proper
domain in their "From" fields, and it doesn't matter.
But that's all outside the scope of DKIM.
DKIM only provides
assurance of the *signing* domain, and that the message has arrived
substantially unchanged from when it was signed (modulo h= and c=).
It is possible to read the first clause as meaning more than you actually
so I'll suggest a slight tweak which is still what you meant:
DKIM only provides an assurance of the valid use of the signing domain name
(d=), and that the message...
NOTE WELL: This list operates according to