How do I tell if mailman-web is running? There is no such service.

Which installation instructions did you follow from https://docs.mailman3.org/en/latest/install/install.html ?

If it was virtualenv (recommended) you have systemd services configured. Then run:

systemctl | grep mail

What does it show? Another method:

ps -ef | grep -i python

The mlist name is wrong. It should be lllllllllll%40gmail.com.

The mlist should be gmail.com?
Which official DNS domain are you using?
Usually mailing lists are set up on a DNS domain that you control. Are you an administrator of bellsouth.net or gmail.com? Or are those simply an end-user email account. You would register a domain with a registrar, and then create mailing lists on mydomain116.com, for example, or whatever the domain is.

He can't or won't pay for it.

Googling: cheapest dns registrar, the results say "Register cheap domain names from $0.99" and "Starting at $0.99!"
Ok. It sounds like a difficult and convoluted exercise in mail flow configuration. :-)

If it becomes impossible I will switch back to mailman2 which works on my CentOS system.

Mark Sapiro writes:

On 12/26/25 07:25, dap1--- via Mailman-users wrote:

If it becomes impossible I will switch back to mailman2 which

...

works on my CentOS system.

This is a viable solution[...].

Much of your issue with Mailman 3 is because in MM 3, mail delivery to Mailman is different and list names include the domain. This prevents things which worked in your MM 2 configuration from working in MM 3.

Sure, but I don't see why the right Postfix configuration wouldn't allow Mailman 3 to work as well as Mailman 2. This isn't a Mailman configuration problem as far as I can see -- just make a vanilla configuration based on the desired posting address. The problems are in routing to Mailman via fetchmail and Postfix. Since the tranport_maps take precedence over pretty much everything, and can be address-specific, just put the @gmail.com addresses he uses in there in the usual way. Then tell fetchmail to forward those addresses as is to Postfix's SMTP (depending on what other mail it needs to handle he might want to set up a configuration for an smtpd on port 8025, but probably not necessary). Maybe it's convenient for fetchmail to set Postfix's extension separator to '-' so that "cufsalumni-*@gmail.com" addresses are recognized as "cufsalumni@gmail.com" variants by Postfix. The transport_maps will pick those addresses (and only those cufsalumni*@gmail.com addresses of any gmail.com addresses) and forward them to Mailman, which will DTRT.

The problems I see with routing have to do with the impossibility of spoofing a Gmail origin for verifications and notifications, and anonymous lists etc that configure From to be the list. But that's going to be a problem for Mailman 2 as well AFAICS. His basic problem is that he chooses to operate with only one From address that is reliably deliverable in the current Internet, and unfortuately that's his personal address.

One solution I can think of would be to send the administrative list traffic out through Gmail's SMTP gateway using his registered cufsalumni-* accounts. That might work well -- it's Postfix's job so Mailman doesn't need to know about it, those should be infrequent at best, and they won't be relays from 3rd parties as mailing list posts usually are.

Dunno what's going on with his web configuration, tho.

-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

On 12/24/25 08:14, dap1--- via Mailman-users wrote:

How do I tell if mailman-web is running? There is no such service.

In this case, the mailman-web service is gunicorn.

/etc/mailman3/gunicorn.py (recall I had to use py rather than conf to get it to work under Ubuntu):

It should have worked as gunicorn.conf despite the warning (not error) that it didn't have a .py extension.

# /etc/mailman3/gunicorn.conf # # bind = ['127.0.0.1:8000'] proc_name = "mailman-web" # # If you are having response issues you can tune the number of workers. # # The suggested starting point is (2 x $num_cores) + 1 # # See https://docs.gunicorn.org/en/latest/design.html#how-many-workers workers = 3 chdir = "/opt/mailman/mm" pidfile = "/opt/mailman/mm/var/gunicorn.pid" accesslog = "/opt/mailman/mm/var/logs/access.log" errorlog = "/opt/mailman/mm/var/logs/error.log" loglevel = 'debug'

I did notice one thing in the access.log that is wrong:

127.0.0.1 - - [24/Nov/2025:16:02:55 +0000] "GET /archives/api/mailman/urls?mlist=lllllllllll%40dddddd.net&msgid=705caa ab-afcc-4249-8d1d-cc48050d02d1%40bellsouth.net HTTP/1.1" 200 113 "-" "python-requests/2.32.5"

This request came from HyperKitty.

