Dave CROCKER wrote:
Suresh Ramasubramanian wrote:
2. DKIM signs all the headers and validation of that hash tends to be
useful to verify grandma is who she is. Or at least its her, or its
comrade botmaster who's just taken over grandma's PC.
This is a common misunderstanding of DKIM:
1. DKIM doesn't have to sign all the header fields.
2. Independent of how much or little it signs, a DKIM signature does not mean
that any of the content is "valid", merely that data integrity has been
maintained. In particular, there is nothing that says that the author field
accurately states who created the message.
What is delivered can be verified as what was sent. But what was sent is
still
free to be incorrect.
With DKIM i=, it becomes possible to convey a stable identifier (though of
course there's no guarantee that the identifier is stable, leading to John's
t= suggestion.) Without DKIM (or something like it), as we know, any
potential identifiers are trivially forged.
As Suresh pointed out, DKIM doesn't convey anything about who is using
Grandma's login credentials (in the case where Grandma's login credentials
can be associated with a stable, authenticatable identifier), but I'd say
that's out of scope here.
--
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html