[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: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] qemu-devel mailing list vs DMARC and microsoft.com's p=reject policy |
Date: |
Wed, 29 Mar 2017 13:18:56 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Thomas Huth <address@hidden> writes:
> 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.
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.