I recently noticed that I get messages from gentoo-user+owner@g.o with: Subject: Bouncing messages from gentoo-user@lists.gentoo.org "Some messages to you could not be delivered. If you're seeing this message it means things are back to normal, and it's merely for your information. Here is the list of the bounced messages: - 182775 " Additional messages: - 182748 - 182749 - 182751 - 182681 I'm not the only one, there are few users with gmail address as well, and some with different mail addreses. Also there is a thread about this on gentoo-user ml[1]. I'm subscribed to gentoo ml's for some time, never had these issues before. I know this could be my email provider related issue, I did check that there are some restrictions in amount of emails sent/received during a period of time, little bit unclear, is it for free account or not, but I receive very few emails during the day, so I doubt I can hit any limit. But could be other side, that it blocks lists.gentoo.org for sending too many emails in short period of time. [1] https://archives.gentoo.org/gentoo-user/message/794191dd8bf8f293f9120d31dd72e79e Reproducible: Sometimes
I don't see anything obviously wrong with those messages but they all came from the same sender. It's possible that his mails are somehow off and trigger some problems in GMail.
Ok, found a current bounce referencing the sender: 41 <xxxxxxx>: host gmail-smtp-in.l.google.com[74.125.124.26] said: 42 550-5.7.1 Unauthenticated email from tnetconsulting.net is not accepted due 43 to 550-5.7.1 domain's DMARC policy. Please contact the administrator of 44 550-5.7.1 tnetconsulting.net domain if this was a legitimate mail. Please 45 visit 550-5.7.1 https://support.google.com/mail/answer/2451690 to learn 46 about the 550 5.7.1 DMARC initiative. m203si838522itd.103 - gsmtp (in reply 47 to end of DATA command) I'll contact him.
I strongly believe the problem is that the gentoo-users@ mailing list is sending message in a way that is not compliant with DMARC. So any messages originating from a sender with an email address in a domain that is using DMARC (or SPF, more on that later) will extremely likely fail. IMHO the gentoo-users@ (and all) mailing lists need to send emails out in a DMARC (and SPF) complaint manner. The messages to subscribers are being rightfully rejected because the message coming from the gentoo-users@ mailing list is NOT from the original sender. Thus it is failing security measures that the original sending domain has in place. Hence why the receiving servers reject the message. SPF: I replied to Michał (CCing infrastructure@) and received a bounce (DSN) from smtp.gentoo.org (Reporting-MTA) because the message was apparently forwarded to (I'm speculating) Michał using the original SMTP envelope from. There by sending in a non SPF compliant manner. See the following link for more details. http://www.openspf.org/Why?s=mfrom;id=REDACTED@tnetconsulting.net;ip=2001:470:ea4a:1:5054:ff:fec7:86e4;r=
Please note: More and more institutions are adopting DMARC, and some governments (Germany and US come to mind) are starting to mandate DMARC for government agencies and sub-contractors.
Thanks for your explanation, Grant. In that case, I think this may be solved when we finally switch the mailing lists to mailman.
Grant/mgorny: The envelope-sender/return-path on the mail server messages should be VERP-encoded with an ID that uniquely identifies the mail and the recipient. MAIL FROM:<gentoo-dev+bounces-${ID}-$RECIP=$DOMAIN.$TLD@lists.gentoo.org> SPF should be verifying this address, and not the From: header in the email. DMARC on the other hand verifies the From header in the email, and not the envelope sender. Mailing alias/.forward files that don't rewrite the envelope-sender will break strict SPF AND DMARC. Mailing lists that rewrite the envelope-sender break DMARC but not SPF. Updating the mailing lists will solve DMARC, but I don't have a solution that magically fixes .forward files and regular mail aliases.
Robin, I was seeing the VERP address in my MTA logs like you are indicating. I also believe that SPF was happy with the MAIL FROM:<VERP> address. I believe that DMARC is the crux of the issue that prompted the creation of this bug. I have configured my MTA to support Sender Rewriting Scheme (SRS) to address .forward type issues. - Some people really dislike SRS, others (like myself) are okay with it. IMHO it is a necessary evil to get around SPF for forwarded email. I think I saw reference to migrating mailing lists to Mailman, so I'll mention this: There are three settings that I'm aware of that need to be set to make sure that messages from Mailman don't suffer from these same types of problems. I don't remember the exact settings, but I'm happy to dig them out of my archives if anyone is interested. Finally, since this (DMARC) is a known problem and has a planed mitigation, I'll deviate from my default email work flow to avoid triggering it and inadvertently negatively impacting other list subscribers by causing excessive bounces. (My default email work flow is to personally send email from <user>@<domain>.<tld>, which has full security enabled. - I can manually send each message from an alternate address that does not have the same level of security enabled.) Finally, I'm happy to discuss anything in further detail if anyone has any questions or would like to enlighten me to better methods.
I set up mailman3 and tested mail from my home server (which has dmarc enabled and strict). The settings are... 1. do nothing 2. rewrite the from to be the list address 3. wrap the message in an outer message from the server 3. reject the message 4. discard The only setting that 'fixes' it is to rewrite the from header. Personally I'm fine with it. If you send a message to a list, expect it to munge it (imo). From isn't in the signed part of the message when signing it. Wrapping the message since the original message shows up as an attachment.
What do you mean by "From isn't in the signed part of the message when signing it."? The From: header is one of the recommended headers in to be protected by DKIM.
(In reply to Matthew Thode ( prometheanfire ) from comment #8) > The only setting that 'fixes' it is to rewrite the from header. Personally > I'm fine with it. If you send a message to a list, expect it to munge it > (imo). From isn't in the signed part of the message when signing it. Does the rewritten header forward mail back to the original sender?
Munge the From: header - The obvious way to avoid a DMARC rejection is to munge the From: header so it doesn't contain the domain that triggers the DMARC rejection. Essentially, the Mailman list takes ownership of the message and injects its own address into the From: header. This can affect reply-to-sender, although we add the original From: address in the Reply-To: header (or sometimes the Cc: header) to reduce the impact of this. taken from https://wiki.list.org/DEV/DMARC
(In reply to Michał Górny from comment #10) > Does the rewritten header forward mail back to the original sender? No, and maybe. Proper MTAs will send bounces back to the SMTP from address. Programs that don't have knowledge of the SMTP from address will likely send replies (fake bounces) back to the From: header. With From: munging, that is likely a list address and not the original message author. The answer to your question really depends on the context and what has happened up to that point. The best generality that I can give you is that the replies (like above) will likely not go back to the original author when From: munging is used.
