Our company is evaluating mailman3 as an option for company internal list serving.
One of the requirements is that anyone with access to the list server be allowed to create and manage lists.
Is this possible? If so, how? Is there a "create list" role that can be added for all registered users?
I'm in an odd situation where I need to rename a bunch of lists. They
were all created on mailman2 originally and migrated to mailman3 (very
successfully, TYVM) but the names were all originally
discuss-<foo>@domain and it's very confusing to be sure you're always
sending to the correct <foo>. We want to completely rename the lists to
These lists do not keep archives, so if I have to resort to extracting
the subscriber lists and the configs and building new lists, I'm
completely fine with that. Problem is, I'm really used to MM2 and
config_list and could do this without thinking using those tools... that
I don't have.
Running MM3 3.2.2 trying to make this happen. Any assistance I could
get will be greatly appreciated.
Web Administrator, Alpha Psi Omega Grand Cast
etc... etc... etc...
I’ve got a strange error. I migrated from mailman 2.1 to 3 using the migration guide on the website and things have been working fine. But I’m in the process of testing the new syncmembers command to replace some inhouse mailman API code we wrote. I’ve tracked my problem down to what appears to be a deadlock in the postgresql database. When trying to delete certain users the SQL query hangs and never returns.
After doing some tracing and tracking it down to the database, I enabled DB logging of all queries and saw that the following query was never returning:
DELETE FROM member WHERE member.id = 166814
If I try to run it manually I get the same issue, in psql it never returns.
mailman=# explain analyze DELETE FROM member WHERE member.id = 166814;
[… 60 seconds passes…]
^CCancel request sent
ERROR: canceling statement due to user request
CONTEXT: while deleting tuple (2998,72) in relation "member"
I’m just wondering if there are any commands or scripts I can run to verify the database and it’s constraints to see if there is some error in the database data? Or where you’d recommend I go from here? It only impacts the user on this specific list. If I add this user to another list and remove them, everything works fine.
This is on a test system so I can do various testing. I’m trying to find the root cause so that I can verify my production system isn’t impacted by the same thing.
OS: Oracle Linux 7 (Redhat)
Installed using pip via virtualenv talking to a local pgsql database on the same box.
Data was migrated from a mailman 2.1 install into mailman3 using migration instructions on the website.
PIP Modules versions:
I have mailman3 running now, more or less. Mailman did not send messages
to my list, giving a permiission error on the digest.mmdf file, which
was not there. I created the file and made list.list the owner, now it
I don't know what should have created the file or what set the
permissions to the directory, I just thought I'd let you know.
dagdag is just a two character rotation of byebye
I was testing out the process of rejecting an incoming subscription
request. Choosing the reject option for a moderated subscription request
does send out a rejection notice but it gives no reason for the
rejection. Please see:
Your request to the redacted(a)redacted.com mailing list
has been rejected by the list moderator. The moderator gave the
following reason for rejecting your request:
"[No reason given]"
Any questions or comments should be directed to the list administrator
Is there a place somewhere in Postorius to provide a rejection reasons
for moderated subscription requests? Does Mailman 3 core provide this
via its REST api but it is just not revealed in Postorius yet?
I have been using mailman for about ten years, now I want to move the
lists to another server, I have installed mailman3 there, most of it
seems to be running, but the "rest api runner" is not. Nothing is
listening on port 8001. What have I missed? What do I do to start the
restapi runner? I checked the logs, I don't see anything suspicious.
this is what systemctl status says:
root@lists:~# systemctl status mailman3
● mailman3.service - Mailman3 server
Loaded: loaded (/lib/systemd/system/mailman3.service; enabled;
vendor preset: enabled)
Active: failed (Result: timeout) since Sat 2021-03-27 12:04:06
UTC; 6min ago
Process: 173111 ExecStart=/usr/bin/mailman -C
/etc/mailman3/mailman.cfg start --force (code=killed, signal=TERM)
Mar 27 12:02:36 lists systemd: Starting Mailman3 server...
Mar 27 12:04:06 lists systemd: mailman3.service: start operation
timed out. Terminating.
Mar 27 12:04:06 lists systemd: mailman3.service: Failed with result
Mar 27 12:04:06 lists systemd: Failed to start Mailman3 server.
There is nothing in mailman.log, nor in smtp.log
dagdag is just a two character rotation of byebye
I am moving the website www.t10.org from a private/corporate VM to AWS EC2s.
For many years, t10.org has had very happy results with using Mailman 2 for its email reflector, and I have no real concerns about moving to Mailman 3. My bugbear is the fact that I need the following mixed bag of incoming email addresses to work in concert with each other to receive and handle emails.
> t10(a)t10.org (Primary Mailman Reflector)
> chair(a)t10.org (Mailman Reflector to direct messages to the T10 chair and his designates)
* docs(a)t10.org (document posting mechanics - serviced by a small mountain of home-grown code code)
* bbs(a)t10.org (other publicly accessible services - serviced by code that recalls the days when everything as done on a Bulletin Board System, BBS)
My best guess is that the AWS Simple Email Service (SES) needs to sit in front of both Mailman and the home-grown code, to properly direct the incoming emails to the right places. The big worry is as follows...
All available evidence read to date suggests that the default AWS installation of Mailman 3 assumes that Mailman 3 is the *only* receiver of emails in the configuration. If true, then putting SES in front of Mailman could be a Herculean challenge.
Or... Hercules may have already cleaned the Augean Stables, and left behind a AWS Lambda function that can serve as a keystone puzzle piece for solving my dilemma.
Thanks for taking the time to look at this.
All the best,
FWIW Information about the current t10.org Mailman reflector can be found at https://www.t10.org/t10r.htm. T10 is primarily an open-to-the-public activity, so there are no company confidential secrets there.
For those interested in the archives associated with the t10.org Mailman reflector, they are available at https://www.t10.org/pipermail/t10/ and "inquiring minds" may puzzle over the fact that the archives date back to December 1993. When Mailman 2 was installed, we converted all the Majordomo archives to Mailman 2 format.
I keep seeing bounces being recorded in logs/bounce.log that have no
corresponding entry in Postfix's mail.log. For instance one address had
registered about 2 dozen bounces in the past week in bounce.log and yet
every single entry for this address in mail.log has a status=sent. What
am I missing here?