We can take a look. Thanks.

We are often on various blocklists because people subscribe, forget that they did and report the posts they get as spam. ;(

I am not sure what its meaning about 'dns record not found'... lists.fedoraproject.org definitely resolves.

But we can look into it and see what we can do.

dns record not found it means that a DNS "record A" does not exist for the subdomain, but it's not a serious problem

uh...

✗ host -t a lists.fedoraproject.org
lists.fedoraproject.org has address 140.211.169.196
lists.fedoraproject.org has address 8.43.85.67
lists.fedoraproject.org has address 34.221.3.152
lists.fedoraproject.org has address 152.19.134.198
lists.fedoraproject.org has address 152.19.134.142
lists.fedoraproject.org has address 38.145.60.21
lists.fedoraproject.org has address 67.219.144.68
lists.fedoraproject.org has address 38.145.60.20
lists.fedoraproject.org has address 8.43.85.73

Additional infos from https://www.checktls.com/TestReceiver

[...]
Cert Hostname DOES NOT VERIFY (smtp-mm-ib01.fedoraproject.org != bastion.fedoraproject.org | DNS:bastion.fedoraproject.org | DNS:smtp-mm-cc-rdu01.fedoraproject.org)
        (turning on Send SNI might fix this: Try It)
        So email is encrypted but the host is not verified
[...]
Cert Hostname DOES NOT VERIFY (smtp-mm-osuosl01.fedoraproject.org != bastion.fedoraproject.org | DNS:bastion.fedoraproject.org | DNS:smtp-mm-cc-rdu01.fedoraproject.org)
        (turning on Send SNI might fix this: Try It)
        So email is encrypted but the host is not verified

learndmarc.com output I got by passing the email headers (taken from my gmail account) corresponding to the message
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/Y3SEQTPGMJJHTLHRJV6WIS6UIR6YOFS6/

DMARC Results
--- Connection parameters ---
Source IP address: 38.145.60.11
Hostname: bastion.fedoraproject.org
Sender: users-bounces@lists.fedoraproject.org
--- SPF ---
Domain: lists.fedoraproject.org
Identity: RFC5321.MailFrom
Auth Result: PASS
DMARC Alignment: fedoraproject.org != gmail.com
--- DKIM ---
Domain: n/a
Selector: n/a
Algorithm: n/a
Auth Result: none
DMARC Alignment: n/a
--- DMARC ---
RFC5322.From domain: gmail.com
Policy (p=): none
SPF: FAIL
DKIM: FAIL
DMARC Result: FAIL
--- Final verdict ---
The DMARC disposition is set to 'none'. This means that DMARC does not take any specific action regarding the delivery of the message. In most cases, this indicates that the message will be delivered successfully. However, it's important to remember that other mechanisms, such as a spam filter, can still reject or quarantine a message.
---------------------
Thanks for using learndmarc.com
This free service is brought to you by URIports.com - DMARC Monitoring Reinvented.

for comparison, this is the learndmarc.com output you get by passing the headers of a message from kde-devel@kde.org mailing list, which never is classified as spam by GMail

DMARC Results
--- Connection parameters ---
Source IP address: 46.43.1.242
Hostname: letterbox.kde.org
Sender: kde-devel-bounces@kde.org
--- SPF ---
Domain: kde.org
Identity: RFC5321.MailFrom
Auth Result: PASS
DMARC Alignment: PASS
--- DKIM ---
Domain: kde.org
Selector: lists
Algorithm: rsa-sha256
Auth Result: PASS
DMARC Alignment: PASS
-- DKIM ---
Domain: kde.org
Selector: users
Algorithm: rsa-sha256
Auth Result: PASS
DMARC Alignment: PASS
--- DMARC ---
Warning: No DMARC record found – this can severely impact your email deliverability and harm your domain’s reputation!
RFC5322.From domain: kde.org
Policy (p=): reject (simulated)
SPF: PASS
DKIM: PASS
DMARC Result: PASS
--- Final verdict ---
DMARC does not take any specific action regarding message delivery. Generally, this means that the message will be successfully delivered. However, it's important to note that other factors like spam filters can still reject or quarantine a message.
---------------------
Thanks for using learndmarc.com
This free service is brought to you by URIports.com - DMARC Monitoring Reinvented.

one view to the TXT record and you see the lack of a DMARC entry.

You can use this one to get rid of google:

"v=DMARC1; p=none;"

I thought that adding DMARC on mailman would be enough, but it seems that we need to add it to DNS as well.

Well, in mailman thats mitigation for the sender of the email having DMARC (to avoid the lists sending as that user from our outgoing server, which would be rejected).

This is google being... google and demanding DMARC I guess.

We do have:

host -t txt _DMARC.fedoraproject.org
_DMARC.fedoraproject.org descriptive text "v=DMARC1; p=none; rua=mailto:dmarc-admin@fedoraproject.org; ruf=mailto:dmarc-admin@fedoraproject.org; fo=0"

for the base domain.

Outgoing emails from the list go via bastion and are signed, but from bastion, which might make something cranky.

I'm fine adding the none record for lists for now.

Mailman "munging" (which is enabled on KDE lists) description from chatgpt o3
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html

What “munging” the From: header means

“Munging” (literally “to mangle or scramble”) is the act of rewriting the From: field by the mailing-list software.
When this option is enabled, Mailman takes the original message and:

1. Replaces the sender address
   From: Mario Rossi <mario@example.com>
   becomes, for example
   From: Mario Rossi via ListName <listname@lists.domain.org>

2. Moves the author’s real address into Reply-To: (or sometimes Cc:) so that replies can still reach the original poster.

The end result is that, after the list relays the mail, the domain in From: matches the domain of the server actually sending it; SPF and DKIM are therefore “aligned,” and the message passes DMARC checks.

Why it’s done

• List servers add footers, tweak the subject, and modify headers → the author’s DKIM signature no longer verifies.
• The list server’s IP is usually not in the author’s SPF record.
• If the author’s domain publishes a strict DMARC policy (p=quarantine / reject), recipients such as Gmail or Yahoo would reject or spam-folder the message.
• By rewriting From: to use the list’s domain, SPF (and DKIM, if the list signs outgoing mail) now align with that domain, so DMARC passes.

Mailman documents this as the munge_from action in its “DMARC Mitigations” guide and the official wiki describes it as “Rewrite (Munge) the From: header … to avoid DMARC rejection.”

How to configure it in Mailman

• Mailman 2.1
• from_is_list = Yes (old)
• or dmarc_moderation_action = Munge From (recommended in ≥ 2.1.18).
• Mailman 3
• dmarc_mitigate_action = munge_from
• Optionally set dmarc_mitigate_unconditionally = Yes to apply it to all messages, or leave it off to affect only those from domains with strict DMARC.

Advantages

• Excellent deliverability: messages from domains with strict DMARC don’t get rejected or spam-filtered.
• No need to block posters from “gmail.com,” “yahoo.com,” etc.

Drawbacks

• The From: header recipients see no longer shows the true author’s address; some users find this confusing.
• Tools that rely exactly on From: (e.g., git am, certain mail filters) can break.
• Strictly speaking it bends RFC 5322, which expects the real author in From: (though the practice is widely accepted).

In a nutshell

From munging simply changes the visible sender so the domain matches the mailing list’s domain, sidestepping DMARC blocks.
Mailman lets you enable it with a single setting—use it when deliverability matters more than keeping the From: header 100 % intact.

We already have dmarc mitigation enabled for all lists. We have it set to do mitigations when the sending domain has a reject or quarantine setting.
I don't think we want to enable it unconditionally.

I've added a placeholder DMARC txt record to hopefully fix things. Please test.

So, any change for anyone?

I don't see much improvement. This message sent yesterday has still been classified as spam

DMARC Results
--- Connection parameters ---
Source IP address: 38.145.60.11
Hostname: bastion.fedoraproject.org
Sender: devel-bounces@lists.fedoraproject.org
--- SPF ---
Domain: lists.fedoraproject.org
Identity: RFC5321.MailFrom
Auth Result: PASS
DMARC Alignment: fedoraproject.org != redhat.com
--- DKIM ---
Domain: n/a
Selector: n/a
Algorithm: n/a
Auth Result: none
DMARC Alignment: n/a
--- DMARC ---
RFC5322.From domain: redhat.com
Policy (p=): quarantine
SPF: FAIL
DKIM: FAIL
DMARC Result: FAIL
--- Final verdict ---
The DMARC disposition is set to 'quarantine'. The recipient treats the message with suspicion, which can lead to various actions based on the recipient's capabilities. These actions may include placing the message in the spam folder, subjecting it to heightened scrutiny, or flagging it as suspicious.
---------------------
Thanks for using learndmarc.com
This free service is brought to you by URIports.com - DMARC Monitoring Reinvented.

And noone wonders, why it complains that fedoraproject is not redhat.com?

The link to a website without headers of that email, does not help, so i searched the mail on the dev-ml.

I checked SPF for both domains, and from the fact, that redhat.com got named, i have to assume and checked with the original mail to the list, that it's the original senderdomain which has been used to send over bastion, which must fail, as bastion is not listed in redhat.com's SPF entry.

fedoraprojects and redhats dmarc entries are syntactically valid and the report names SPF as failed.

BTW: pagure.io is used as a sender domain for the FI-ML and does not have SPF at all. Maybe someone wants to fix this or gmail won't take those mails either.

Conclusion: x@redhat.com is not allowed to be send over bastion by SPF..

Solution: Introduce SRS or add bastion to redhat's SPF entry (way easier).

2.BTW: Why did DKIM failed for the reporting tool? I checked the original mail and DKIM is correct. At least that should have passed. (note: dkim is dns based and dns can fail)

/usr/bin/spfquery --scope mfrom --id x@redhat.com --ip 38.145.60.11

fail
Please see http://www.openspf.org/Why?s=mfrom;id=x%40redhat.com;ip=38.145.60.11;r=c1.resellerdesktop.de
redhat.com ... 73t7ezjz._spf._d.mim.ec: Sender is not authorized by default to use 'x@redhat.com' in 'mfrom' identity (mechanism '-all' matched)
Received-SPF: fail (redhat.com ... 73t7ezjz._spf._d.mim.ec: Sender is not authorized by default to use 'x@redhat.com' in 'mfrom' identity (mechanism '-all' matched)) receiver=xxx.resellerdesktop.de; identity=mailfrom; envelope-from="x@redhat.com"; client-ip=38.145.60.11

QED

The problem here seems to be redhat.com doesn't trigger the mailman dmarc mitigation (because dmarc policy on redhat.com doesn't require it, but then the email hits SPF issues.

There is almost no chance that redhat.com will add us as a sender in SPF records.

than there is only one solution left: SRS (Sender Rewriting Scheme)

Rewriting the sender to an allowed form with a working domain, so SPF will pass.

Right and the only way I see to do that is to enable the mailman dmarc mitigation always. I guess we can do that but it might confuse some people.

Is the devel list the only place folks are seeing this issue?

So, still seeing any issues? or can we close this now?

Is the devel list the only place folks are seeing this issue?

no. Many of them are affected, I.E. users@lists.fedoraproject.org

So, still seeing any issues? or can we close this now?

Nothing has changed, so it is definitely not fixed. I am still experiencing it everyday

ok, and you are seeing it from just @redhat.com senders? or various?

HI,

Am 22.07.25 um 01:37 schrieb Kevin Fenzi:

kevin added a new comment to an issue you are following:
``
ok, and you are seeing it from just @redhat.com senders? or various?

``

To reply, visit the link below or just reply to this email
https://pagure.io/fedora-infrastructure/issue/12487

a) FAS not working, Login not possible => Gateway Timeout

