Dave CROCKER wrote: > On 10/1/2010 1:27 PM, McCann Peter-A001034 wrote: >> The fundamental problem with the current situation is that the >> authenticated identity is not displayed and the displayed identity is >> not authenticated. > > > Forgive my pursuing it in this fashion, but I'd class that as a first > derivative, rather than fundamental. (But, then, first derivatives > are important.) > > Fundamental is that DKIM is not trying to authenticate the message > and it is not trying to authenticate any identity such as From: > > It is merely trying to affix a /separate/ identifier, with a claim > that its being affixed is valid, but not that it relates to any other > aspect of the message. In other words, it is trying to identify > message streams, rather than "validate" messages or authors. > > The fact that DKIM uses underlying crypto algorithms keeps confusing > people into wanting to use it the way OpenPGP or S/MIME are designed > to be used. Ain't gonna work. > > d/
But DKIM does indeed bind an identifier (d=) to a message cryptographically in a way that allows an MTA to use the reputation of the owner of the (yes, separate) identifier when evaluating the spamminess of a message. The d= domain is the "authenticated identifier" to which I was referring. ADSP and the related third-party extensions try to create a binding between d= and From: but either break applications such as MLMs or create a provisioning problem where domain owners need to explicitly configure the third-parties that are allowed to sign their mail. These mechanisms are motivated by the fact that MUAs typically display the From: field and users tend to give credence to the identifier in this field when evaluating phishing messages. My point is that, rather than trying to authenticate this field with DKIM + ADSP, we should be encouraging MUAs to display the d= value and let the user independently evaluate the reputation of the signing domain and decide whether or not it was appropriate for the domain to sign mail with the given From: line. I can trust a message From: paypal.com but signed with d=mipassoc.org not because paypal.com has somehow "authorized" mipassoc.org but because I subscribe to the dkim mailing list and I know the context in which the message is being delivered. I would similarly know that my friend Joe has a vanity domain but uses google apps for his mail, and expect to see a d=gmail.com DKIM signature on mails from him. If this changes for some reason, I might call Joe and ask him if he changed providers. Even if the MUA doesn't display the d= domain directly, I can imagine they might implement security tools similar in spirit to some of the CA validation extensions for browsers that are available to warn the user in case the CA of a given website changes countries (see http://files.cloudprivacy.net/ssl-mitm.pdf). -Pete _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html