Signing outbound list mail with OpenDKIM

For my server running the discussion mailing lists that I host, I'm running OpenDKIM, OpenDMARC and Postfix on Ubuntu. I run a custom mailing list manager that I wrote myself; I keep telling myself that eventually I'll polish the code enough to share it with the world.

I wanted all posts to the mailing list to be signed with the DKIM signature of my mailing list domain name. Any DKIM signature the message was initially signed with when submitted to the list is rendered invalid by the header changes my mailing list software makes before distributing the posted message to all subscribers. Thus, mail would have been distributed to subscribers either with no signature or with a now failing signature. I feel strongly enough about email authentication to be dissatisfied by that; I want all mailing list messages to clearly demonstrate to the world that my server, my domain is responsible for the list mail.

To do this, I would in theory want to add OpenDKIM's "SenderMacro" directive to opendkim.conf. Except, support for SenderMacro is not compiled into OpenDKIM by default. No big deal, right? My brain shouldn't have atrophied too much from when I had a day job as a unix system administrator; I can just recompile it. But, it turns out, compiling OpenDKIM from source on Ubuntu is a hugely frustrating pain in the ass, with a ton of dependencies that I had to solve for manually, and package names that correspond to the absent library names in almost no way whatsoever. And even after I got it all compiled, there still ended up being a path issue with locating libraries at runtime that I just was not able to figure out. In theory I know how to fix that, but in practice, it just didn't work no matter what I did.

But then I stumbled across a much simpler way to do this: The "SenderHeaders" directive. The OpenDKIM README has a helpful section on mailing lists, where it explains that you can add this directive and set it to "Sender, From" to tell OpenDKIM, when deciding whether or not to sign the mail, look first at the domain in the sender header, then if that doesn't match the list of domains you sign, look at the From address domain to find a match.

My mailing list manager software doesn't use a sender header. I could easily add one, but I don't really like how that displays in the user interface of certain MUAs. Thankfully, the OpenDKIM documentation suggests an alternative header: "List-Post." Most mailing list manager software, including mine, includes a header designating what address you send to if you want to post a message to the mailing list. (The header looks like this: "List-Post: <mailto:LISTNAME@example.com>.")

I decided to give that a try and updated the SenderHeaders directive to read "SenderHeaders List-Post,Sender,From" and it worked! OpenDKIM looks at the List-Post header, sees a domain there that I can sign mail for, and it signs the mail with the key for that domain. The net result, all messages to the mailing list a signed with my DKIM key automatically.

Yahoo on Yahoo's new DMARC Policy

What impact has Yahoo's new "p=reject" DMARC policy had on spam claiming to be from Yahoo.com? "DMARC has reduced spam purported to come from yahoo.com accounts by over 90%," says Alex Stamos, Yahoo's Vice President of Information Security, in his recent testimony before Congress.

H/T: Return Path's Ken Takahashi.

(Note: Alex's title may be Chief Information Security Officer; I've seen him referred to both ways. I decided to use the title referenced in the testimony.)

The Current State of TLS over SMTP?

Michael Adkins, Mail Integrity Engineer at Facebook summarizes it thusly:

"STARTTLS encryption is widely supported and has achieved critical mass despite some issues with certificate management. A system deploying STARTTLS support for the first time can expect more than half of its outbound email to be encrypted. Also, the majority of deployments provide Perfect Forward Secrecy. We see two high priority areas for improvement. First, we encourage the industry to work together to develop better tools for preventing mismatched certificates. Second, we encourage everyone to deploy support for opportunistic encryption via STARTTLS."

TL;DR? Turn on opportunistic TLS, and if your results are like Facebook's results, at least half of the time your mail will be encrypted in transit. This is a very good thing, and adoption is only going to grow, especially when you've got a big site like Facebook who sends a lot of mail, helping to gently nudge folks in the right direction.

Want to learn more? Steve Atkins explains how to Protect your email with TLS over at Word to the Wise.

Yahoo Groups rewriting from addresses to handle DMARC policy

As reported on the Mailop list today, Yahoo has modified their Yahoo Groups discussion group service to "play nice" with posts from subscribers at domains behind a restrictive DMARC policy. Google recently implemented very similar changes to its Google Groups service. Both are believed to have done so in response to Yahoo and AOL having recently both implemented strict "p=reject" DMARC policies, affecting Yahoo users' and AOL users' ability to participate in some mailing list discussion forums.


Yahoo is modifying the original from address header to make the sending email address the Yahoo Group address and moving the original from address header to an X-Original-From header.

Yahoo Groups, Google Groups, mailman, and others services and software packages have been updating their handling of from addresses recently, in response to the challenges posed by restrictive DMARC policies that prevent off-network, unauthenticated uses of certain domain names in a from address. I've updated my own mailing list manager software similarly, and I'm sure you'll be seeing more of the same from other mailing list services and software packages in the near future.

Operators of discussion mailing lists and similar services pretty much have two possible choices for how to respond to this type of issue: Modify their software to write the from address to cooperate with this policy change, or lock Yahoo and AOL users out of participating in these various services and discussion groups; this course of action that doesn't seem widely accepted or adopted. Most list managers want their subscribers to be able to continue to participate, and most commercial service providers seem to not want to deny participation to a large swath of internet users. And certainly, one concern I've hear is, what happens when the next large ISP or webmail provider implements a similar policy?

May 15, 2014 update: Yahoo explains their changes to Yahoo Groups here.

(May 13, 2014 author note: I had an unfinished, half-written blog post in my draft queue trying to answer the question "What of Yahoo Groups?" I was basically going to say that it wouldn't surprise me to see Yahoo Groups update their service similar to how Google has done. Guess there's now no need to finish that one up.)

Gmail’s message to email marketers: Focus on engagement

Campaign Monitor's Andrew Bonar reports on the takeaways from a recent presentation and Q&A session where Gmail's Sri Somanchi chatted with members of the ESPC (Email Sender and Provider Coalition).