On 9 Aug 2005, at 5:23 PM, Eric Allman wrote:
I'm not sure that we aren't in agreement here. But I'm also not sure
that we are.
To toss my commentary in, I think we're within epsilon of agreement,
for many epsilon.
I find it helpful when I think of this to look at both sides of the
protocol, the sender and the receiver. When I am the receiver, a DKIM
signature tells me that (to use you as an example because your message
provides a particularly juicy one) that "sendmail.org" has taken
responsibility for the message. There's also this other bit of
qualification -- "eric+dkim" which is utterly irrelevant to me. It
might be interesting, but it's irrelevant. I know nothing about
"eric+dkim" which could be a "user" or not. (As a human being, I
strongly suspect that there is no actual account on a mailserver for
"eric+dkim" -- I suspect that there's actually an "eric" and the
"+dkim" part facilitates internal mail processing.)
So I validate the DKIM signature and when it validates I pass it on to
other parts of the mail processing system that process properly
authenticated email. Likewise, if it doesn't verify, I toss it off into
whatever subsystem handles invalid signatures.
That's it.
Now, on the sender side of the system, "eric+dkim" provides valuable
information for me. It lets me, as we know, use a different signing key
for it and other cute infrastructure setup tricks. But the most
important thing it does is to provide signed information to me about
valid, but improper messages. If an outside entity comes whining to me
about the content of a properly signed, validated message, then I know
whose knuckles to rap over it.
The i=/g= mechanisms are mechanisms for the *sender* that allow the
sender to partition the keyspace, provide internal accountability, and
so on. But they do not alter the fact that the *meaning* of the
signature is at the domain level.
Jon
_______________________________________________
ietf-dkim mailing list
ietf-dkim@mipassoc.org
http://mipassoc.org/mailman/listinfo/ietf-dkim