b)

Did you activate it on DEVML already because i don't see SRS there?

c) the SRS on this mail:

reply+25c163d354594b3b8b043102b4f3456a12e6b5f79a83d39533c0b6e38581536a3c9b954e70c46757cd724d5201de8a7788b9cea03f4cad96008bf4241e0e7f16@pagure.io

Is too much for TB to handle on the create message ui, the TO: ui
element got out of alignment... aka why is it thaaaaaaaaaaaat long??? :DDD

best regards,
Marius

@mschwarz I didn't heard anybody complaining that the FAS is not working, I just logged in without issue. Both with kerberos ticket and by username and password. Can you elaborate, where it's not working?

Am 22.07.25 um 14:54 schrieb Michal Konečný:

zlopez added a new comment to an issue you are following:
@mschwarz I didn't heard anybody complaining that the FAS is not working, I just logged in without issue. Both with kerberos ticket and by username and password. Can you elaborate, where it's not working?

At the time of that reply.

"now" it's working as expected.

best regards,
Marius

b)

Did you activate it on DEVML already because i don't see SRS there?

It's enabled for all lists with the setting of:
Replace From with list addess

for

"The action to apply to messages From: a domain publishing a DMARC policy of reject or quarantine"

So, I guess the issue is that at least redhat.com does set such a policy, and gmail is marking things as spam because the re-writing isn't taking place.

