On Sat, 2005-10-29 at 20:02 +0200, Eliot Lear wrote: > Eric, > > Thank you for your comments. > > > Indeed, if what you wanted to do > > was stop message forgery as a general case, you would have to > > consider the issue of forgery by other authorized users in > > the same administrative domain, which generally leads to an > > S/MIME style solution. > > While it is true that a wide deployment of S/MIME may limit forgery, it > is perhaps not the only way, and so let me suggest that where you say > "generally" we are now outside that realm. > > Here the problem is broken into several parts: verification that a > message came from an administrative domain and verification within the > administrative domain. Mechanisms exist within an administrative domain > to verify identity of a sender. Those methods can be improved. > Dramatically, IMHO. But that needn't be something for DKIM. > > To tackle *spam*, reputation must be considered. That needn't be done > by DKIM but it must be done. I haven't seen a strong argument that the > reputation component should be done within the IETF, as no protocol > requirements to do it have been identified. What is clear is that > reputation cannot be considered without something like DKIM. > > Would you agree or disagree with the above statements?
The scope of DKIM should be limited to identifying the domain accountable for the email message transport system. Attempts to broaden the scope of DKIM to include the author via ill-conceived policies derived from _many_ DNS lookups is sure to derail a DKIM effort. The charter has already attempted to exclude overlapping efforts related to OpenPGP and S/MIME. These author related efforts should be placed out of scope. With respect to phishing, the vast majority of MUAs only display the "pretty-name" which significantly reduces the merit related to attempts at exclusively protecting the From header, especially when the disruption to email related services is considered. A practical means to eradicate phishing attempts requires examination of the message content. If any URLs within the message look to point to a phished domain, and the DKIM signature of the message does not match that of the phished domain, this would be a highly suspicious message. Detecting the phishing attempt would _not_ rely upon the From header. Being able to determine which domain is accountable for the email message transport system will have a significant impact upon an ability to eradicate phishing attempts irrespective of the message's headers. It is far more likely that content of the message will trigger the isolation of the phishing attempt. I agree with Eliot that the reputation of the domain accountable for the email message transport must be defended. The current DKIM draft ignores this issue completely. I will also add that there is an alternative threat-review written with respect to DKIM that attempts to explore this issue. The efforts used within our protective strategy have been successful and are suggested in this draft. Currently, these techniques already account for a _major_ portion of the spam blocked. These techniques are unrelated to traditional real-time black-hole list, but instead respond to current exploits. The html version of is at: http://www.sonic.net/~dougotis/id/draft-otis-dkim-threats-01.html http://www.sonic.net/~dougotis/id/draft-otis-mass-reputation-03.html These are also published as IETF drafts. -Doug _______________________________________________ ietf-dkim mailing list http://dkim.org
