[Bug 1539384] [NEW] Non-blocking DMARC mitigations should also be done for p=none

Jakob Bohm jb-debbugs at wisemo.net
Thu Jan 28 23:01:00 EST 2016


Public bug reported:

If you read the DMARC informational RFC (no longer just a draft), you
will see that there are 3 possible policies a mail domain (of a poster)
can set

p=reject  All recipients should reject/drop mails with From: ...<at
ourdomain> that have neither DKIM not SPF pass for our ourdomain.  Send
automatic reports of this to our postmaster at the specified rua
address.

p=quarantine  All recipient spam filters should penalize ditto.  Send
the same automatic reports.

p=none  Recipients should act as if this policy was not there, but send
the automatic reports so we can decide if our policy needs fine tuning
before switching to a tougher p value.

Currently Mailman 2.1.20+ has code that applies reasonable adjustments
to avoid failures with posters from p=reject domains (such as Yahoo).
Mailman 2.1.20+ also has an option to do the same for p=quarantine.

But when a domain is set to p=none because the postmaster is trying to
figure out what will break if he/she/they turn on quarantine, Mailman
will continue sending mail in a way which causes all the backscatter
reports from everybody except the list owner.

As a postmaster I find this very annoying as it makes it hard to find
actual problems in the flurry of backscatter noise from making even a
few posts to a single Mailman list.  Especially annoying is reports that
some servers received mails with failed DKIM from a 4th party IP, as it
is impossible to tell if those 4th parties were forwarding mails that
were broken by Mailman munging the Subject header or were handling mails
of some other kind needing a different correction.

I would therefore suggest the following change to the 2.1 branch (since
3.x is still not in a usable state):

* If dmarc_moderation_action is set to a value other than Reject or
Discard, the specified mitigation should be applied to domains with any
valid DMARC policy, not just reject.

The effect of this would be:

+ List admins need to do nothing extra, since this works with the
existing Mailman settings.

+ Domains that use p=none with a user posting to a list with action
other than Reject/Discard will see the true effects that setting
p=reject would have, and their users will see any change in the Mailing
list behavior and be able to complain to the local postmaster before the
domain goes to p=reject.  Which is exactly the intended purpose of
p=none.

+ Domains that use p=none with a user posting to a list with action set
to Reject/Discard will receive a flurry of error reports reflecting how
badly things will break if they go to p=reject, but the users will not
loose their ability to post (because the reject/discard action is not
applied to domains with p=none).  Again this is consistent with the
intended purpose of p=none.

+ Domains that use p=quarantine with a user posting to a list that has
not set dmarc_quarantine_moderation_action will see the same effects as
domains that use p=none (see above).

+ Domains that use p=quarantine with a user posting to a list that has
set dmarc_quarantine_moderation_action will see the  same behavior as
for the current 2.1.20 code.

+ Domains that use p=reject will see the same behavior as for the
current 2.1.20 code.

** Affects: mailman
     Importance: Undecided
         Status: New


** Tags: dmarc

-- 
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1539384

Title:
  Non-blocking DMARC mitigations should also be done for p=none

To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1539384/+subscriptions


More information about the Mailman-coders mailing list