Moderator e-mails only going out once a day
Hi, I have just got done migrating from MM2 to MM3 and the users are experiencing issues with their moderated messages. After the message is sent, the moderator does not know about the message until the next day. I checked the maillogs and all those messages are being sent at the same time around midnight. I also noticed the messages are being sent from user@example.com, which I switched in /etc/mailman3/mailman.cfg to a generic e-mail address.
Is there a way to change those moderator e-mails to send right away? Does having user@example.com in the config affect that?
Thank you in advance, Joe
On March 25, 2025 2:57:25 AM GMT+07:00, jkoral@luc.edu wrote:
Is there a way to change those moderator e-mails to send right away? Does having user@example.com in the config affect that?
In each list's settings under Automatic responses, set Admin immed notify to Yes.
-- Mark Sapiro <mark@msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.
Mark, thank you for your reply. I did not mention it, but that is already set and we are still having an issue. Is there anything in the setting I can check? Also, I changed the name of the e-mail in the settings and restarted the mailman3 service. Does anything else need to be restarted?
A little more information. When I setup my list to be moderated and I send a message, I never get the moderator message, so I have to manually check for messages being held. Once I accept that message, I get the message. But I never get the message as a moderator that I have items waiting to be released.
Mark, just a little more information that might be helpful. I still have the old Mailman2 server up and running and that is what is forwarding the e-mails to the new Mailman3 server. All of the forwarding addresses are setup in /etc/aliases.
Who should the moderator e-mail come from when the moderator has to approve something? I have been searching the logs and cannot find that an e-mail for that exists.
OK, another thought. Could it be because of the way my cronjob is setup??? Here is what I have.
@daily /opt/mailman/venv/bin/mailman digests --periodic @daily /opt/mailman/venv/bin/mailman notify
0,15,30,45 * * * * /opt/mailman/venv/bin/mailman-web runjobs quarter_hourly @hourly /opt/mailman/venv/bin/mailman-web runjobs hourly @daily /opt/mailman/venv/bin/mailman-web runjobs daily @weekly /opt/mailman/venv/bin/mailman-web runjobs weekly @monthly /opt/mailman/venv/bin/mailman-web runjobs monthly @yearly /opt/mailman/venv/bin/mailman-web runjobs yearly/opt/mailman/venv/bin/mailman-web runjobs minutely
After running mailman notify manually, I received the moderator e-mail. But of course running that every minute would produce the same e-mails every minute.
Joe,
It may help to have more information about what your system is like. Specifically:
- Did you install Mailman from our source distribution, from PyPI, or from some other source?
- Did you install Mailman in its own virtual environment?
- When you run 'mailman info', does the output make sense? Especially, is the configuration file (mailman.cfg) in the directory (usually /etc/mailman3) you expect?
- How do you control the Mailman processes? Using systemd's systemctl utility, SysV init scripts, or the 'mailman' and 'mailman-web' utilities? If you are not using the systemd or init utilities, what is the current directory when you start or restart Mailman?
- Is the virgin runner running? (ps aux | grep virgin) Are there messages stuck in queue/virgin or elsewhere in queue/*? Especially queue/shunt and queue/bad.
As long as I'm asking, may as well check these as well:
- What versions of Mailman applications (mailman, Postorius, HyperKitty, mailmanclient, django-mailman3) are installed?
- What version of Python are you running Mailman under?
- What is the operating system?
-Mailman was installed using the virtual environment.
-Mailman info: GNU Mailman 3.3.9 (Tom Sawyer) Python 3.12.3 (main, Feb 4 2025, 14:48:35) [GCC 13.3.0] config file: /etc/mailman3/mailman.cfg db url: postgresql://mailman:PasswordBlanked@localhost/mailman devmode: DISABLED REST root url: http://localhost:8001/3.1/ REST credentials: restadmin:restpass
-I use systemd to stop and start the services.
-Virgin is running: mailman 2041324 0.0 1.1 118832 91972 ? S Mar24 0:29 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=virgin:0:1 mailman 2897963 0.0 0.0 6544 2304 pts/1 S+ 14:51 0:00 grep virgin Note: Not sure how to check the queue, but when I run mailman3 notify, the moderator e-mails get sent.
-Versions: Mailman 3.3.9 Postorius Version 1.3.10 HyperKitty version 1.3.9 Postfix = 3.8.6 Django version = 4.2.13
jkoral@luc.edu writes:
-Mailman was installed using the virtual environment. -Mailman info: -I use systemd to stop and start the services.
OK, this is all about as close to the environment most of the Mailman devs run as you can get. On the one hand, it's easiest for us to understand, but it also makes it more mysterious when something doesn't work ... "works for me", you know.
REST credentials: restadmin:restpass
You should change this. It just makes it a little more annoying for someone unauthorized who gets access to port 8001, but it's very low cost to change.
-Virgin is running: Note: Not sure how to check the queue, but when I run mailman3 notify, the moderator e-mails get sent.
Good. The queues are implemented with Python pickle files in the "queue" subtree, probably /opt/mailman/var/queue in your case, or maybe /opt/mailman/mm/var/queue if you use Mark's preferred setup. You're looking for .pck files in subdirectories of that directory which are older than about 5 minutes.
I don't have a suggestion why the "notify immediately" option isn't working. Both the 'mailman notify' command and the 'notify immediately' option work the same way, by composing the notification and dropping it in the virgin queue.
This should tell you the same thing that Postorius does, but you could try "su - mailman" followed by activating the virtual environment, then type
mailman withlist -l list.with.problem
and then
m.admin_immed_notify
expecting the response True according to your setting. If it comes up False, there's your problem but we need to figure out why that's different from what Postorius is telling you. You should be able to change it as well by typing
m.admin_immed_notify = True commit()
and exiting.
Steve
Stephen, Looking at the queues, I see 27 .pck files under shunt from Nov 14th. Could that be the issue why moderators are not getting their e-mails right away? Can I clear the queue by just deleting these files?
Thanks, Joe
On March 28, 2025 12:06:19 AM GMT+07:00, jkoral@luc.edu wrote:
Stephen, Looking at the queues, I see 27 .pck files under shunt from Nov 14th. Could that be the issue why moderators are not getting their e-mails right away? Can I clear the queue by just deleting these files?
For each one of those there will be an error message and a SHUNTING message in mailman.log. The error message with traceback will help you diagnose the issue.
You can examine the files with mailman qfile. Once you fix the issue causing the exception, you can reprocess the shunted messages with mailman unshunt.
-- Mark Sapiro <mark@msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.
jkoral@luc.edu writes:
Looking at the queues, I see 27 .pck files under shunt from Nov 14th. Could that be the issue why moderators are not getting their e-mails right away?
No. That is way too old to be the cause of the current moderation issue.
Presumably that occurred either at time of upgrade due to some initial misconfiguration, or during a period of network glitching, or possibly it's a spate of spam. The paranoid thing to do with those messages is use "mailman qfile <file>" to examine them, delete any that are unneeded, and use "mailman unshunt" to send the rest (possibly with a separate message from you to subscribers explaining why old messages are suddenly appearing). But you could just assume they're obsolete and delete them.
I use
cd /path/to/queue/shunt for file in *.pck; do mailman qfile $file | less; done
and take notes of which to delete in such situations.
Can I clear the queue by just deleting these files?
No. You should *never* delete files in shunt or bad in hopes of resolving an issue. Translated into English, "shunt" is Mailman telling you "as far as Mailman can tell, these messages should be deliverable but something is going wrong, and I need your help to get them sent". Implied is "if *you* don't fix the 'something' for me, it will happen again and I will shunt again."
It was worth a try to look at shunt, but unless something very weird is happening to file timestamps, those aren't your missing notifications.
I wonder if *owners* get immediate notifications if they are not listed as *moderators*. I seem to recall that they didn't (but maybe I'm imagining things). I don't have time to check right now.
Steve
On 3/26/25 6:46 AM, jkoral@luc.edu wrote:
OK, another thought. Could it be because of the way my cronjob is setup??? Here is what I have.
@daily /opt/mailman/venv/bin/mailman digests --periodic @daily /opt/mailman/venv/bin/mailman notify
/opt/mailman/venv/bin/mailman-web runjobs minutely
That looks good, but admin_immed_notify doesn't depend on any cron.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 3/26/25 5:30 AM, jkoral@luc.edu wrote:
Who should the moderator e-mail come from when the moderator has to approve something? I have been searching the logs and cannot find that an e-mail for that exists.
It is From: the listname-owner address and sent to the listname-owner address which then resends it to the actual owner and moderator addresses.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 3/26/25 12:52 AM, jkoral@luc.edu wrote:
Mark, thank you for your reply. I did not mention it, but that is already set and we are still having an issue. Is there anything in the setting I can check? Also, I changed the name of the e-mail in the settings and restarted the mailman3 service. Does anything else need to be restarted?
Assuming admin_immed_notify is True (Postorius Admin immed notify is Yes), the notice should be sent. Check Mailman's mailman.log and your MTA logs for clues.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark, can you clarify the part about (Postorius Admin immed notify is Yes)? Is that a separate setting than admin_immed_notify is True? If so , how do I check that setting.
On March 27, 2025 2:20:56 AM GMT+07:00, jkoral@luc.edu wrote:
Mark, can you clarify the part about (Postorius Admin immed notify is Yes)? Is that a separate setting than admin_immed_notify is True? If so , how do I check that setting.
They are the same. The setting is admin_immed_notify which is a True/False setting. This setting is exposed in Postorius as a Yes/No setting called Admin immediately notify.
-- Mark Sapiro <mark@msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.
Hi Mark and Stephen, Is there anything else that I can look for or can you make any other suggestions?
Thanks, Joe
On 4/3/25 12:45, jkoral@luc.edu wrote:
Hi Mark and Stephen, Is there anything else that I can look for or can you make any other suggestions?
First, verify admin_immed_notify with this mailman shell interaction
$ /opt/mailman/mm/bin/mailman shell
Welcome to the GNU Mailman shell
Use commit() to commit changes.
Use abort() to discard changes since the last commit.
Exit with ctrl+D does an implicit commit() but exit() does not.
>>> for mlist in getUtility(IListManager):
... print(f'List {mlist.fqdn_listname} '
... f'Immed notify {mlist.admin_immed_notify}')
...
<output here>
Then, send a message to the list that will be held for moderation and check mailman.log and the MTA log for clues.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
I am having a similar issue as Joe.
Our Mailman 3 server is running on Rocky Linux 9.5. It is deployed using a Python virtual environment.
(venv) [mailman@<server> shunt]$ mailman info GNU Mailman 3.3.9 (Tom Sawyer) Python 3.9.21 (main, Dec 5 2024, 00:00:00) [GCC 11.5.0 20240719 (Red Hat 11.5.0-2)] config file: /etc/mailman3/mailman.cfg <output trimmed>
Mailman 3.3.9 Postorius Version 1.3.10 HyperKitty version 1.3.9 Postfix = 3.5.25-1.el9 (may have some newer bits backported into it - RHEL way) Django version = 4.2.13
Output of the for loop Mark provided above shows that all the lists on the server have admin_immed_notify set to True.
Here is the activity from the mailman.log file when I send a message to the list and it gets held:
Apr 21 19:11:37 2025 (2564) sans-faculty: DMARC lookup for dgoldsmith@sans.org (_dmarc.sans.org) found p=reject in _dmarc.sans.org. = v=DMARC1; p=reject; rua=mailto:dmarc_agg@vali.email Apr 21 19:11:37 2025 (2564) HOLD: sans-faculty@mlm.sans.org post from dgoldsmith@sans.org held, message-id= <SJ0PR18MB5112D63A7D9F3851A4A6B0C0AEB82@SJ0PR18MB5112.namprd18.prod.outlook.com>: The message comes from a moderated member
No further activity indicating it sends (or attempts to) a notice to the list admins/mods about a held message.
dgoldsmith--- via Mailman-users writes:
Here is the activity from the mailman.log file when I send a message to the list and it gets held:
Most of the activity you're interested in would be in smtp.log. The interactions with the mail system are broken out into channels with separate log files (smtp, bounce). The vette channel is the one that records the actual hold decision in mailman.log (by default, you could configure it to have its own file).
-- GNU Mailman consultant (installation, migration, customization) Sirus Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On Mon, Apr 21, 2025 at 10:16 PM dgoldsmith--- via Mailman-users < mailman-users@mailman3.org> wrote:
I am having a similar issue as Joe.
Our Mailman 3 server is running on Rocky Linux 9.5. It is deployed using a Python virtual environment.
(venv) [mailman@<server> shunt]$ mailman info GNU Mailman 3.3.9 (Tom Sawyer) Python 3.9.21 (main, Dec 5 2024, 00:00:00) [GCC 11.5.0 20240719 (Red Hat 11.5.0-2)] config file: /etc/mailman3/mailman.cfg <output trimmed>
Mailman 3.3.9 Postorius Version 1.3.10 HyperKitty version 1.3.9 Postfix = 3.5.25-1.el9 (may have some newer bits backported into it - RHEL way) Django version = 4.2.13
Output of the for loop Mark provided above shows that all the lists on the server have admin_immed_notify set to True.
Here is the activity from the mailman.log file when I send a message to the list and it gets held:
Apr 21 19:11:37 2025 (2564) sans-faculty: DMARC lookup for dgoldsmith@sans.org (_dmarc.sans.org) found p=reject in _dmarc.sans.org. = v=DMARC1; p=reject; rua=mailto:dmarc_agg@vali.email Apr 21 19:11:37 2025 (2564) HOLD: sans-faculty@mlm.sans.org post from dgoldsmith@sans.org held, message-id= < SJ0PR18MB5112D63A7D9F3851A4A6B0C0AEB82@SJ0PR18MB5112.namprd18.prod.outlook.com>: The message comes from a moderated member
No further activity indicating it sends (or attempts to) a notice to the list admins/mods about a held message.
Assuming you did run the mailman shell command and the output was:
List sans-faculty@mlm.sans.org Immed notify True
What do you have in your MTA logs around the same time? Nothing?
That would imply that for this list, you have set "Default action to take when a non-member posts to the list" to "Discard" If you change that setting to "Hold for moderation", then you will receive a notification.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
participants (6)
-
dgoldsmith＠sans.org -
jkoral＠luc.edu -
Mark Sapiro -
Odhiambo Washington -
Stephen J. Turnbull -
Stephen J. Turnbull