According to https://gitlab.com/mailman/mailman/-/issues/1084 there's also now a setting where we could set *@redhat.com to use the rewrite.
Perhaps thats worth doing?

c) the SRS on this mail:

reply+25c163d354594b3b8b043102b4f3456a12e6b5f79a83d39533c0b6e38581536a3c9b954e70c46757cd724d5201de8a7788b9cea03f4cad96008bf4241e0e7f16@pagure.io
Is too much for TB to handle on the create message ui, the TO: ui
element got out of alignment... aka why is it thaaaaaaaaaaaat long??? :DDD

This is mail direct from pagure.io, not any list.

I don't know why the reply is so long there, but it needs to be unique over all issues/tickets/projects... so it's probibly a large hash.

Proton Mail also classifies many messages as spam, for example the email I got for message,
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SWJZF2PEH6K74YZIQUMNP4JPSEULCIMW/

The header contains X-Mailman-Rule-Misses: dmarc-mitigation. So can I ask what type of mitigation have you enabled?
I would like again to stress that munge can definitely help fixing the spam problem.

P.S. (19th August)
a comment from Daniel Gruno of The Apache Software Foundation, in #mailman IRC channel

without munging, it's a crap shoot whether the email is classified as spam or not. even if it isn't, larger email providers like google and outlook (msft) are now requiring DMARC regardless of the sender's domain
the only real solution is to munge AND sign all outgoing email
if they are not ready for that yet, they are going to have to live with their emails not making it to peoples inboxes :|

