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
