cc modification due to nodup setting breaks DKIM & thus DMARC
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
GNU Mailman |
Fix Released
|
Low
|
Mark Sapiro |
Bug Description
Keeping DKIM signature intact allows passing DMARC without from munging
(I have references all about this if needed). However, mailman modifies
the cc header when a subscriber has the nodup setting and someone sends
to the list with that subscriber cced. Mailman doesn't email them and
removes them from the cc, presumably so for further replies mailman can
email them without it being a duplicate and they get all the good
mailman headers instead of a plain email from the cc. Anyways, best if
Mailman just not modify the cc if we are in the situation where it
matters for passing DMARC. The attached patch does that.
Note, I'm sending this as an employee of the Free Software Foundation
and my copyright is already going to them.
Related branches
Changed in mailman: | |
assignee: | nobody → Mark Sapiro (msapiro) |
importance: | Wishlist → Low |
milestone: | none → 2.1.30 |
status: | Triaged → Fix Committed |
Changed in mailman: | |
status: | Fix Committed → Fix Released |
I have long argued that there are two orthogonal things, currently both being managed by the single Avoid Duplicates settings. One is good, one is horrible. I would really love to have TWO separate knobs so that users can choose which of the two features they want.
1. Suppress duplicates - if a user does not want the same mail received twice through two paths, the list should not mail that user when their name is on a to or cc. This feature is good.
2. Rewrite CC - when the list suppresses sending to a given user, it rewrites mail headers to drop that user from cc, on the grounds that anyone replying to the list will still get their reply to the original author (through the list, rather than through cc). This feature is bad.
I _really_ want a way to enable JUST feature 1, and NOT feature 2, for the mailman lists I am subscribed to.
Here's several scenarios where I find feature 2 to be a misfeature, where User A is a user with the feature enabled, users B and C are list subscribers, and user D is not a list subscriber.
Scenario 1: User B writes to the list and to user A in cc (to catch user A's attention). User A gets a copy of the email where they are on CC, but user B and user C get a copy of the email where user A is not on CC. If user C replies to all, the reply will reach user A via the list, but will NOT have user A in cc, failing to catch user A's attention on the followup.
Scenario 2: User D writes to the list and to user A in cc (unaware that user A is subscribed to the list, and trying to catch user A's attention). User A gets the copy of the email where they are on cc, but user B and user C do not see that user A was in CC. Furthermore, user B replies all to the list and to user D, and now user D sees that user A was dropped from the CC. User D now wonders why user B dropped user A from the conversation.
Avoiding the munging of CC when DMARC rules are involved is nice, but does not go as far as I want, which is to have a knob for an individual user to ALWAYS avoid the munging of their own email, regardless of whether duplicate delivery is suppressed, and regardless of DMARC.