ietf-dkim
[Top] [All Lists]

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

2011-04-15 23:44:49
On Fri, 15 Apr 2011, Douglas Otis wrote:
In addition, verifiers MUST
ensure the presence of multiple singleton originating header fields
do not provide a valid signature result.
---

Not including this additional requirement removes recipient assurances a
sender may have expected to be offered by DKIM.

Not... This... Again...

There are already other ways to get a phish past an unsuspicious user in
spite of DKIM/ADSP.  The full name trick is one, mi5pe11ings are another.
Also rather important is that few users are likely to have the thing armed
to block mail.

You're basically trying to weatherstrip a barn door that we have no idea
how to even close.  Pointless.

(Also, the extra filtering you want would quickly be added to
SpamAssassin anyway, once people try to exploit it.)


Requirements to strictly enforce the message format do have a place, but
in a different RFC.  Such an RFC would outline minimal standards for
supression of forgeries.  Email providers who follow this hypothetical
RFC would advertise that fact, and then phish-target sites might reward
users who provide a contact address at a compliant site.

But you'd need to put a lot more than just a reference to ADSP and your
enforcement of a unique From:, to make such a document viable.

Otherwise phish-targets won't offer sufficient reward to be worth the
tech-support hassle of being unable to disable ADSP (lest they lose
compliance) at the request of a user with a false-positive problem.

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