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
While analyzing another problem, I again found a string of these messages in the log, at the time when the monthly automatic password reminder mails were being sent:
Image: https://1drv.ms/i/c/9280aefa808b52a9/IQDouWHBxn-YRbTlWPFC6eliAXAtDq_o7ZD4f54...
This time, I managed to locate the string "root@cloud-ci.unifiedlayer.com" in /usr/local/cpanel/3rdparty/mailman/lists/mailman/config.pck.
Image: https://1drv.ms/i/c/9280aefa808b52a9/IQCDTNS6wem0R5N7qVg1OTV8AZrS90FfgZQtxyJ...
This seems to be a configuration file set up by the "mailing list administration" webpages in the administrative interface for the mailing list. Thing is, I cannot find this field anywhere on any of those pages.
I could try a meataxe approach and just patch the dratted thing, but I'd rather understand how this got there and the proper way to change it. Can anyone help?
On 4/7/26 01:21, Macs R We via Mailman-Users wrote:
While analyzing another problem, I again found a string of these messages in the log, at the time when the monthly automatic password reminder mails were being sent:
Image: https://1drv.ms/i/c/9280aefa808b52a9/IQDouWHBxn-YRbTlWPFC6eliAXAtDq_o7ZD4f54...
This time, I managed to locate the string "root@cloud-ci.unifiedlayer.com" in /usr/local/cpanel/3rdparty/mailman/lists/mailman/config.pck.
Image: https://1drv.ms/i/c/9280aefa808b52a9/IQCDTNS6wem0R5N7qVg1OTV8AZrS90FfgZQtxyJ...
This image appears to be an excerpt from the raw pickle file. Config.pck is a Python pickle and its raw content is difficult for humans to comprehend. Get a human friendly representation with
/usr/local/cpanel/3rdparty/mailman/bin/dumpdb /usr/local/cpanel/3rdparty/mailman/lists/mailman/config.pck
This seems to be a configuration file set up by the "mailing list administration" webpages in the administrative interface for the mailing list. Thing is, I cannot find this field anywhere on any of those pages.
This is the list's configuration and membership data.
I could try a meataxe approach and just patch the dratted thing, but I'd rather understand how this got there and the proper way to change it. Can anyone help?
Don't do that. You'll almost certainly break your list.
That said, password reminders are sent with envelope from the configured MAILMAN_SITE_LIST-bounces@domain address, normally mailman-bounces@domain, so that bounces of password reminders go there. Bounce processing which receive a message to that address tries to forward it to the owner(s) of the site list with envelope from the mailman-loop address. The mailman-loop address is normally configured in the MTA to deliver to a local file or a guaranteed deliverable address.
In your case you see bounces of messages from the mailman-loop address to root@cloud-ci.unifiedlayer.com. These are DSNs for password reminders that bounced, and the root@cloud-ci.unifiedlayer.com address is an owner of the site list.
The bottom line is some password reminders are bouncing and the bounce DSNs are being sent to root@cloud-ci.unifiedlayer.com and that address is undeliverable. You need to adjust the owner of the site list to be a deliverable address so you can see the bounces and see what user addresses are bouncing. Or, maybe you can find where the DSN's to mailman-loop are going and see them there.
Caveat: This reply is based on standard GNU Mailman 2.1. It probably applies to cPanel Mailman 2.2, but no guarantees.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Macs R We -
Mark Sapiro -
Stephen J. Turnbull