Re: [Qemu-devel] qemu-devel mailing list vs DMARC and microsoft.com's p=reject policy

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3178 bytes --]

On Tue, Mar 28, 2017 at 06:35:55PM +0100, Peter Maydell wrote:
> Hi; it's been pointed out to me that we have a problem with qemu-devel
> unsubscribing people because of DMARC. Specifically:
>  * microsoft.com publishes a DMARC policy that has p=reject
>  * some subscribers use mail systems that honour this and send bounces
>    for non-verifying emails from those domains
>  * the mailing list software (mailman) modifies emails that pass through
>    it, among other things adding the "[qemu-devel]" subject tag, in
>    a way that means that signatures no longer verify
>  * bounces back to mailman as a result of mailing list postings from
>    microsoft.com people can then cause people to be unintentionally
>    unsubscribed
> 
> This is kind of painful. https://wiki.list.org/DEV/DMARC has the
> Mailman wiki information on the subject. In an ideal world nobody
> would use p=reject because it breaks mailing lists. In the actual
> world we have a few choices:
> 
>  (1) I could set dmarc_moderation_action=Reject
>    * this means nobody can subscribe if they've set their dmarc policy
>      to reject (the "if you don't believe in mailing lists we don't
>      believe in you" policy).
>    * there is a certain purity to this option, in that it is pushing
>      the costs of this unhelpful mail config back on the organisations
>      which have chosen it; on the other hand I'm reluctant to make
>      life harder for people who are contributing to the project
>      and who typically don't have much say over corporate email config.
>  (2) I could reconfigure mailman to try to not rewrite anything that
>      we think is likely to be signed (in particular not the body or the
>      subject)
>    * this means dropping the [qemu-devel] tag from the subject, which I'm
>      a bit reluctant to do (it seems likely at least some readers are
>      filtering on it, and personally I quite like it)
>    * if anybody DKIM-signs the Sender: header we're stuck anyway
>  (3) I could set dmarc_moderation_action to Munge From, which means that
>      those senders who have a p=reject policy will get their mails
>      rewritten to have a From="Whoever (via the list) <qemu-devel@...>"
>      and their actual email in the Reply-to:
>    * if anybody's mail client doesn't honour Reply-to: then what they
>      think is a personal reply will go to the list by accident

Option 3 sounds good given that Option 2 is unlikely to be reliable
(e.g. DKIM-signing).

>  (4) I could do nothing, and hope that we don't get so many of these
>      that they actually result in unsubscriptions
>    * in any case emails won't end up going through to some recipients,
>      so this isn't much of an option anyway
>  (5) I could set the bounce processing config to be (much) less aggressive
>    * this seems like a bad idea
>    * in any case people whose systems honour DMARC still wouldn't get
>      mails from the p=reject senders
> 
> I don't really like any of these choices.
> 
> For the moment I have picked option (3), but I'm open to argument
> that we should pick something else.
> 
> thanks
> -- PMM

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]