mailman-loop sending mail to undesirable address

I tried posting this twice at the website and it appears to blackholed both times, don’t know whether it’s a new-user moderating thing or what. So apologies if this is a duplicate
Hopefully, this is simple. I know nothing about the innards of Mailman -- I've been just using it as a black box for a decade and it's been working fine.
Today, in the process of handling a subscriber's non-delivery complaint, I came across this error message in WHM's Mail Delivery Reports:
From Address: mailman-loop@server.wickenburg.us Sender: Sent Time: Feb 22, 2025, 6:48:18 PM Sender Host: server.wickenburg.us Sender IP: 127.0.0.1 Authentication: unauthorized Spam Score: 0 Recipient: root@cloud-ci.unifiedlayer.com Delivered To: Delivery User: Delivery Domain: cloud-ci.unifiedlayer.com Router: reject Transport: **rejected** Out Time: Feb 22, 2025, 6:48:18 PM ID: 1tm16p-00000000BOG-aS00 Delivery Host: server.wickenburg.us Delivery IP: 127.0.0.1 Size: 0 bytes Result: The mail server could not deliver mail to root@cloud-ci.unifiedlayer.com. The account or domain may not exist, they may be blacklisted, or missing the proper dns entries.
The recipient identified is not anything I ever set up. "unifiedlayer" belongs to my hosting provider, so this may be some sort of default or unset value. I've scoured the Mailman configuration screens for anything resembling this, or any field I should have provided but left blank, and I'm buffaloed.
Where is Mailman getting this value from, and how to I change it to something more useful?

Macs R We via Mailman-Users writes:
I tried posting this twice at the website and it appears to blackholed both times, don’t know whether it’s a new-user moderating thing or what. So apologies if this is a duplicate
It's non-subscriber moderation. I don't know about recent statistics, but historically checking that the poster is a subscriber has been enough to keep out 80-90% of spam. I've registered your address as a nonmember user. You probably should claim that address using the web ui at mail.python.org/mailman3, but your future posts will go through even if you don't claim it.
Today, in the process of handling a subscriber's non-delivery complaint, I came across this error message in WHM's Mail Delivery Reports:
That's cPanel, right? We'll do what we can, but cPanel Mailman is ancient (I mean we end-of-life'd Mailman 2.1 half a decade ago), and it's heavily patched by cPanel. They or your hosting or email provider should be the first place you go, as we have very little visibility into what can go wrong with cPanel Mailman.
See https://wiki.list.org/DOC/Mailman%20and%20CPanel.
From Address: mailman-loop@server.wickenburg.us Sender: Sent Time: Feb 22, 2025, 6:48:18 PM Sender Host: server.wickenburg.us Sender IP: 127.0.0.1 Authentication: unauthorized Spam Score: 0 Recipient: root@cloud-ci.unifiedlayer.com Delivered To: Delivery User: Delivery Domain: cloud-ci.unifiedlayer.com Router: reject Transport: **rejected** Out Time: Feb 22, 2025, 6:48:18 PM ID: 1tm16p-00000000BOG-aS00 Delivery Host: server.wickenburg.us Delivery IP: 127.0.0.1 Size: 0 bytes
Result: The mail server could not deliver mail to root@cloud-ci.unifiedlayer.com. The account or domain may not exist, they may be blacklisted, or missing the proper dns entries.
This looks like somebody is spamming your mailman@YOUR.DOMAIN to me.
The recipient identified is not anything I ever set up. "unifiedlayer" belongs to my hosting provider, so this may be some sort of default or unset value. I've scoured the Mailman configuration screens for anything resembling this, or any field I should have provided but left blank, and I'm buffaloed.
Where is Mailman getting this value from, and how to I change it to something more useful?
If you mean "root@cloud-ci.unifiedlayer.com", that should be the owner address of the mailman@YOUR.DOMAIN list. How it got there, you'll have to ask whoever set up the Mailman installation. To change it, you need the password to that list or the site password (the password you need to create lists).
For more information: Somewhere there should be a source or documentation directory where you can find mailman-install.txt and probably an HTML-ized version. Search for "mailman-loop" to get to Section 6, and "site list" to get to Section 8.

I bopped around in /usr/local/cpanel/3rdparty/mailman today. I grepped for the string "unifiedlayer" and found it in only one file -- an archived or template (not live) copy of the mail archives HTML page header. I verified that the live page had the proper contents in it. I gave up the hunt as nonproductive.
I found the logs in that hierarchy also, including the smtp-errors log, which indicated continual DKIM errors to gmail and some other sites; I believe I have solved the nondelivery problem by increasing the munging isolation factor from "rewrite header" to "enclose in wrapper."
Thanks for your help in identifying those two wiki pages. I'm sure I will have occasion to refer to them in the future

Macs R We via Mailman-Users writes:
I believe I have solved the nondelivery problem by increasing the munging isolation factor from "rewrite header" to "enclose in wrapper."
I'm glad you're using the wrapper option: I conceived and implemented that myself. As long as your DKIM settings are consistent across DNS and your MTA, you should get the best possible deliverability.
However, the reason it's not the developers' recommendation is that Apple Mail in particular had issues reading encapsulated messages. That was 10 years ago, so perhaps they've improved compatibility since then. But you should watch for reports from users.
Regards, Steve
participants (2)
-
Macs R We
-
Stephen J. Turnbull