Peter Maydell
2017-03-28 17:35:55 UTC
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-***@...>"
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
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-***@...>"
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