New strategies for mailing list DMARC

Problems often occur with mailman-style mailing lists when list participants have strong DMARC enforcement for sent and received emails. Around a year ago I was regularly participating in the Gemini mailing list and experienced this problem firsthand.

Somebody would post to the list from their own domain, with a strict p=reject policy for spoofed emails. These users often used Migadu for email hosting although this might have been coincidence.
The list would forward the same message to all subscribers, effectively spoofing the sender by including their From address but originating from an unexpected server.
I was using an iCloud email address at the time and as mainstream email providers go, they’re unusually conscientious about applying the requested DMARC policy. It would correctly refuse delivery of the apparently-spoofed message.
After several of the bounces occurred within a 24 hour period, the list would deem my account faulty and suspend delivery, even if other messages were delivering okay in the meantime.

This isn’t a new problem and there has been plenty of prior discussion. The issue hasn’t gone away, however, and the other day I was told about a new draft RFC which is pretty interesting: DMARC Compliant Mailing Lists.

The author astutely observes that since it’s the mailing list server that’s sending the email to subscribers (often with some modification), the subscriber should merely concern itself with proving the authenticity of the mailing list server. Yes, prior to that there was an email that the poster sent to the mailing list, but as a subscriber that isn’t really important to me. I can trust that the software verified the original email before resending it to me.

While this sounds elegant, the main catch is that every email transmitted by the mailing list has to originate from an address on the mailing list’s domain. That is, messages cannot appear to come directly from the original sender. The bulk of this draft RFC describes a system of long-lived aliases where senders’ real addresses are mapped to different email addresses on the mailing list domain. Then, to support the regular behaviour of replying directly to a user rather than the list, these aliases can receive mail which will then be de-aliased and forwarded to the original sender.

I think this whole concept is rather clever and I would be happy to participate in a mailing list that followed this strategy. I’m not sure that it will have widespread acceptance though. It comes with a few downsides and Serious Mailing List Users are among the most fickle people on the planet.

Private replies are forwarded via the list infrastructure, which creates an additional trust dependency. This is a particular concern if list participants want to talk privately about the entity who administers the mailing list. Even if participants took care to switch to direct private addresses, mistakes could easily be made since replying directly is such a common workflow.
Depending on the alias scheme used it may be easy-ish or impossible to work out the sender’s real email address from the alias used, unless they specify it directly in their email signature. This could also be considered a feature!
You can only email someone directly at the shown alias address if you are also a subscriber to the list. This will be confusing or hostile to people who are reading a public record of a mailing list but not subscribed themselves.

For many situations, perhaps that’s good enough—especially if the aliases follow a consistent and transparent pattern.