> -----Original Message----- > From: [email protected] [mailto:ietf-dkim- > [email protected]] On Behalf Of Michael Deutschmann > Sent: Tuesday, March 01, 2011 6:12 PM > To: [email protected] > 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 <[email protected]> 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
