[Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16

[Franck Martin]

----- Original Message -----
> From: "Mark Sapiro" <mark at msapiro.net>
> To: mailman-developers at python.org
> Sent: Friday, September 13, 2013 11:31:44 AM
> Subject: Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
> 
> On 09/13/2013 08:06 AM, Barry Warsaw wrote:
> > 
> > I will leave it to Mark for final decision on this, but my own opinion is
> > that
> > the mm_cfg.py option should stay.  cPanel already customizes their Mailman
> > installation, so I think they should set it to Yes when they upgrade their
> > systems to 2.1.16.
> 
> 
> I don't feel strongly about this either way except for the general
> principle of least surprise. Enabling this by default has three
> downsides that I see. It can render a fully i18n translated General
> Options page a bit ugly with one relatively large English paragraph; it
> gives list owners yet another bullet with which to shoot themselves in
> the foot, and it complicates list configuration by adding yet another
> decision.
> 
> None of these is a deal breaker. I researched the i18n issue, and it
> turns out only 4 languages currently have a fully translated General
> Options page. One of these has already been updated and the other 3 are
> being addressed. Most languages already have between 1 and 3
> untranslated strings on this page from prior changes so it could be
> argued that one more is not important.
> 
> The other two considerations are relatively minor, but I still lean
> towards requiring overt action by the site admin to enable the feature.
> 
> I wanted this brought to mailman-developers in the hope that whatever
> discussion ensued would lead to some consensus.
> 
> I confess, I'm not at all up to speed on DMARC. Franck has assured me
> that this feature can be useful even in the absence of the DNS and MTA
> changes necessary to DKIM sign outgoing list mail, but it seems to me
> that enabling author_is_list will almost guarantee that any incoming
> DKIM signatures will be broken (the From: is almost certainly included
> in the signed headers) which will cause problems if the outgoing mail is
> not signed with a valid DKIM signature.
> 

DKIM does not require that the d= to be linked to the domains in the From: that's what DMARC do.

Mailman breaks DKIM as soon as you add a footer or tag in the subject line, which a lot of lists do (including this one). The rule with DKIM is to consider any broken DKIM signature as if there was no signature at all. So for instance this list mailman-developers will break all DKIM signatures when resending emails. Mailman could in fact strip DKIM at reception and this would be same effect.

So let me explain what author_is_list achieves.

if I post to this list using any of these domains which have a p=reject DMARC policy (linkedin.com, paypal.com, twitter.com,...). The original DKIM signature will be broken, and SPF while being valid, will not be aligned, not the same organizational domain as in the From:

Return-Path: mailman-developers-bounces+franck=peachymango.org at python.org

So DMARC will fail, creating the email to be bounced when being resent to members at gmail,yahoo,hotmail,aol,comacast,.. Note: This add to the unsubscription count for these members.

With Author is list, the From: becomes (I simplified):
From: mailman-developers at python.org

python.org does not have a DMARC policy, therefore the email will not be bounced due to DMARC for members at gmail,yahoo,hotmail,...

For a receiver, the IP is known, the headers contains the List-Id, so what is in the From has not much impact (besides the DMARC check), because it is mainly about the reputation of the sending IP that makes the email delivered to your mailbox.

> Also, it seems that an installation would want to validate in some way
> incoming mail before taking responsibility, even in a minor way, for
> resending it.

This would be appreciated, but I'm not sure why adding this extra burden on author_is_list is needed. All installations of mailman should validate somehow messages before resending them, with or without author_is_list.

> 
> All of this leads me to think that making this available to list owners
> should be an installation decision rather than being done by default.
> 
I'm not bent on if this option stays in the config file, I find already awesome that the option is present and we (the people using DMARC) have the opportunity to build adoption. Just trying to reduce adoption friction ;)