And assuming you tie client side whitelists to dkim i= ..
1. smtp auth is already a best practice and it's hardly likely you'd
find dkim deployers who dont already deploy AUTH, or run webmail
systems where you cant change the return path / if you can change it,
your actual user account gets stamped somewhere else (a Sender:
header, a X-Actual-User: cleartext or hashed header, etc)
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.
--srs
On Wed, Jan 28, 2009 at 12:00 AM, Suresh Ramasubramanian
<ops(_dot_)lists(_at_)gmail(_dot_)com> wrote:
On Tue, Jan 27, 2009 at 10:53 PM, J.D. Falk
<jdfalk-lists(_at_)cybernothing(_dot_)org> wrote:
It's irrelevant for purposes of spam filtering, but not for the equally
valid purpose of "is this message really from my grandma?"
(Or, more accurately, "is this message really from my grandma's email
address?")
1. Does her grandson run mailops at the receiver ISP?
2. Does the receiver ISP make finegrained control based on dkim sigs
part of the client experience for the user? Webmail possibly but from
a toolbar? And how do they stop it being gamed, how do they keep
state for millions of accounts, and then keep changing things around
when grandsom breaks up with one girlfriend, suddenly decides another
dude is a twit etc?
That's not layering trust as much as it becomes a gigantic social
networking site based on dkim, scaled large enough
--srs
--
Suresh Ramasubramanian (ops(_dot_)lists(_at_)gmail(_dot_)com)
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html