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