On Tue, 18 Jun 2013, Douglas Otis wrote:
Trust in a DKIM signature is being used as a basis for acceptance as
described in section 5.4 in [RFC5863]. Since neither SMTP nor DKIM check
for invalid prefixed header fields, TBTB domains offer a simple means for
malefactors to have their deceptive messages delivered to their victim's
inbox. This problem is real.
Ukh. This again.
I think I see what the problem is with the DKIM design community.
Most of you assume that once DKIM and an accessory protocol of choice
(DMARC, etc.) reaches a sufficient amount of respect from the RFC
machinery, it will magically be deployed absolutely everywhere it is
relevant.
Otis is just a shade more humble. He thinks the magical deployment will
occur, but will be accomplished by a jerk literal genie, who will try to
pass as much bad mail as possible while keeping to the letter of the
final DKIM spec.
In reality, the recipient end DKIM deployment will be driven by
sysadmins representing end-users who want less bad mail to reach them.
Unlike the participating senders, they are not afraid of a phish or
virus mail succeeding --- they merely do not want to be disturbed unless
the mail is actually relevant.
(So if Otis' attack actually gets used, it will be in the selfish
interest of those domains to filter it, there being no legitimate use for
double From:s. SpamAssassin would likely pick it up, resulting in sites
that block the attack mails while not even using DKIM.)
The accessory protocols I've seen are unusable senderside even by my
vanity domain, let alone casual users, because of the mailing list
problem.
Those who believe in magic deny this is a concern, because despite the
fact that we represent the vast majority of senders, we aren't "phish
targets". But if extra context is only provided for the tiny fraction of
mails purportedly from "phish targets", then DKIM isn't worth my while to
deploy receiverside.
(I have deployed DKIM alone senderside, but that's just to keep in
practice in case someone invents an accessory protocol that's actually
sane. Allowing me to declare that all mail bearing my RFC821 MAIL FROM:
without a corresponding signature is bogus while saying nothing about
that which merely bears my RFC822 From: would be a good start.)
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html