-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Michael Deutschmann
Sent: Tuesday, March 01, 2011 6:12 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Full name problem
On 27 Feb 2011, John Levine wrote:
Um, you must be new here. We've argued about this ad nauseam
over the years.
I've been subscribed since Janurary 2008. Although my eyes may have
glazed over during some of the longer threads....
There are two uses for a protocol similar to DKIM/ADSP.
#1: it can be used as one of many general mailbox decluttering
weapons,
reducing the amount of "bad mail" of various sorts that the end
recipient
has to sort through with his own eyes.
#2: it can be used to stop phishes from being successful, by
preventing
gullible users from even seeing them.
DKIM signing in and of itself is neither #1 nor is it #2. In the
broadest sense it is simply a party signing a message and taking
"responsibility" for it. When we get into a discussion of 1st party vs
3rd party signatures it is possible to infer specific value in terms of
phishing with regard to the From email address (which is where ADSP
comes in).
The immediate responses I'm getting in this thread suggest the
intended
mission of DKIM is #1. Which is what I thought in the very first
place,
as the Full Name Problem makes mission #2 rather problematic.
And yet, two things on this list seem to indicate that there are
people
here who think #2 is the mission:
First, there's the whole double-From: fuss. The demand for coercive
language on this minor point only makes sense on the assumption that
the
recipient admin is not eager to block suspect mail; that he is only
implementing ADSP for some sort of Good Netizenship ticklist.
The fuss centers on specific technical attacks that have been
identified. While the problem is broader than DKIM, they create problems
that potentially reduce (subvert?) the value of the DKIM signing
proposition depending on what a validator does and how the message is
subsequently handled.
Second, one of the responses I've gotten to my "except-mlist" proposal
is that the domains for which it would be superior to TPA (consumer
ISPs, basically) are not phish targets. That is true, but it is only
a
counterargument under mission #2. Under mission #1, it is just as
valuable to block *@gmail.com forgeries as *@paypal.com forgeries.
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
The display name is problematic as Mr. Crocker has pointed out. One
solution to this which I have suggested in the past is to not display
the display name in the MUA if the email fails to authenticate. This
would require reaching some tipping point in authenticated mail
implementation where receivers/MUA providers perceive a value
proposition that provides benefit greater than the perceived detriment
for legitimate mail which is not authenticated.
Such an approach also raises the hackles of some email purists.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html