#11427 DMARC validation failed for mail from lists.fp-o
Opened 10 months ago by darknao. Modified 3 months ago

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).

Authentication-Results: mailin029.protonmail.ch; dmarc=fail (p=none dis=none)

Authentication-Results: mailin029.protonmail.ch; spf=pass

Authentication-Results: mailin029.protonmail.ch; arc=none smtp.remote-ip=

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).

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).

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.

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.

Since the original sender address is preserved in the Reply-To: header, this should not change anything from a user perspective.

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

10 months ago

[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

3 months ago

Metadata Update from @zlopez:
- Issue tagged with: blocked

3 months ago

Login to comment on this ticket.

Boards 1
ops Status: Backlog