germano commented

Fedora mailing list messages often are classified as spam by GMail. As you can see from messages sources, dmarc and other checks are failing.
A good overview of the DNS configuration problems can bee seen at
https://mxtoolbox.com/emailhealth/lists.fedoraproject.org/
then mind the warning

These results are for fedoraproject.org.
Did you really mean to run lists.fedoraproject.org?
Click Here

and click the "Click Here" button to run the tests against lists.fedoraproject.org.
You will see 5 buttons (Problems, Blacklist, Mail Server, Web Server, DNS) that let you expand the various categories

Fedora mailing list messages often are classified as spam by GMail. As you can see from messages sources, dmarc and other checks are failing. A good overview of the DNS configuration problems can bee seen at https://mxtoolbox.com/emailhealth/lists.fedoraproject.org/ then mind the warning ``` These results are for fedoraproject.org. Did you really mean to run lists.fedoraproject.org? Click Here ``` and click the "Click Here" button to run the tests against lists.fedoraproject.org. You will see 5 buttons (Problems, Blacklist, Mail Server, Web Server, DNS) that let you expand the various categories

kevin commented

2025-04-11 00:26:13 +00:00

Owner

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.

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.

germano commented

2025-04-11 00:49:07 +00:00

Author

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

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

kevin commented

2025-04-11 00:55:47 +00:00

Owner

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

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 ```

phsmoura commented

2025-04-14 19:03:48 +00:00

Member

Metadata Update from @phsmoura:

Issue priority set to: Waiting on Assignee (was: Needs Review)
Issue tagged with: low-gain, low-trouble, ops

**Metadata Update from @phsmoura**: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: low-gain, low-trouble, ops

germano commented

2025-04-15 13:02:09 +00:00

Author

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

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 ```

germano commented

2025-04-16 12:58:49 +00:00

Author

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.

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

mschwarz commented

2025-04-19 17:43:41 +00:00

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;"

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;"

zlopez commented

2025-04-23 13:09:58 +00:00

Owner

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

kevin commented

2025-04-23 23:20:11 +00:00

Owner

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.

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.

germano commented

2025-04-25 13:02:45 +00:00

Author

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:

Replaces the sender address

From: Mario Rossi <mario@example.com>

becomes, for example

From: Mario Rossi via ListName <listname@lists.domain.org>

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.

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.

kevin commented

2025-04-28 18:51:15 +00:00

Owner

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.

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.

kevin commented

2025-04-30 21:43:34 +00:00

Owner

So, any change for anyone?

germano commented

2025-04-30 22:08:40 +00:00

Author

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.

I don't see much improvement. [This message](https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2XGFPFLDNPVIIVXVQG4MELWXQIXSOUUD/) 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. ```

mschwarz commented

2025-05-04 22:16:46 +00:00

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)

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)

mschwarz commented

2025-05-04 22:20:14 +00:00

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

# /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

kevin commented

2025-05-05 16:03:50 +00:00

Owner

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.

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.

mschwarz commented

2025-05-06 07:52:42 +00:00

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.

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.

kevin commented

2025-05-06 17:00:34 +00:00

Owner

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.

kevin commented

2025-05-06 17:01:42 +00:00

Owner

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

kevin commented

2025-07-21 19:45:37 +00:00

Owner

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

germano commented

2025-07-21 19:55:22 +00:00

Author

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

> 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

kevin commented

2025-07-21 23:37:52 +00:00

Owner

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

mschwarz commented

2025-07-22 09:06:04 +00:00

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

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

zlopez commented

2025-07-22 12:54:14 +00:00

Owner

@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?

mschwarz commented

2025-07-22 13:51:30 +00:00

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

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

kevin commented

2025-07-22 19:32:34 +00:00

Owner

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.

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

germano commented

2025-08-13 13:39:13 +00:00

Author

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 :|

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 :|

kevin commented

2025-08-28 00:04:46 +00:00

Owner

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.

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.

kevin commented

2025-09-09 23:50:58 +00:00

Owner

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

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.

zlopez commented

2025-09-10 07:53:45 +00:00

Owner

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

kevin commented

2025-09-11 00:37:47 +00:00

