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

[Markus Armbruster]

"Michael S. Tsirkin" <address@hidden> writes:

> 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
>
> For the record I'd strongly prefer this option - I tag all list mail
> and so "qemu-devel" appears twice: in subject and as a tag.
> Also, if mail is copied to another list, qemu-devel will
> still appear as gmail de-duplicates email by msg id.
> I can remove tags I don't care about but can't remove
> subject prefixes.

Seconded.  Mailing lists messing with the subject to "help" users with
filtering just complicate it.

Filtering on List-Id isn't any harder, and has the added advantage that
it actually works.

>>  (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.
>> 
>> thanks
>> -- PMM
>
> Is there a way not to munge the name? It's currently rewritten to
> add "via qemu-devel" which confuses the clients which think
> it's part of the name, and can't be easily stripped away.

Not munging the name will confuse different clients to think qemu-devel@
is an alternative e-mail for this person.

Once you start messing with e-mail headers, you inevitably get to a
place where you have to choose the functionality you're least unhappy to
break.  Which may not be the one your users are least happy to lose.

Just say no.