Subject: DKIM, mailing lists, and bounces

From: Adam Roach <[email-masked]>
Date: Tue, 04 May 2010 22:40:28 -0500

Recently, I've been having more than a few headaches with the following 
situation:

   1. A mailing list subscriber sends an email to [email-masked]. This
      message contains a DKIM signature.
   2. The mailman instance at ietf.org modifies the subject line (e.g.,
      by inserting "[sipcore]" or changing "Re:" to "RE:"), and by
      appending a working-group specific footer. These changes
      invalidate the DKIM signature.
   3. Upon receipt, several of the mailing list subscribers' MTAs reject
      the message, since the DKIM signature does not match.
   4. After enough of these bounces, mailman unsubscribes the users
      whose MTAs check DKIM signatures.

I don't think we'll be able to stop people from sending DKIM-signed 
messages, so #1 really can't be helped.

Some of the recipients might be able to change their handling, but some 
cannot. For example, Rockwell corporate IT has been asked, and refused, 
to deactivate DKIM signature verification for messages originating from 
ietf.org. So, #3 really can't be fixed. This would be a hackish 
work-around anyway.

#4 is an additional headache, but stopping that behavior (in addition to 
introducing its own suite of problems) doesn't solve the root issue that 
subscribers aren't seeing everything sent to the list.

So that leaves #2. Of course, it makes perfect sense that the mailman 
software should be changing the Subject line. Perhaps not the 
"RE:"/"Re:" thing, but people pretty much expect insertion of the 
mailing list name in the subject. It also makes perfect sense that this 
invalidates the DKIM signature. So what's the right answer here? Should 
the IETF server be stripping the DKIM signature? Is there some allowance 
in DKIM for mailman to do something like say "the original sender said 
this, but I changed it to this"? Can we replace the original signature 
with one generated by ietf.org?

In other words: what did the designers of DKIM expect to happen with 
regards to mailing lists? What does the protocol anticipate we do here? 
Is the proper behavior supported by mailman?

/a

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 May 2010 23:53:56 -0400

On May 4, 2010, at 11:40 PM, Adam Roach wrote:
> In other words: what did the designers of DKIM expect to happen with regards to mailing lists? What does the protocol anticipate we do here? Is the proper behavior supported by mailman?

Mailman should be stripping the DKIM headers, since it, not the subscribers, is the intended recipient of the message.

---

From: John Levine <[email-masked]>
Date: 5 May 2010 05:42:30 -0000

>ietf.org.

Just to emphasize Barry's point, if they are dropping mail solely due
to signatures not verifying, their behavior is just wrong.  The DKIM
spec says what to do in this situation, but Rockwell's IT have done
something else which doesn't work.  I hope we agree that it's not a
good idea to try to work around someone's deliberate choice not to
interoperate.  While it would be a good idea in general for the IETF
to sign its mail, I doubt that would help in this case.

I'd offer the same advice we give to anyone else who's having mail
problems due to broken mail software, find a mail system that works.
The usual suspects are Yahoo and Gmail.

R's,
John

---

From: Adam Roach <[email-masked]>
Date: Wed, 05 May 2010 00:58:10 -0500

> to sign its mail, I doubt that would help in this case.

Actually, after a little bit of digging (I'm only vaguely familiar with 
the workings of DKIM, and I'd never heard of ADSP before tonight), it 
turns out that the sending systems are at least partly to blame in this 
mess. One of the senders triggering these problems has the following 
ADSP record published:

_adsp._domainkey.packetizer.com. 86400 IN TXT    "dkim=discardable"

So it appears that the systems that are bouncing email are doing so at 
the behest of the original sending domain. I'll be asking the owners of 
such broken ADSP records to do something more appropriate, but it does 
expose an interesting denial-of-service attack that we need to be aware of:

By installing a "dkim=discardable" record for their domain, anyone can 
knock some subset of subscribers off any IETF mailing list by simply 
joining the list, and then rapidly sending enough messages to trip 
mailman's bounce threshold. *poof* Anyone in a domain that honors ADSP 
is thrown off the list. As an added bonus, the mailing list 
administrators get a heaping pile of blowback to deal with.

/a

---

From: "John R. Levine" <[email-masked]>
Date: 5 May 2010 02:19:20 -0400

> the senders triggering these problems has the following ADSP record 
> published:
>

Sigh.  As one of the authors of the ADSP draft, my advice is that nobody 
should implement ADSP anywhere, ever.  This is exactly the situation I 
anticipated, the majority of people who try to use it will use it wrong 
and cause mail problems all over the place.

> By installing a "dkim=discardable" record for their domain, anyone can knock 
> some subset of subscribers off any IETF mailing list by simply joining the 
> list

Yes, we'll probably advise list owners to reject all mail from domains 
with adsp=discardable to prevent this kind of problem.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 10 May 2010 13:18:20 -0400

>> _adsp._domainkey.packetizer.com. 86400 IN TXT    "dkim=discardable"

I took another look at the RFC for ADSP, and in the examples in Appendix 
B, we say pretty clearly that if your users send mail through mailing 
lists, you shouldn't say dkim=discardable.  They were doing something we 
told them not to do.

I see that packetizer.com has gotten the hint and now says dkim=unknown, 
so they shouldn't be causing problems.  But if anyone else does that, it 
would be quite reasonable to suspend their ability to send mail to IETF 
lists until they fix their configuration to play nicely with others.

Paypal, who really should know better, publishes dkim=discardable but puts 
their staff email in the same paypal.com domain as their transaction mail. 
There are a few paypal people on the DKIM list, dunno about other lists, 
but if you're seeing more mystery bounces, look there.

R's,
John