ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion

2010-05-28 01:37:25

On May 27, 2010, at 10:02 PM, Scott Kitterman wrote:

...
 1. Do we want to reduce the DKIM broken signature rate or do we want to
make ADSP less vulnerable to it. Or both, I guess.

 2. If we want to reduce the DKIM broken signature rate, do we need to
rework DKIM at all, or do we need to make operational recommendations to
the generator and signer of the mail, or do we need to provide
operational advice to forwarders and mailing list managers. For any of
those we need to balance the improvement against the reduction in
deployment and reduction in correct deployment the increased complexity
will cause. The history of SPF-all and SRS is likely relevant there.
...

I'm curious what level of reliability you think DKIM signatures have
currently?

I just measured 72% broken in one case, and it's one that's
not that atypical.

It'll depend on the sort of mail you're talking about. For mail that's
drafted carefully, and avoids doing anything (mime encoding,
charsets) that might trigger MIME level rewrites during delivery, that's
sent by a competent bulk mailer from well configured smarthosts
directly to the MXes of a major consumer ISP I'd expect them to
be extremely robust as measured at the MX. 

If your favorite use case of ADSP is bulk business-to-consumer mail
sent from domains dedicated to sending solely that sort of mail,
with no usage by employees, role accounts, customer support
and so on then that's really good news. You'd need to start your
email business unit pretty much from scratch to be able to do
that, though. Also, I work with quite a lot of bulk mailers, and
consistent operational competence of the level required is much
rarer than you might hope.

For mail that's being sent through any less well understood path
there's risk of the mail being rewritten or lightly corrupted to an
extent that it'll break the signature simply as part of SMTP forwarding.
A common cause of this is mail being forwarded from a
mail filtering appliance to an internal Exchange server. I've seen
a bunch of obscure MIME rewriting and corruption issues in that
case (our app used to express the same strong opinions at an
ESMTP level that Exchange does, so I spent a long time tracking
down a bunch of oddities there). I've no idea how widespread this
sort of issue is, but I've seen problems that I think might cause
this sort of issue at maybe 10% of my customers.

For mail that's being sent through actual forwarders it's somewhat
worse, as they're even more likely to annotate headers or body,
modify headers or redraft MIME structure. Even "invisible" forwarding
such as .forward files can break things when the mail is annotated
by spam filters, then forwarded.

All of the above can be mitigated somewhat by being very
cautious both in generating mail content and by choosing
which header not to sign, I'm sure.

There there are mailing list managers - all bets are off, they tend
to rewrite most everything and will break signatures more often
than not. The only good point there is that the sender probably
knows they're sending to a mailing list.

 And are you measuring at a border MTA or somewhere later in
the delivery chain?

I've been considering the state at the border MTA. I suspect it'll be a
little worse later in the delivery chain, typically, but that's going to
vary significantly based on the delivery path. I think there's going
to be a large systemic component and a much smaller random
component.

And with that, I declare it the end of the week. Have a good
slow Friday and Memorial day long weekend, everyone, if
you're in a bit of the world that observes that.

Cheers,
  Steve

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html