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:

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

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.