Owner

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. ;(

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. ;(

decathorpe commented

2026-01-15 20:47:40 +00:00

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.

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

salimma commented

2026-01-16 17:10:34 +00:00

Do you know which version of postorius we need?

kevin commented

2026-01-16 17:45:54 +00:00

Owner

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?

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?

richardm referenced this issue from quality/tickets

2026-03-22 05:36:33 +00:00

Forward test-announce emails to test list as well? #715

zlopez commented

2026-06-11 15:50:30 +00:00

Owner

This is waiting for postorius new release or need somebody to backport the patch directly.

zlopez commented

2026-07-09 12:40:47 +00:00

Owner

@salimma Did you have time to build the new version for EPEL9? I see that there is still postorius-1.3.8-9.el9.noarch on mailman01 machine.

@salimma Did you have time to build the new version for EPEL9? I see that there is still `postorius-1.3.8-9.el9.noarch` on mailman01 machine.

kevin commented

2026-07-22 00:24:18 +00:00

Owner

ok. Tired of this existing I carved out time to poke at it.

I was able to backport the patch to the existing postorius. It needs also the newer mailman3 which I built a while ago.
I deployed in staging and testing and it seemed to accept it ok.

So, I rolled it out to prod and set:

^.*@redhat.com

on devel, users and devel-announce.

So, please take a look at emails from redhat.com addresses after this update to see if it's doing the right thing.

ok. Tired of this existing I carved out time to poke at it. I was able to backport the patch to the existing postorius. It needs also the newer mailman3 which I built a while ago. I deployed in staging and testing and it seemed to accept it ok. So, I rolled it out to prod and set: ^.*@redhat\.com on devel, users and devel-announce. So, please take a look at emails from redhat.com addresses after this update to see if it's doing the right thing.

❤️ 1

kevin added

and removed

labels

2026-07-22 00:24:30 +00:00

kevin self-assigned this

2026-07-22 00:24:49 +00:00

kevin added this to the Sprint ( 2026-07-13 to 2026-07-26) project

2026-07-23 00:51:30 +00:00

kevin commented

2026-07-23 00:51:35 +00:00

Owner

ok, I see this doing the correct thing (always using mitigations for redhat.com addresses).

I think this is solved. Please re-open if you still see an issue...

ok, I see this doing the correct thing (always using mitigations for redhat.com addresses). I think this is solved. Please re-open if you still see an issue...

kevin closed this issue

2026-07-23 00:51:35 +00:00

catanzaro commented

2026-08-01 13:04:13 +00:00

After your comment on July 22, I deleted my custom Sieve rule that I had been using to prevent all devel@ mail from going to spam. Everything was fine until yesterday, when 3 mails landed in my Spam folder again. I'm using Fastmail.

I've attached one of the three affected mails, "Fedora 45 Rawhide 20260731.n.0 nightly compose nominated for testing," but here are some interesting headers:

X-Spam-known-sender: no
X-Spam-sender-reputation: 1000 (email)
X-Spam-score: 8.8
X-Spam-hits: DCC_CHECK 1.1, MAILING_LIST_MULTI -1, ME_SC_NH -0.001,
  ME_SENDERREP_ALLOW -4, ME_VADESPAM_MED_NB 4.5, RCVD_IN_DNSWL_LOW -0.7,
  SH_HBL_EMAILS 8, SPF_HELO_PASS -0.001, SPF_SOFTFAIL 0.972, LANGUAGES en,
  BAYES_USED none, SA_VERSION 4.0.1
X-Spam-source: IP='44.216.4.43', Host='smtp.gnome.org', Country='US', FromHeader='org',
  MailFrom='org'
X-Spam-charsets: plain='utf-8'

Looks like ME_VADESPAM_MED_NB and SH_HBL_EMAILS are the problem, but these seem to be custom to Fastmail and I have no clue what they might mean.

It's probably not related to the DNS issue?

After your comment on July 22, I deleted my custom Sieve rule that I had been using to prevent all devel@ mail from going to spam. Everything was fine until yesterday, when 3 mails landed in my Spam folder again. I'm using Fastmail. I've attached one of the three affected mails, "Fedora 45 Rawhide 20260731.n.0 nightly compose nominated for testing," but here are some interesting headers: ``` X-Spam-known-sender: no X-Spam-sender-reputation: 1000 (email) X-Spam-score: 8.8 X-Spam-hits: DCC_CHECK 1.1, MAILING_LIST_MULTI -1, ME_SC_NH -0.001, ME_SENDERREP_ALLOW -4, ME_VADESPAM_MED_NB 4.5, RCVD_IN_DNSWL_LOW -0.7, SH_HBL_EMAILS 8, SPF_HELO_PASS -0.001, SPF_SOFTFAIL 0.972, LANGUAGES en, BAYES_USED none, SA_VERSION 4.0.1 X-Spam-source: IP='44.216.4.43', Host='smtp.gnome.org', Country='US', FromHeader='org', MailFrom='org' X-Spam-charsets: plain='utf-8' ``` Looks like `ME_VADESPAM_MED_NB` and `SH_HBL_EMAILS` are the problem, but these seem to be custom to Fastmail and I have no clue what they might mean. It's probably not related to the DNS issue?

geary-message-9P6BT3.txt

15 KiB

mschwarz commented

2026-08-01 13:24:30 +00:00

SP_HBL => "SpamHaus HashBlockList" checks with hashes for known spam content i.e. crypto wallet ids etc. Due to the nature of a hash, you will habe collisions, if the hash algo is producing too small hashes.

No idea it's a good idea to use such a blocklist.

SP_HBL => "SpamHaus HashBlockList" checks with hashes for known spam content i.e. crypto wallet ids etc. Due to the nature of a hash, you will habe collisions, if the hash algo is producing too small hashes. No idea it's a good idea to use such a blocklist.

catanzaro referenced this issue

2026-08-03 16:45:39 +00:00

Fedora mailing list mails are still classified as spam #13489

catanzaro commented

2026-08-03 16:46:09 +00:00

Aha, so I see this is being set by SpamAssassin (on the Fastmail server). Interesting.

I've created #13489 to follow up, since this is a separate issue. It seems every mail from Fedora devel@ list matches the SpamHaus blocklist.

Aha, so I see this is being set by SpamAssassin (on the Fastmail server). Interesting. I've created #13489 to follow up, since this is a separate issue. It seems _every_ mail from Fedora devel@ list matches the SpamHaus blocklist.

Rows
Columns

fix DNS configuration of lists.fedoraproject.org to stop email messages being classified as spam #12487

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

Why it’s done

How to configure it in Mailman

Advantages

Drawbacks

In a nutshell

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

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