Differences between revisions 1 and 19 (spanning 18 versions)
Revision 1 as of 2014-04-09 06:05:12
Size: 1035
Editor: msapiro
Comment:
Revision 19 as of 2019-10-16 22:04:09
Size: 4169
Editor: IanKelling
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#pragma page-filename DOC/versions/17891505
Yahoo has recently (April 2014) implemented a strict DMARC policy that will cause posts From: yahoo.com users to be bounced by many other services.
#pragma page-filename DOC/versions/17891458
Yahoo has recently (April 12, 2014) implemented a strict DMARC policy that will cause posts From: yahoo.com users to be bounced by many other services, and as of April 22, 2014 aol.com has also done this.
Line 4: Line 4:
There are a few things that con be done about this, none of which are ideal. There are a few things that can be done about this, none of which are ideal.
Line 10: Line 10:
in mm_cfg.py and then set the list's from_is_list setting to either 'Mung From' or 'Wrap Message'. Note that the 'Mung From' setting arguably creates non-RFC 822/2822/5322 compliant messages in that the From: address is now the list and not the post's author, and the 'Wrap Message' setting will create messages that some mail clients, notably Apple iOS iThing clients, but others too, will not display well. in mm_cfg.py and then set the list's from_is_list setting on the web admin General Options page to either 'Mung From' or 'Wrap Message'. Even though you will see and can set the setting in the web admin GUI, it is still necessary to restart Mailman after changing mm_cfg.py for the setting to be effective. Note that the 'Mung From' setting arguably creates non-RFC 822/2822/5322 compliant messages in that the From: address is now the list and not the post's author, and the 'Wrap Message' setting will create messages that some mail clients, notably Apple iOS iThing clients, but others too, will not display well.

The above mm_cfg.py setting goes away in Mailman 2.1.18 and the from_is_list setting is always available but deprecated. Also in 2.1.18, there is a new dmarc_moderation_action setting available under Privacy options... -> Sender filters. This can apply a selected 'Mung From', 'Wrap Message', 'Reject' or 'Discard' action only to messages From: domains that publish DMARC p=reject or p=quarantine policy. See [[../../DEV/DMARC|the DMARC page]] for more detail.
Line 14: Line 16:
2)Turn off Content filtering, and Reply-To: header munging and remove subject_prefix, msg_header and msg_footer so Mailman doesn't make message modifications that break Yahoo's DKIM signature. 2) Turn off Content filtering, scrubbing of non-digest messages and header munging (reply_goes_to_list, from_is_list, anonymous_list, first_strip_reply_to, reply_to_address, dmarc_moderation_action), and remove subject_prefix, msg_header and msg_footer so Mailman doesn't make message modifications that break Yahoo's DKIM signature. Also, apply this patch to fix Mailman breaking DKIM signatures in some cases: https://bugs.launchpad.net/mailman/+bug/1845751

Some misconfigured mail servers sign the list-* headers. This is a bad idea, but it should especially never be done when submitting to a mailing list, since its telling that mailing list that the message can't be sent from any other mailing list without breaking DKIM. You can have Exim do from munging in any case where DMARC is going to fail, see https://wiki.debian.org/Exim#For_running_a_mailing_list_and_ensuring_all_sent_mail_is_DMARC_compliant. This also allows you to leave on Content Filtering on, and munging will just happen when it kicks in.
Line 18: Line 22:
3) Turn off Bounce processing and live with the problem. 3) Set the list's anonymous_list setting to Yes. This will work for the same reason that Mung From works, but it's more drastic as it completely hides the poster's identity unless she identifies herself in the message body.

Or

4) Disallow posts From: yahoo.com addresses and tell those users they need some other (freemail provider or other) address to post. You can do this for specific known domains with header_filter_rules or, in 2.1.18, for all domains with specific DMARC policies with dmarc_moderation_action and dmarc_moderation_notice settings.

Or

5) Set

{{{VERP_PROBES = Yes}}}

in mm_cfg.py. The VERP probe will not be bounced for DMARC policy because its From: domain is the list's. If the probe doesn't bounce, the user won't be unsubscribed.

Or

6) Turn off Bounce processing and live with the problem.

Or