The mlist name is wrong. It should be lllllllllll%40gmail.com. I don't know where that is coming from but I'm sure it is left over from before I changed the list name.

To you have a hyperkitty list named lllllllllll%40dddddd.net. What does

SELECT name FROM hyperkitty_mailinglist;

show?

When I include the port in the URL I get an unable to connect page.

So nothing is listening on 127.0.0.1:8000 (localhost:8000 assuming the localhost is 127.0.0.1 in /etc/hosts and not an IPv6 fe00::0 address)

What if any does netstat -lntp show is listening on 127.0.0.1:8000?

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

I'm running everything in the virtual environment.

There is no such service.

If following the instructions from Virtualenv Installation https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-insta... it recommends creating a systemd service for gunicorn.

"Automatically starting Mailman-web. In order to automatically start at startup, you can create a second systemd service, mailmanweb.service. Create a new file /etc/systemd/system/mailmanweb.service" "If using Gunicorn, the ExecStart line above becomes...:"

Review that section, and create a systemd service called mailmanweb.service. It will start either uwsgi or gunicorn. Then start it. Debug from there.

On 12/26/25 08:02, dap1--- via Mailman-users wrote:

SELECT name FROM hyperkitty_mailinglist; +--------------------------+ | name | +--------------------------+ | lllllllll@ddddddddd.net | | lllllllll@gmail.com | +--------------------------+ 2 rows in set (0.00 sec)

It seems just deleting lllllllll@ddddddddd.net is non-trivial. Cannot delete or update a parent row: a foreign key constraint fails (mailmanweb.hyperkitty_email , CONSTRAINT hyperkitty_email_mailinglist_id_2c2b6f03_fk_hyperkitt FOREIGN KEY (mailinglist_id) REFERENCES hyperki tty_mailinglist (id))

This is not a critical issue so you can just ignore it until you get the web UI working at which time a Django superuser or the list owner can delete the list in HyperKitty's web UI.

If you want to do it in the database, I think you can first do

DELETE FROM hyperkitty_attachment WHERE hyperkitty_attachment.email_id IN (SELECT id FROM hyperkitty_email WHERE hyperkitty_email.mailinglist_id IN (SELECT id FROM hyperkitty_mailinglist WHERE hyperkitty_mailinglist.name = 'lllllllll@ddddddddd.net'));

to delete attachments and then do

DELETE FROM hyperkitty_email WHERE hyperkitty_email.mailinglist_id IN (SELECT id FROM hyperkitty_mailinglist WHERE hyperkitty_mailinglist.name = 'lllllllll@ddddddddd.net');

to delete the emails and finally

DELETE FROM hyperkitty_mailinglist WHERE hyperkitty_mailinglist.name = 'lllllllll@ddddddddd.net';

But this may possibly run into other foreign key constraint issues. It's probably easier to get the web UI up and do it there.

netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.54:53 0.0.0.0:* LISTEN 1103/systemd-resolv tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 1407/mysqld tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 1644/smbd tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 1644/smbd tcp 0 0 127.0.0.1:8001 0.0.0.0:* LISTEN 74794/python3 tcp 0 0 127.0.0.1:8024 0.0.0.0:* LISTEN 74791/python3 tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 1103/systemd-resolv tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 74696/master tcp 0 0 0.0.0.0:26 0.0.0.0:* LISTEN 1/init tcp 0 0 127.0.0.1:33060 0.0.0.0:* LISTEN 1407/mysqld tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 160003/cupsd tcp6 0 0 :::443 :::* LISTEN 132763/apache2 tcp6 0 0 :::445 :::* LISTEN 1644/smbd tcp6 0 0 :::139 :::* LISTEN 1644/smbd tcp6 0 0 :::80 :::* LISTEN 132763/apache2 tcp6 0 0 :::25 :::* LISTEN 74696/master tcp6 0 0 :::26 :::* LISTEN 1/init tcp6 0 0 ::1:631 :::* LISTEN 160003/cupsd

I'm not using IPV6. Nothing is listening on 8000, just 8001 and 8024.

It appears that guicorn is not running if there is supposed to be a process by that name. There is also no such service.

See https://docs.mailman3.org/en/latest/install/virtualenv.html#automatically-st...

Particularly the part that says:

If using Gunicorn, the ExecStart line above becomes:

ExecStart=/opt/mailman/venv/bin/gunicorn -c /etc/mailman3/gunicorn.conf mailman_web.wsgi:application

Do you have that and is the mailmanweb service running?

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan