It's most likely not something new, but since I moved to another mail provider (namely protonmail) this is becoming more visible to me.
Mails coming from lists.fp-o are very often flagged to me as "spoofed or improperly forwarded".
Looking closely at the headers, it seems to fail on the DMARC check as the From header is being rewritten by mailman with the original sender address and does not match the return-path domain (lists.fedoraproject.org). example:
From
return-path
Authentication-Results: mailin029.protonmail.ch; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mailin029.protonmail.ch; spf=pass smtp.mailfrom=lists.fedoraproject.org Authentication-Results: mailin029.protonmail.ch; arc=none smtp.remote-ip=38.145.60.11 Authentication-Results: mailin029.protonmail.ch; dkim=none
If the sender domain doesn't have a DMARC record, that's fine, nothing happens. But if the domain does have a DMARC record, the check will fail. Best case scenario, nothing "bad" happens besides the "warning" flag (with DMARC policy set to none). Worst case, the mail is flagged as spam (p=quarantine) or even rejected (p=reject).
none
p=quarantine
p=reject
In my case, my domain is set to quarantine, and messages sent from me to the infra list end up in the user spam folder. (You should be able to confirm that if you got one of my mail to the infra list earlier this morning).
quarantine
I think this should be easily avoidable by setting the DMARC mitigations globally on mailman with the following settings: dmarc_mitigate_action to munge_from so the From header match the return-path.
dmarc_mitigate_action
munge_from
and dmarc_mitigate_unconditionally to True so not only domains with a DMARC policy of quarantine and reject get modified, to avoid the "spoofed" flag entirely.
dmarc_mitigate_unconditionally
True
reject
Since the original sender address is preserved in the Reply-To: header, this should not change anything from a user perspective.
Reply-To:
Notes from memory which are probably wrong: 1. I thought we had set this already but maybe it was a different flag? 2. There were some outstanding DMARC issues which are fixed in later mailman3 versions than what we are running. Getting mailman3 upgraded to something from this decade may fix a lot of issues.
So, our policy has been that it's a per list setting and lists that want to set it can do so.
That was established a number of years ago when it was less popular. Given that google is really forcing everyone to use it now, perhaps we should enable it globally?
People using reject with dmarc policy are... crazy, but thats their choice of course.
Happy to get more feedback on if we should enable it globally. I guess I'm ok with it now since it's really so common anymore.
Metadata Update from @phsmoura: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: medium-gain, medium-trouble, ops
[backlog refinement] With the work on mailman 3 being done, we should wait and see if the issue persists after upgrade.
Metadata Update from @zlopez: - Issue marked as depending on: #8455
Metadata Update from @zlopez: - Issue tagged with: blocked
Metadata Update from @zlopez: - Issue assigned to zlopez
Metadata Update from @zlopez: - Issue untagged with: blocked
After some digging I found this thread on list.mailman3.org where it is said, that styles could be used to set default for all the lists.
Will this work for us?
It's possible.
@arrfab also mentioned that this could be done on postfix side. I'm not sure how to implement this yet, but maybe that could be better solution for us.
After yesterday discussion we decided that best course of action is to enable it in database for all existing lists and update guide for creating new mailing lists, so we don't forgot to enable it for new lists.
I created a PR containing script that will enable DMARC mitigation for lists that don't have it set yet in database.
I tested the script out in staging already and it finished without issue.
Next step is to update the documentation for creating a new mailing list.
And here is the documentation PR
The documentation PR is merged and the DMARC mitigation script was run on production as well.
Closing this ticket as done. @darknao Feel free to reopen it if you thing we missed something.
Metadata Update from @zlopez: - Issue close_status updated to: Fixed with Explanation - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.