So, we have "DMARC mitigation action" set to "Replace from with list address" and "DMARC Mitigate unconditionally" set to no. Which means " The action to apply to messages From: a domain publishing a DMARC policy of reject or quarantine or to all messages if DMARC Mitigate unconditionally is True."

However, redhat.com does have a policy of quarantine, so it should have mitigated it, but it didn't.
AH. It has a quarantine policy externally... but internally it does not. ;(

I'm not sure how best to work around this. We could enable "Mitigate unconditionally" but it could break filters/I would not want to do it without notice.
Or perhaps there's some way to override just this one domain.

I found https://gitlab.com/mailman/mailman/-/commit/a3374da0be6a11a3d298b41213704de17a4fcdf0 but it's in the next version up from the one we have. ;(
We need to get that updated.

I see that 3.3.9 is already packaged for rawhide, F43 and F42, so we just need to update epel9 version.

3.3.9 builds fine, I updated staging with it... but actually we need a newer postorious for this... and that doesn't build, it has some new dependencies. ;(

Also, staging mailman seems to be ooming all the time again. ;(

It looks like this is now happening more frequently? At least a handful of emails from @redhat.com addresses now land in my Spam folder every day.

Do you know which version of postorius we need?

Yeah, 1.3.9

"The Mailing list's dmarc_addresses attribute can now be viewed/set in Postorius. (Closes #585)"

https://gitlab.com/mailman/postorius/-/merge_requests/825 is the mr... perhaps it might be possible to just backport that?

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/infra/tickets/issues/12487

Please continue any further discussion there.