7) For Mailman versions without DMARC mitigation, you could set everyone to digest, make the list nondigestable = No and set digest_size_threshold to a small number > 0 such as 1 so everyone gets frequent digests. This has significant replying issues and will be unwelcome by those digest members who really want a digest and not essentially individual messages wrapped in a digest, but it may be useful as a last resort.

{{{#!wiki note
The mitigations 5) and 6) above will prevent users from having their delivery disabled and ultimately being unsubscribed by bounce processing because of their ISP's bouncing of posts from Yahoo and AOL users, but the posts will still be bounced by many ISPs and many other list members won't receive them although they will be in the archives.
}}}

Yahoo has recently (April 12, 2014) implemented a strict DMARC policy that will cause posts From: yahoo.com users to be bounced by many other services, and as of April 22, 2014 aol.com has also done this.

There are a few things that can be done about this, none of which are ideal.

1) If you have Mailman 2.1.16 or newer, set

ALLOW_FROM_IS_LIST = Yes

in mm_cfg.py and then set the list's from_is_list setting on the web admin General Options page to either 'Mung From' or 'Wrap Message'. Even though you will see and can set the setting in the web admin GUI, it is still necessary to restart Mailman after changing mm_cfg.py for the setting to be effective. Note that the 'Mung From' setting arguably creates non-RFC 822/2822/5322 compliant messages in that the From: address is now the list and not the post's author, and the 'Wrap Message' setting will create messages that some mail clients, notably Apple iOS iThing clients, but others too, will not display well.

The above mm_cfg.py setting goes away in Mailman 2.1.18 and the from_is_list setting is always available but deprecated. Also in 2.1.18, there is a new dmarc_moderation_action setting available under Privacy options... -> Sender filters. This can apply a selected 'Mung From', 'Wrap Message', 'Reject' or 'Discard' action only to messages From: domains that publish DMARC p=reject or p=quarantine policy. See the DMARC page for more detail.

Or

2) Turn off Content filtering, scrubbing of non-digest messages and header munging (reply_goes_to_list, from_is_list, anonymous_list, first_strip_reply_to, reply_to_address, dmarc_moderation_action), and remove subject_prefix, msg_header and msg_footer so Mailman doesn't make message modifications that break Yahoo's DKIM signature. Also, apply this patch to fix Mailman breaking DKIM signatures in some cases: https://bugs.launchpad.net/mailman/+bug/1845751

Some misconfigured mail servers sign the list-* headers. This is a bad idea, but it should especially never be done when submitting to a mailing list, since its telling that mailing list that the message can't be sent from any other mailing list without breaking DKIM. You can have Exim do from munging in any case where DMARC is going to fail, see https://wiki.debian.org/Exim#For_running_a_mailing_list_and_ensuring_all_sent_mail_is_DMARC_compliant. This also allows you to leave on Content Filtering on, and munging will just happen when it kicks in.

Or

3) Set the list's anonymous_list setting to Yes. This will work for the same reason that Mung From works, but it's more drastic as it completely hides the poster's identity unless she identifies herself in the message body.

Or

4) Disallow posts From: yahoo.com addresses and tell those users they need some other (freemail provider or other) address to post. You can do this for specific known domains with header_filter_rules or, in 2.1.18, for all domains with specific DMARC policies with dmarc_moderation_action and dmarc_moderation_notice settings.

Or

5) Set

VERP_PROBES = Yes

in mm_cfg.py. The VERP probe will not be bounced for DMARC policy because its From: domain is the list's. If the probe doesn't bounce, the user won't be unsubscribed.

Or

6) Turn off Bounce processing and live with the problem.

Or

7) For Mailman versions without DMARC mitigation, you could set everyone to digest, make the list nondigestable = No and set digest_size_threshold to a small number > 0 such as 1 so everyone gets frequent digests. This has significant replying issues and will be unwelcome by those digest members who really want a digest and not essentially individual messages wrapped in a digest, but it may be useful as a last resort.

The mitigations 5) and 6) above will prevent users from having their delivery disabled and ultimately being unsubscribed by bounce processing because of their ISP's bouncing of posts from Yahoo and AOL users, but the posts will still be bounced by many ISPs and many other list members won't receive them although they will be in the archives.

MailmanWiki: DOC/What can I do about members being unsubscribed by bounces of Yahoo user's posts for DMARC policy reasons? (last edited 2022-06-15 06:00:16 by msapiro)