Differences between revisions 6 and 7
Revision 6 as of 2015-03-05 01:41:35
Size: 8466
Editor: JimTittsler
Comment: typo; option spelling
Revision 7 as of 2015-05-02 17:49:49
Size: 8530
Editor: msapiro
Comment: Added recommending dmarc_moderation_action over from_is_list.
Deletions are marked like this. Additions are marked like this.
Line 22: Line 22:
 * The from_is_list feature from 2.1.16 is always available.  * The from_is_list feature from 2.1.16 is always available, but it is not recommended. Use dmarc_moderation_action instead.

Mailman and DMARC

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.   Yahoo! recently 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.  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.

  • 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.

Mailman 3

This is what we propose for Mailman 3.  Any of this could change.

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.

Therefore, the site administrator will have the following options:

  • Do nothing - mailing lists will operate the way they always have.  This might be a viable option if tools upstream of the mailing list already handle DMARC.  For example, the list's MTA may employ a milter to automatically reject messages coming from Yahoo! or similar domains.

  • Reject - Mailman 3 accepts messages over its LMTP connection, in series with the SMTP dialog.  A site administrator may have a policy to simply not accept any message from Yahoo! or similar domain, and if a milter is not feasible, setting the site policy to reject would serve the same effect.

  • Force list admins to decide - This would require that the list administrator choose a mitigation technique among those options described below.  The list administrator would not be allowed to "do nothing" since that could negatively affect the reputation of the entire site.  By giving the list administrator some choice, they can select the least undesirable option.

The last two of these choices implies that the Mailman 3 system will perform a DNS check to look up the DMARC policy of the From: header's domain.  If the DMARC DNS record exists and is reject (or possibly also quarantine), then this would be recorded in the message metadata if the message is accepted and the Mailman policy is force list admins to decide.  List administrators would have the following options available to them:

  • 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 server would take ownership of the message and would inject its own address into the From: header.  This breaks reply-to-sender, although we might be able to add the original sender address in another header, or in the Reply-To header to reduce the impact of this.

  • Wrap the message - This involves MIME wrapping the original header, 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 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.

  • Don't break the signature - It may be possible to disable signature breaking features such as Subject: header munging or footer decorations that would make the mailing list a pure-forwarder.  If this is possible, then a list administrator could twiddle all the appropriate knobs so that messages would be accepted by Yahoo! or similar.  Putting those settings under the umbrella of a don't break the signatures setting would be a useful convenience.

  • 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.

Here are some open questions:

  • Should the list administrator's options be all or none?  In other words, if the message comes from a domain that does not publish a DMARC reject policy, should those messages also get the mitigation techniques applied to it?  Don't doing so limits the unfortunate effects to just those messages that need it, but would give users an inconsistent experience.  We might need to give list administrators an option to control this.
  • Should we also perform the mitigation for policies other than DMARC reject?  E.g. quarantine
  • Unfortunate side effects of From: munging include breaking Reply-To: since it will be impossible to reply to the original sender (it might still be possible with MIME unwrapping).  It will also break the ability to search for a message based on the sender.  Is there anything we can do about these?

MailmanWiki: DEV/DMARC (last edited 2019-10-01 18:13:52 by msapiro)