All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Andrew Baumann <Andrew.Baumann@microsoft.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@redhat.com>
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	[thread overview]
Message-ID: <20170329161852-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <862ea872-423a-8394-3ed5-250b0a3d2ba2@redhat.com>

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

  parent reply	other threads:[~2017-03-29 13:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-28 17:35 [Qemu-devel] qemu-devel mailing list vs DMARC and microsoft.com's p=reject policy Peter Maydell
2017-03-28 17:53 ` Andrew Baumann
2017-03-28 17:58   ` Peter Maydell
2017-03-28 18:38   ` Eric Blake
2017-03-28 18:28 ` Michael S. Tsirkin
2017-03-28 18:41   ` Eric Blake
2017-03-29  6:46   ` Markus Armbruster
2017-03-29 10:44     ` Thomas Huth
2017-03-29 11:18       ` Markus Armbruster
2017-03-29 13:47       ` Michael S. Tsirkin [this message]
2017-03-29 10:34 ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170329161852-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=Andrew.Baumann@microsoft.com \
    --cc=armbru@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.