Alternative DMARC mitigation: Keep Headers

Bug #1539390 reported by Jakob Bohm
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU Mailman
Won't Fix
Wishlist
Unassigned

Bug Description

This is just a suggestion:

The current Mailman code offers two alternative DMARC mitigation values: "Munge From" and "Wrap Message".

I would suggest a 3rd and even simpler mitigation:

"Keep Headers"

This setting would have the following effects within Mailman:

* Preserve the Subject header intact, as well as all other headers listed in the DKIM-Signature header of the actual post.

* Do not remove the DKIM-Signature header, even if the Mailman option to do so is set.

* Do not add a DKIM-Signature for the mailing list, even if otherwise configured to do so.

* If there is no DKIM-Signature in the post, none of the above applies.

* When gatewaying from NNTP to SMTP and there is no DKIM-Signature header in the post, use the "Munge From" procedure because most NNTP servers and newsreaders do not add the required DKIM signatures anyway.

The expected effect on message delivery would be:

+ The posting passes DKIM validation for the signature placed there by the posters domain

+ DMARC checking recipients will therefore (according to the DMARC spec) accept the message as validly sent by the original poster and let it pass.

+ Because the number of DKIM-Signature headers is not increased from 1 to 2, there is no issue with the common case where buggy DMARC checkers use only the first or last DKIM-Signature header, even though the RFC says to check all DKIM signatures that match the From header domain and accept if at least one is good.

+ Spoofed posts via SMTP with an invalid DKIM-Signature header will be correctly rejected as spoofs by anyone checking the DKIM signatures according to DMARC or ADSP.

+ Spoofed posts via SMTP with no DKIM-Signature header will be correctly rejected as spoofs by anyone checking the DKIM signatures according to DMARC or ADSP.

Note: Older Mailman versions happen to already do this for replies (but not original posts) by accident because they lack the code to rearrange the "Re: " in the Subject header.

Tags: dmarc
Revision history for this message
Mark Sapiro (msapiro) wrote :

I think you are suggesting that the 'Keep Headers' option would apply no transformations whatsoever to the mail, i.e.no content filtering, no subject prefixing and no msg_header or msg_footer.

I don't see that not making these transformations, especially the lack of content filtering would be acceptable. Would you really want to allow me to post anything at all to a list and bypass all content-filtering just by posting from my Yahoo address?

Changed in mailman:
importance: Undecided → Wishlist
status: New → Won't Fix
Revision history for this message
Jakob Bohm (jb-debbugs) wrote :

I was not suggesting not doing policy/security filtering of posts. If such filtering changes a message, that message obviously cannot be handled in "Keep Headers" mode and needs to fall back to one of the other methods.

I was suggesting simply not doing the purely cosmetic message munging where that munging would invalidate an enforced DKIM signature (or a PGP signature if a poster uses that). In other words, no suffix prefixing, no reordering of "Re: " prefixes, no msg_header and no msg_footer. For many messages this would be enough to leave the message intact so it passes signature validation.

Revision history for this message
Mark Sapiro (msapiro) wrote :

I think many list owners and members would be disappointed to not see msg_footer in 'some' posts. In fact, in some jurisdictions lists are required to have visible unsubscribe links and msg_footer or (msg_header) is often used for that.

Further, I think most lists apply some content filtering in that many modern MUAs create multipart/alternative messages by default and Mailman by default will collapse these to just the first alternative part.

Thus, I see this feature as having very limited applicability, and I'm not interested in implementing it.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.