#pragma page-filename DEV/versions/17891477
= Mailman and DMARC =

[[http://www.dmarc.org/|DMARC]] is a standard developed as a technique to reduce email spam and phishing.  Unfortunately, it has negative consequences for mailing lists, essentially breaking long established mailing list norms, standards, and behaviors.  
[[http://www.ietf.org/mail-archive/web/ietf/current/msg87153.html|Yahoo!]] recently [[http://thehackernews.com/2014/04/yahoos-new-dmarc-policy-destroys-every.html|began]] publishing a DMARC policy for rejecting all messages that fail the signature tests, and every mailing list with Yahoo! members started seeing bounces from these members.  This has caused the Mailman community of members, list administrators, and developers enormous pain.

Mitigating the effects of the DMARC reject policy are difficult.  All known mitigation techniques break some user expectations and/or degrade the user experience.  Still, it's incumbent on the Mailman developers to try to reduce the pain our users feel, and to provide some options for site and list administrators who find themselves caught in the middle.   This page attempts to capture the Mailman developers' current thinking about the problem.

Solutions are difficult and complicated. The DMARC authors essentially acknowledge that adopting DMARC requires changing mailing list habits.  You cannot continue to run your mailing list the way you always have, in DMARC compatible way. An overview of all available solutions is in
[[https://wiki.list.org/x/17891458|this FAQ]].

Mailman 2.1.16 was the first version that added some workarounds for DMARC rejections, with refinements ongoing in subsequent releases.  Mailman 3 will also handle this in some way, with the plan described below. 

== Mailman 2 ==

Here's what's implemented in Mailman 2.1:

In 2.1.16 a from_is_list feature was implemented which if enabled by a site configuration option would offer a list admin the ability to either:

 * Rewrite (Munge) the From: header with the posters name 'via the list' and the list's address and merge the poster's address into Reply-To: or
 * Wrap the message as a message/rfc822 sub-part in a MIME format outer message with From: and Reply-To: as above.

Implemented now for release in 2.1.18 are the following:

 * The from_is_list feature from 2.1.16 is always available, but it is not recommended. Use dmarc_moderation_action instead.
 * There are new settings in Privacy options - Sender filters:
  * dmarc_moderation_action is a five valued setting with values
   * Accept - accept the post without rewriting From: or wrapping the message 
   * Munge From - rewrite the From: and Reply-To: as in from_is_list
   * Wrap Message - wrap the message as in from_is_list
   * Reject - reject the post
   * Discard - Discard the post
  * dmarc_moderation_notice is a custom reject message to replace the default Reject message.
 * The above options other than Accept override the from_is_list setting for messages whose original From: domain publishes a DMARC policy of p=reject or p=quarantine. A per-list option is available to limit this to just p=reject or to apply it to either p=reject or p=quarantine. If the option is Accept, the from_is_list setting applies.<<BR>>
 * There is a site option to set the default for dmarc_moderation_action and list admins may not set the action to a setting which is above the site default in the above list. E.g., if the site default is Reject, list admins can only set Reject or Discard; if the site default is Munge From, list admins can select anything but Accept.<<BR>>

== Mailman 3 ==

This is what currently exists in Mailman 3.1. There could be changes in future releases.

It is recognized that the behavior of individual lists can have an effect on the site's reputation.  For example, if a list allows signature violating messages to flow through to their membership, and one of those members is a Yahoo! subscriber, then it is possible that Yahoo! would consider the mailing list site to be a spammer and give it a black mark.  You could imagine that after enough of these, it might just start rejecting all message from the mailing list's domain.  This could affect other mailing lists, and even other users that send messages from this domain.

These considerations imply that the site administrator should have some control over what list policies are available similar in intent to the Mailman 2.1 restriction that the list's policy must be as ``strong`` or stronger than the site default, but this does not currently exist in Mailman 3.1. Site admins can set default policies for new lists, but the defaults do not restrict how they can be overridden by list policy.

List admins can chose from the following options for a list's DMARC mitigations.
 * ''Take no action'' - This applies none of the following to any messages.
 * ''Munge the '''From:''' header ''- The obvious way to avoid a DMARC rejection is to munge the '''From: '''header so it doesn't contain the domain that triggers the DMARC rejection.  Essentially, the Mailman list takes ownership of the message and injects its own address into the '''From:''' header.  This can affect reply-to-sender, although we add the original '''From:''' address in the '''Reply-To:''' header (or sometimes the '''Cc:''' header) to reduce the impact of this.
 * ''Wrap the message ''- This involves MIME wrapping the original message, keeping it intact and thus avoiding the RFC-violating behavior of munging the '''From: '''header.  The outer MIME part would have the '''From: '''header of the mailing list and the original '''From:''' address in the '''Reply-To:''' header (or sometimes the '''Cc:''' header), and may also contain the prologues and epilogues with the traditionally appended postings text.  Users of MUAs that can't unwrap this MIME decoration would suffer.
 * Bounce - An individual list administrator may opt to just not allow postings from such users onto their list.  Because this decision is made after the message is accepted into the Mailman system, it cannot be rejected (that implies an LMTP-time decision).  Bouncing the message means returning it to the original sender, with some explanatory text.
 * ''Discard'' - The list administrator may opt to just discard such messages.  It's not very user friendly to the poor poster, but it seems reasonable to give them this option.

Normally, the selected action is applied only to messages '''From:''' domains that publish a DMARC policy of 'reject' or 'quarantine', but if the action is ''Munge the '''From:''' header'' or ''Wrap the message'', the list admin can chose to apply the action to all list messages.