Joe Peterson wrote:
> Hi Michael,
>
> Thanks for writing about this. I suspect many are under the impression
> that passing messages through mail lists tended to break DomainKeys and
> DKIM (I know I was one, at least back when I was experimenting a lot
> with it). In fact, it always seemed to break on my Mailman lists,
> leaving what seemed to be a misleading result. It seemed that mail
> lists would need to "re-sign" messages as the new sender for it to work
> right, and did that not require the old key to be removed? Maybe things
> have changed recently, or maybe at least I misunderstood some aspects of it.
>
I'm not sure whether Murray's dkim milter allows you to sign with the l=
option or not, but setting the body length allows text to be appended to the
end of a message -- like a mailing list trailer. This combined with some
heuristics
with subject line modification gets you to nearly 100% success rates.
The only
other problem that I've had with mailman is that it sometimes reorders the
dkim-signature header field itself which causes the signature to break. I've
been trying to figure out where in the code it does that so that we could
either fix it or compensate for it when I'm creating the signature itself.
As for resigning -- that would certainly be a Good Thing, though not a
cure-all. It's always better to have more accountability rather than
less, but
a valid first party signature (ie, From) is best of all. But in its
absence, it
would be nice for a remailer to sign the message so that it's possible for
the receiver to whitelist them as a legit third party signer.
It's not entirely clear to me whether implementing it in the MTA or mailman
is better, though I suppose that there would be no harm having it in both
places as an option. It would probably be a pretty modest matter to
implement
a signer -- dealing with keys is really the biggest PITA.
> If, in fact, there is a way for the two to play well together, I think
> that would be great! It would remove one of the big "downsides" of
> using DK/DKIM. Since Mailman is one of the (if not *the* most) popular
> mail list systems, perhaps you can help Mailman developers to make the
> two things better integrated.
>
Yes, that would be most excellent -- I've been meaning to subscribe for a
while about these issues.
> I would think/hope there would be a way to increase the
> handling/interaction to allow for 100% reliable flow-through of keys.
> That would really help DKIM's cause, I think, since so many people use
> mailing lists. Is this not theoretically possible if both Mailman and
> DKIM obey an understood set of rules? I believe that a solid way to
> "fix" this is a lot better than a stochastic one.
>
I've for quite a while thought that part of an ultimate DKIM BCP would
give some guidance on what a "well behaved mailing list" would be. It
would certainly be good if mailman were an example of that because at
least at Cisco it accounts for the bulk of external mailing list traffic
we see.
> As for body length, would that not have to be a "guess"? I mean, short
> messages would fail due to the footer, and long ones would not get full
> checking (after the set length), right? If so, that sounds like a less
> than optimal solution.
>
No, the body length just counts the number of canonical bytes in the body
when it's computing the hash, so that if there are bytes that are
appended, it
doesn't affect the outcome. The lack of the l= tag implies that the entire
body is hashed which is most likely what the sendmail dkim milter does
(at least by default). The main issue is that there is a security/robustness
tradeoff with the use of l=. That is, bad guys could append content too.
On the other hand, *if* that comes to pass, receivers are completely at
liberty to scan the covered and uncovered parts of the body differently,
delete the appended text, etc, etc.
> I, for one, would love to see the email "accountability" problem solved.
> With spam becoming the one thing that could ruin the Internet, we need
> all the help we can get. I used DKIM for a while on my own server, but
> because of Mailman gotchas, etc. (and maybe these were more a problem of
> perception on my part), it seemed too easy to break. Also, with
> anything short of near global acceptance, it really seems like a tough
> battle, especially when so many are adopting things like SPF, which I
> never liked at all. Certainly, resolving the mailing list issue would
> be a huge step in the right direction, so consider me an enthusiastic
> supporter of your efforts.
>
Thanks, I appreciate that :) The one thing to be said is that you don't
actually
need to global acceptance to do useful things with dkim (though I'd
certainly be
happy if there were). The reason that Cisco deployed DKIM internally is to
counter spear-phishing attacks. That is, forged mail that is a targeted
social
engineering attack. For this, we just need to determine whether the mail is
or isn't from Cisco's servers and warn people when the message doesn't
verify
correctly. To pull this off, we need to keep the false positive rate
fairly low which
means that the legions of geeks using mailing list should mostly work.
Which is
why I was so alarmed to find out the newest versions of mailman was now
doing
the wrong thing.
In any case, backing out this change would go a *long* way to helping DKIM.
Mike
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
