[Mailman-Developers] Adding DMARC support for Mailman 3

[Barry Warsaw]

On Jul 02, 2013, at 12:44 AM, Patrick Ben Koetter wrote:

>Before we take out to write code, I would like to ask mailman-developers how
>it should be done to fit best into Mailman's architecture. Here are the DMARC
>features that should go into Mailman 3:
>
>- don't allow email that comes from a domain with a DMRAC record of p=reject
>- take ownership of the email and send it with a From: using the
>  domain of the mailing list. (There's a patch for this for Mailman 2.1, which
>  might might be helpful for Mailman 3.)
>- find the authentication-results header and rewrite it as an
>  Original-Authentication-header:
>  http://tools.ietf.org/html/draft-kucherawy-original-authres-00.html

In this message, I'll talk about implementation strategies.

In very general terms, what I think you're looking at is writing an
extension/plugin that provides additional rules and handlers, and then
modifying or extending the built-in processing chains and pipelines to consult
those new rules and handlers.  In this way, DMARC support (or some subset of
it) can start out as an unofficial extension, which then based on experience
may eventually make it into the standard distribution.

I've spoken many times about the architecture for moderation (rules and
chains) and modification (pipeline of handlers), so I won't go into more
detail here.  Please start with my Pycon 2012 talk and feel free to ask any
questions you may still have.

In some sense there is overlap with how I would integrate any other anti-spam
tool in MM3.  Most of us agree that such things are better done in the MTA,
but it's just not always possible to do that.  List admins have more control
over how their lists are configured than over their MTA, so I do see value in
providing these services in MM3, as plugins.

For #1 you would have a rule that can answer the question of DMARC
disposition.  Rules output binary results, and if this rule hits, it would run
an action, probably to discard the message, although it could also hold it or
reject/bounce it.  I doubt you'd want to accept the message.  If the rule
misses then processing continues along as normal.

Munging the From header is done by a processing handler, after the message has
already been accepted for posting, and is being prepared for delivery to the
list membership.  Similarly, the Authentication-Results rewrite would be done
in the same or a different handler.  With respect to both headers, I'm
assuming that the munging is the same for every recipient; there's a different
hook point for personalization of outgoing messages.

-Barry