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

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

[Peter Maydell]

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

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

[Andrew Baumann]

> From: Peter Maydell [mailto:peter.maydell@linaro.org]
> 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) <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
>  (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

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

[Peter Maydell]

On 28 March 2017 at 18:53, Andrew Baumann <Andrew.Baumann@microsoft.com> wrote:
>> From: Peter Maydell [mailto:peter.maydell@linaro.org]
>>  (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).

Yes, you're right. It wouldn't inconvenience mere lurkers at
these domains.

thanks
-- PMM

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

[Michael S. Tsirkin]

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.

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

-- 
MST

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

[Eric Blake]

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

On 03/28/2017 12:53 PM, Andrew Baumann via Qemu-devel wrote:

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

That's my favorite of the options (and these days, reply-to works a lot
better than it used to even 10 year ago)...

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

and it appears to have worked; Andrew's mail purported to be from the
list, but had a correct 'Reply-to', and my mailer (thunderbird) appears
to do the right thing for reply-to-all.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

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

[Eric Blake]

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

On 03/28/2017 01:28 PM, Michael S. Tsirkin wrote:
>>  (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.

I'm ambivalent - I like the prefixes, but don't mind if they are not
present (it's easy enough to filter on List-Sender: when the prefix is
not reliable).  It's especially nice that the prefix lets me tell the
difference between mail sent to qemu-devel and qemu-block while still
dumping both lists into the same folder.

> 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 that I know of, but at least the munging only occurs for senders
with restrictive DMARC and not for ALL senders.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

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

[Markus Armbruster]

"Michael S. Tsirkin" <mst@redhat.com> 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) <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
>>  (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.

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

[Stefan Hajnoczi]

[-- 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 --]

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

[Thomas Huth]

On 29.03.2017 08:46, Markus Armbruster wrote:
> "Michael S. Tsirkin" <mst@redhat.com> 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.

The problem is that some mail clients are rather limited and you can
only filter via title there - so I guess some people would complain we
removed the tag from the subject.

Apart from that, I've also seen mailman messing up white spaces in the
body of e-mails, so this likely would only solve parts of this problem.

 Thomas

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

[Markus Armbruster]

Thomas Huth <thuth@redhat.com> writes:

> On 29.03.2017 08:46, Markus Armbruster wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> 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.
>
> The problem is that some mail clients are rather limited and you can
> only filter via title there - so I guess some people would complain we
> removed the tag from the subject.

Some people might have to switch to less crippled^W^Wmore capable
software.  Thank me later.

> Apart from that, I've also seen mailman messing up white spaces in the
> body of e-mails, so this likely would only solve parts of this problem.

Assuming that's still the case, and not a mailman configuration issue:
mailman bug.

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

[Michael S. Tsirkin]

On Wed, Mar 29, 2017 at 12:44:27PM +0200, Thomas Huth wrote:
> On 29.03.2017 08:46, Markus Armbruster wrote:
> > "Michael S. Tsirkin" <mst@redhat.com> 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.
> 
> The problem is that some mail clients are rather limited and you can
> only filter via title there - so I guess some people would complain we
> removed the tag from the subject.

Do you mean gmail by any chance? In gmail you can filter using list:
which isn't well known. This works even if you get same mail through
multiple paths. filtering by subject in gmail is extermely unreliable:
if you get a copy directly it discards others and so you get
an inconsistent mix of messages with and without the subject prefix.

In short I suspect filtering by subject works only half-way and
most people just don't notice.

> Apart from that, I've also seen mailman messing up white spaces in the
> body of e-mails, so this likely would only solve parts of this problem.
> 
>  Thomas