DKIM L=Tag Exploit, two months later: Status and data


Last week on the Valimail blog, I shared a status update on the DKIM L= tag vulnerability that allowed bad guys to repurpose signed email messages, replace or append their own bad content, and then re-inject the content into the mail stream, having it then pass DKIM (and DMARC) successfully, hijacking the signature from a message sent with somebody else's domain.

I've also summarized it in a quick little video here, where I share a bit more data on what I'm seeing as far as messages in my own mail streams showing DKIM signatures containing the L= tag. TL;DR? They're still out there, volume perhaps down a tiny but, but we've got a ways to go to continue to work to get folks to remove the L= tag from their DKIM signature configuration.

A few of us have had some success notifying senders utilizing the L= tag in their DKIM configuration and convincing them to remove it, and I would encourage folks to please keep doing that. Or start doing that, if you can.

Why should people ditch the L= tag from their DKIM signature configuration?

  • It's an outdated setting meant for discussion email lists. It doesn't provide any sort of modern, useful feature or functionality.
  • It limits what parts of a message are protected by a DKIM signature. Years ago this might have meant reducing CPU overhead for generating DKIM signatures enough to matter in a production MTA environment. Today, not so much. Nowadays, it just means that messages aren't fully protected.
  • Gmail explicitly recommends against using the L= tag in your DKIM configuration.
  • Based on whispers I've heard through various channels, certain mailbox providers will or already do treat messages containing a DKIM signature with an L= tag as unsigned, losing the benefits of DKIM authentication.
  • And the overall issue here, really, is that bad guys can reuse your messages to send unwanted bad things in email, using your domain. Depending on the L= tag configuration and overall DKIM configuration, it may or may not be easily done, but why risk it?

Got any questions about this DKIM vulnerability? Feel free to drop me a line.

Post a Comment

Comments