- Policy Change
- The Problem Leading to the Policy Change
- LinuxChix's Chosen Solution
- Differences a Member Will See
- A Note of Thanks
- Member DMARC FAQ
- How many LinuxChix members does DMARC affect?
- Which LinuxChix lists does DMARC affect?
- Which domains publish a DMARC record?
- Is my domain's mail server DMARC compliant? Did it reject list mail? Will it reject list mail after the changes?
- I have a Gmail address. Was I affected? How about with the new list settings?
- I have a Yahoo address. Was I affected? How about with the new list settings?
- I don't have a Yahoo or Gmail address. Was I affected? How about with the new list settings?
- My address ends in aol.com or compuserve.com. Anything special I should know?
- Will messages I send be affected by the changes?
- Will messages I receive be affected by the changes?
- Will this affect my mail filters for the lists?
- My domain's DMARC record contains "p=reject" or "p=quarantine". What can I do to make sure I can send and receive list mail?
- Help! I use Mutt. What do I need to change in .muttrc?
- I still need help. What do I do?
In order to ensure deliverability of list mail to its members, LinuxChix will institute a change to its mailing lists. This change is necessary because RFC 7489 "Domain-based Message Authentication, Reporting, and Conformance (DMARC)" breaks mailing lists, resulting in non-delivery or quarantine of legitimate mail and wholesale bounce processing for affected list members. This change impacts LinuxChix's Reply-To Policy, which has been amended accordingly.
Many Mailman lists (including LinuxChix's lists) send out mail using the member's address in the RFC5322.From field. If the organizational domain in the RFC5322.From field has set a DMARC policy of "reject", the message will be rejected by any DMARC compliant mail server because the message will fail both SPF and DKIM.
Yahoo.com published a DMARC TXT record in DNS with a policy of "reject" (p=reject).
$ dig TXT _dmarc.yahoo.com br> ...
;; ANSWER SECTION:
_dmarc.yahoo.com. 1800 IN TXT "v=DMARC1\; p=reject\; sp=none\; pct=100\; rua=mailto:firstname.lastname@example.org, mailto:email@example.com\;"
Jane Doe, a member of techtalk, has a Yahoo address and sends a message to techtalk. Mailman processes the message and sends it to all list members with the RFC5322.From field set to Jane's address ending in yahoo.com.
Here's what happens:
Jane → techtalk → member with DMARC compliant mail server = bounce
Jane → techtalk → member with non-DMARC compliant mail server = received
Mailman increments the bounce score for each member whose mail server has bounced the message. If Jane sends messages to techtalk on successive days, a member's bounce score may reach the threshold for disabling the member's account. Unless the member takes action, the member will eventually be unsubscribed.
If the DMARC policy is "quarantine", then the message will be quarantined. What action constitutes a "quarantine" is defined in Section 6.3 of the DMARC RFC: "Depending on the capabilities of the Mail Receiver, this can mean 'place into spam folder', 'scrutinize with additional intensity', and/or 'flag as suspicious'." Practically, this means that at least some LinuxChix list mail is not being delivered. It also raises the potential for LinuxChix's mail server to be blacklisted.
LinuxChix system administrators became aware of the issue when someone with a Yahoo address posted several days in a row to one of our lists. Good for them for being active on the lists! However, the result was the disabling of almost half of the list members' subscriptions due to DMARC compliant mail servers bouncing the mail. We have taken steps to mitigate the problem but now must put in place a more permanent solution.
How happy are we about this? Not very, for all the reasons others have so eloquently stated elsewhere in the rather heated debates around DMARC. But we're stuck. Either we comply with DMARC, break some RFCs and our members' messages get delivered or we don't and severely impact the usability of our lists.
dmarc_moderation_action with the
Munge From option - selective rewriting of the From: and Reply-To: headers for domains with DMARC policies of "reject" or "quarantine". This decision was made after considering and testing the options.
This option ensures that mail from LinuxChix lists are DMARC compliant where necessary, breaks some RFCs as little as possible and has the least impact on a member's user experience. For full details of the testing, please see the techtalk archives which contain reports from the various testers as well as an in-depth discussion of the problem. Look for munging, wrapping or bouncing in the subject.
A note about the other options: We really didn't want to continue as we were (accept option), or reject or discard members' posts if they used an address with a domain that had a DMARC policy of "reject". Wrapping the message as a message/rfc822 sub-part in a MIME format outer message caused many problems. It was annoying when trying to follow a conversation. Replies broke threading. Replying included the headers in the message, exposing the original poster's email address - not an acceptable result given that some lists are publicly archived. MUAs widely differed in their ability to handle the message/rfc822 sub-part.
If a sender's domain is not a domain with a DMARC policy of "reject" or "quarantine", list mail is not altered so there should be no change in how your MUA behaves now. Viewing, message list display, threading and replying are not affected.
If a sender's domain is a domain with a DMARC policy of "reject" or "quarantine", mail from that sender will be altered. For example, a message to techtalk from Jane's Yahoo address would be rewritten as follows:
From: Jane via Techtalk <techtalk at linuxchix.org>
Reply-To: Jane Doe <Yahoo address>
If a custom Reply-To: was present, Jane's address would be appended.
Reply-To: Jane <someotheraddress>, Jane Doe <Yahoo address>
Functionally, viewing and threading should not be affected. With the exception of the custom Reply-To, MUA behavior when replying will not change for any of the MUAs tested. If you reply privately to a list message, the sender had a custom Reply-To: and the message was rewritten, your MTA will likely direct the reply to both addresses. Using the example above, a private reply would go to both of Jane's addresses. There is no option in Mailman to not append the sender's address to the Reply-To header:.
Message list display is MUA-dependent so you may need to change some settings in your MUA. Our testers found that Thunderbird, Apple Mail and iOS behaved the same with rewritten messages but Mutt required some changes to .muttrc.
LinuxChix would like to thank the system administrators, the list administrators and the people who helped out with the testing and replied countless times to "This is test message #542, let's see what this one does to your MUA."
A lot. As of August 2015, about 10% of our members have addresses using domains with a DMARC policy of "reject" or "quarantine". About 65.5% of our members have addresses with domains that run DMARC compliant mail servers.
All of them. How badly a list is affected is dependent on the domain composition of the list members. If a list is primarily composed of members with Yahoo and Gmail addresses, then chances are the vast majority of list members will be affected.
Major mail providers with a DMARC policy of "reject" include Yahoo and AOL. Gmail publishes a DMARC record with a policy of "none". To check if your domain has a DMARC record and what the policy is, fire up a shell and enter:
dig TXT _dmarc.YOUR.DOMAIN
If a record is found, the policy will be indicated by "p=". If the policy is "p=reject" or "p=quarantine", then you're affected. If you've been wondering where your list mail is, you've found the answer.
Alternatively, you can use one of the web-based tools listed under "Deployment and Validation" at
Is my domain's mail server DMARC compliant? Did it reject list mail? Will it reject list mail after the changes?
Unfortunately, there's no easy way to tell if your domain's mail server is DMARC compliant (unless you run the server). A domain can run a DMARC compliant mail server and not have a DMARC record. These are two separate things.
Major mail providers with DMARC compliant mail servers include Gmail, Yahoo and AOL. We received bounces from all three. Many large mail providers will publish information about DMARC compliance on their web sites. So your best bet is to check with your mail provider.
With the changes to our mailing lists, a DMARC compliant server should not bounce any more mail from LinuxChix's lists. However, given our experience with AOL/Compuserve, we can't guarantee that. Our system administrators and list administrators will be keeping a close watch on the effect of our changes. If we experience any issues related to particular domains, we'll let affected members know as soon as possible.
As a sender, no, you weren't affected nor will you be with the new list settings. Gmail has a DMARC record but the policy is "none" so no DMARC compliant mail server should reject list mail coming from a Gmail address and Mailman will not rewrite.
As a recipient, it depends. With the old list settings, if mail was sent by a member with a domain that has a DMARC policy of "reject", then mail to you bounced and your bounce score was incremented.
With the new list settings, messages from you will not be rewritten. Messages from the list should no longer bounce.
Yes, you were affected as a sender and recipient. With the new list settings, messages from you will be rewritten and messages to you should no longer bounce.
It depends. If your address domain has DMARC compliant mail servers and/or has a DMARC record of "reject" or "quarantine", then you were affected. Witht the new list settings, any issues should be resolved.
Unfortunately, yes. AOL bought Compuserve a while ago. Compuserve used two domains for email - compuserve.com and cs.com. AOL published a DMARC record for cs.com with a policy of "reject" but did not see fit to publish a DMARC record for compuserve.com. The bottom line is that a post from a compuserve.com domain will not be rewritten by Mailman because no DMARC record exists to trigger a rewrite but AOL will reject it based on an SPF-like check. LinuxChix can't fix this. AOL must. You might want to consider changing your list subscription address to a non-AOL or non-Compuserve address. Addresses using cs.com are not affected.
Only if you send mail from an address with a domain whose DMARC policy is "reject' or "quarantine". With the new settings:
Mail address domain → p=reject → From: and Reply-To headers rewritten
Mail address domain → p=quarantine → From: and Reply-To headers rewritten
Mail address domain → p=none or no DMARC record → No change
Only some messages will be affected. Messages sent by members from a domain whose DMARC policy is "reject" or "quarantine" will now have a From: header with "Sender via Listname <LISTNAME at linuxchix.org> and a Reply-To: header with the sender's address appended.
None of our testers found that the changes affected the way they currently filter list mail. YMMV.
My domain's DMARC record contains "p=reject" or "p=quarantine". What can I do to make sure I can send and receive list mail?
The changes should resolve any DMARC compliance issues for LinuxChix list mail. If you're subscribed to the LinuxChix lists with an address whose domain has a DMARC policy of "reject" or "quarantine" you can change your subscription address to one which doesn't have a DMARC policy of "reject" or "quarantine". While we think you should be able to participate in our lists using any address a member wants, as a practical matter, LinuxChix lists aren't your only problem if you use this address for other lists.
We don't know how domains with a "quarantine" policy handled mail before the changes. With the change, mail should be delivered to your inbox, assuming there are no other issues.
Our tester who used Mutt reported making the following changes:
- Changed index_format to use %F instead of %a, to show the sender's real name instead of email address;
- added "set reply_to=ask-no" instead of leaving it unset; and
- added "set reply_to=ask-no" in my default folder-hook.
Her comments: "With those changes, the lists actually work okay. Replying takes one more step than it did before, because I have to tell mutt whether I want to reply to the Reply-to or not; if that turns out to be annoying, I can set it to yes in my folder-hook for LinuxChix lists and go back to unsetting it for everything else."
 Using your favorite search engine, search for "DMARC breaks mailing lists" for a wealth of information. Add "Mailman" to narrow it down.
 Mailman only increments the bounce score once per day, regardless of the number of bounces.