qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrew Baumann
Subject: Re: [Qemu-devel] qemu-devel mailing list vs DMARC and microsoft.com's p=reject policy
Date: Tue, 28 Mar 2017 17:53:57 +0000

> From: Peter Maydell [mailto:address@hidden
> Sent: Tuesday, 28 March 2017 10:36
> 
> 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

Ugh. I agree, this is painful. Sorry :(

>  (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).

Clarification: if I've understood correctly, this means nobody can *post*, 
right? The problem arises when I post to the list, not when I subscribed (and 
qemu-devel doesn't require subscription to post).

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

That would be an uphill battle, I'm sure... in practice, it's more likely to 
simply discourage contributions from folks like me.

>  (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) <address@hidden>"
>      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
>  (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.

Option 3 is a fine one from my perspective (I could also live with 2). This 
email will hopefully help you test whether it's effective.

Andrew

reply via email to

[Prev in Thread] Current Thread [Next in Thread]