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: Michael S. Tsirkin
Subject: Re: [Qemu-devel] qemu-devel mailing list vs DMARC and microsoft.com's p=reject policy
Date: Wed, 29 Mar 2017 16:47:40 +0300

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



reply via email to

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