ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871bis-06.txt // Input requirements

2011-04-21 16:29:38
On Mon, 18 Apr 2011, Douglas Otis wrote:
One method to avoid look-alike or display-name attacks would be to sort
messages into folders.  A fairly common practice.

Users with the technical acumen to do such sorting are unlikely phish
victims.  They might not immediately recognize a message as forged, but
will instantly become suspicious if asked to "re-enter" passwords.

Once they detect such a phish, they may be annoyed, but they can then
implement a double-From: filter to drop future attempts on their own,
without needing an RFC to tell them so.

 From header field checks during signature validation would permit
simplistic phishing attacks not controllable by the domain being
phished.  :^(

Phishing attacks are *never* controllable by the domain being phished.
Nothing forces an ISP to deploy receiverside ADSP at all.

To change that, you need to invent some sort of certification for ISPs
that they take reasonable steps to prevent forgery.  Then banks could
impose a "phishing insurance" surcharge on any user who provides a contact
address at a domain that is not certified.

An explicit requirement to reject double-froms would be appropriate in
the standards for such a certification, but not in the draft at issue.

---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html