
Dear list,
We've encountered an issue with Postorius after migrating from Mailman 2.1. It appears that Postorius is treating email addresses with differing capitalization as distinct user accounts. For example, <markus.grandpre@uni-konstanz.de> and <Markus.Grandpre@uni-konstanz.de> are being recognized as separate identities.
This is causing significant confusion. Users registered with one capitalization pattern are not seeing the list subscriptions and settings that were previously associated with their account (imported from Mailman v2.1) which used a different capitalization.
Is there a known configuration option or method within Postorius (or Mailman 3 itself) to normalize or unify account identification, effectively treating email addresses as case-insensitive for account matching?
We need a solution that ensures users see their correct list memberships regardless of the capitalization they use when logging in or that was used during the original Mailman 2.1 import.
Thank you in advance Markus
-- Markus Ludwig Grandpré Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre, B803, Tel: ++49 7531 88 4342

Markus Grandpré writes:
We've encountered an issue with Postorius after migrating from Mailman 2.1. It appears that Postorius is treating email addresses with differing capitalization as distinct user accounts. For example, <markus.grandpre@uni-konstanz.de> and <Markus.Grandpre@uni-konstanz.de> are being recognized as separate identities.
That's not true on the systems I've worked with most recently -- those will be recognized as duplicate addresses, both at list import time and at login on Postorius. Those are versions Mailman 3.3.9 and 3.3.11, with corresponding Postorius. As far as I can tell the last case- sensitivity bugs were fixed as of Mailman 3.2.1 (released 2019-02-22). Postorius does not appear to have had any case sensitivity bugs (not surprising since Postorius just passes them through to Mailman).
I guess it's possible that this is a Debianism, or there was a temporary regression around 3.3.8.
Is there a known configuration option or method within Postorius (or Mailman 3 itself) to normalize or unify account identification, effectively treating email addresses as case-insensitive for account matching?
There is no such configuration option because Mailman has treated email addresses as case insensitive for quite a while. All I can recommend is an upgrade.
Steve

Hello,
I guess it's possible that this is a Debianism, or there was a temporary regression around 3.3.8.
That is a problem with older versions of django-allauth. Which happens to be used in the mailman3 version of Debian 12.
You can read all the details in this issue: https://github.com/pennersr/django-allauth/issues/3019
At the end of the issue comments you can find the link to a script written by msapiro to fix/workaround this issue.
Regards, Bernhard

Dear Steve, dear list
That's not true on the systems I've worked with most recently -- those will be recognized as duplicate addresses (...)
You are right. I am sorry for this confusion. Please let me correct my initial posting to this list from yesterday, saying:
(...) <markus.grandpre@uni-konstanz.de> and <Markus.Grandpre@uni-konstanz.de> are being recognized as separate identities.
That is not the case. Meanwhile I discovered an error with logging into Postorius when an account is associated with two semantically identical email addresses that differ in their formatting, e.g.,
<markus.grandpre@uni-konstanz.de>
and
<Markus.Grandpre@uni-konstanz.de>.
In this case, the user is unable to log in, and I observed the following error message in the log file:
(...) returned more than one EmailAddress -- it returned 2!
Here is the complete stack trace of this error:
ERROR 2025-02-10 14:29:55,599 211159 django.request Internal Server Error: /mailman3/accounts/login/ Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 47, in inner response = get_response(request) ^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 181, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 70, in view return self.dispatch(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/utils/decorators.py", line 43, in _wrapper return bound_method(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/views/decorators/debug.py", line 89, in sensitive_post_parameters_wrapper return view(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/views.py", line 149, in dispatch return super(LoginView, self).dispatch(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/views.py", line 77, in dispatch response = super(RedirectAuthenticatedUserMixin, self).dispatch( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 98, in dispatch return handler(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/views.py", line 105, in post response = self.form_valid(form) ^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/views.py", line 162, in form_valid return form.login(self.request, redirect_url=success_url) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/forms.py", line 196, in login ret = perform_login( ^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/utils.py", line 168, in perform_login response = adapter.pre_login(request, user, **hook_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/adapter.py", line 411, in pre_login if not has_verified_email(user, email): ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/utils.py", line 130, in has_verified_email emailaddress = EmailAddress.objects.get_for_user(user, email) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/managers.py", line 54, in get_for_user ret = self.get(user=user, email__iexact=email) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/db/models/manager.py", line 85, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 439, in get raise self.model.MultipleObjectsReturned( allauth.account.models.EmailAddress.MultipleObjectsReturned: get() returned more than one EmailAddress -- it returned 2! ERROR 2025-02-10 14:29:55,599 211159 django.request Internal Server Error: /mailman3/accounts/login/ Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 47, in inner response = get_response(request) ^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 181, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 70, in view return self.dispatch(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/utils/decorators.py", line 43, in _wrapper return bound_method(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/views/decorators/debug.py", line 89, in sensitive_post_parameters_wrapper return view(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/views.py", line 149, in dispatch return super(LoginView, self).dispatch(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/views.py", line 77, in dispatch response = super(RedirectAuthenticatedUserMixin, self).dispatch( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 98, in dispatch return handler(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/views.py", line 105, in post response = self.form_valid(form) ^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/views.py", line 162, in form_valid return form.login(self.request, redirect_url=success_url) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/forms.py", line 196, in login ret = perform_login( ^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/utils.py", line 168, in perform_login response = adapter.pre_login(request, user, **hook_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/adapter.py", line 411, in pre_login if not has_verified_email(user, email): ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/utils.py", line 130, in has_verified_email emailaddress = EmailAddress.objects.get_for_user(user, email) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/managers.py", line 54, in get_for_user ret = self.get(user=user, email__iexact=email) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/db/models/manager.py", line 85, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 439, in get raise self.model.MultipleObjectsReturned( allauth.account.models.EmailAddress.MultipleObjectsReturned: get() returned more than one EmailAddress -- it returned 2!
To resolve the issue, the only solution I found was to manually delete the second email address from the database:
mailman3web-prod=> select * from account_emailaddress where user_id = 93; id | email | verified | primary | user_id -----+---------------------------------+----------+---------+--------- 100 | Markus.Grandpre@uni-konstanz.de | t | t | 93 101 | markus.grandpre@uni-konstanz.de | t | f | 93 (2 rows) mailman3web-prod=> delete from account_emailaddress where id = 100; DELETE 1 mailman3web-prod=> select * from account_emailaddress where user_id = 93 ; id | email | verified | primary | user_id -----+---------------------------------+----------+---------+--------- 101 | markus.grandpre@uni-konstanz.de | t | f | 93 (1 row)
Could I have achieved the same deletion using the REST interface?
After the deletion login with <markus.grandpre@uni-konstanz.de> was possible again, and I set the remaining email address as 'primary' using Postorius.
I am not entirely sure how the duplicate email address came into the system. During the data migration from Mailman 2.1 to Mailman 3, an account was created for <markus.grandpre@uni-konstanz.de>. It is most likely that during registration, the user provided <Markus.Grandpre@uni-konstanz.de> as username or email address, which resulted in both variations of the semantically same email address being stored under the same account.
I apologize again for the incorrect information in my initial message to this list. I should have waited until I had a clearer understanding of this issue.
Best regards, Markus
Am 10.02.25 um 15:32 schrieb Stephen J. Turnbull:
Markus Grandpré writes:
We've encountered an issue with Postorius after migrating from Mailman 2.1. It appears that Postorius is treating email addresses with differing capitalization as distinct user accounts. For example, <markus.grandpre@uni-konstanz.de> and <Markus.Grandpre@uni-konstanz.de> are being recognized as separate identities.
That's not true on the systems I've worked with most recently -- those will be recognized as duplicate addresses, both at list import time and at login on Postorius. Those are versions Mailman 3.3.9 and 3.3.11, with corresponding Postorius. As far as I can tell the last case- sensitivity bugs were fixed as of Mailman 3.2.1 (released 2019-02-22). Postorius does not appear to have had any case sensitivity bugs (not surprising since Postorius just passes them through to Mailman).
I guess it's possible that this is a Debianism, or there was a temporary regression around 3.3.8.
Is there a known configuration option or method within Postorius (or Mailman 3 itself) to normalize or unify account identification, effectively treating email addresses as case-insensitive for account matching?
There is no such configuration option because Mailman has treated email addresses as case insensitive for quite a while. All I can recommend is an upgrade.
Steve
-- Markus Ludwig Grandpré Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre, B803, Tel: ++49 7531 88 4342

Markus Grandpré writes:
Dear Steve, dear list
That's not true on the systems I've worked with most recently -- those will be recognized as duplicate addresses (...)
You are right. I am sorry for this confusion. Please let me correct my initial posting to this list from yesterday, saying:
(...) <markus.grandpre@uni-konstanz.de> and <Markus.Grandpre@uni-konstanz.de> are being recognized as separate identities.
That is not the case. Meanwhile I discovered an error with logging into Postorius when an account is associated with two semantically identical email addresses that differ in their formatting, e.g.,
Yes. Apparently this is a problem of a policy difference between Mailman 3 and the Django allauth package, as Bernhard Lichtinger pointed out in <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...>
allauth takes the point of view that the localpart of an email address is the "property" of the provider of the mailbox, and therefore should be taken verbatim by third parties. Mailman takes the more practical point of view that, in practice, almost all providers treat localparts as case insensitive. (Some -- Gmail, grrrrr -- go farther and ignore whole characters such as periods.) The problem is that users treat email addresses as case insensitive, and aren't very careful about using the same case every time. That's why I think the Mailman approach is appropriate.
To resolve the issue, the only solution I found was to manually delete the second email address from the database:
That will work in the short run, but I'm not sure that's a long-term solution. It's not clear to me that allauth won't do the same thing again.
Could I have achieved the same deletion using the REST interface?
I don't know. I would think not. I suspect Mailman code can only find the lowercase version. Mark has a script that looks for such duplicates using psycopg, not mailmanclient, so it accesses the database via the PostgreSQL API, not Mailman's REST API. It deletes any duplicate that is not all-lowercase:
https://github.com/pennersr/django-allauth/issues/3019#issuecomment-24402316...
I am not entirely sure how the duplicate email address came into the system.
allauth did it. It's explained in the issue where Mark's script is attached. It's not very easy to follow the discussion, though. And there's something weird going on because in your stack trace, it appears that allauth is doing a case insensitive database search. So I would just grab the script and run it, in case there are other users with extra addresses that compare equal when comparison is case insensitive.
I apologize again for the incorrect information in my initial message to this list.
No need to apologize. It's extremely complicated. Of course we're happy if you look around and figure out most of it for us!
Steve

On 2/11/25 01:26, Stephen J. Turnbull wrote:
That will work in the short run, but I'm not sure that's a long-term solution. It's not clear to me that allauth won't do the same thing again.
Allauth since 0.62.0 and better since 0.63.0 no longer does this. See https://codeberg.org/allauth/django-allauth/src/branch/main/ChangeLog.rst#se...
Could I have achieved the same deletion using the REST interface?
I don't know. I would think not.
That's correct. The issue is in the account_emailaddress database table which is an allauth table that Mailman core and hence the REST api know nothing about.
Our latest recommendation is django-allauth>=65.4, but that requires changes, see https://gitlab.com/mailman/django-mailman3/-/merge_requests/316 and https://gitlab.com/mailman/mailman-web/-/merge_requests/58 although the changes only affect testing and a deprecation warning.
Also, installing that django-allauth version may result in upgrading Django to a version which doesn't support django-haystack<3.3.0 and may also require manually upgrading django-haystack.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Running Debian 4.19.316-1 Python 3.7.3
I am unable to start mailman core
mailman@lists:~$ /opt/mailman/mm/bin/mailman start Usage: mailman start [OPTIONS] Try 'mailman start -h' for help.
Error: A previous run of GNU Mailman did not exit cleanly (stale_lock). Try using --force mailman@lists:~$
I try using --force and it did not work. So how do I start it?
Bottom line: I would like for Mailman core to start when I reboot the server. How can this be achieved please?

Christian via Mailman-users wrote on 2025-02-12 09:24:
I would like for Mailman core to start when I reboot the server. How can this be achieved please?
# systemctl enable --now mailman3
or:
$ sudo systemctl enable --now mailman3

That command generates an error.
root@lists:~# systemctl enable --now mailman3 Failed to enable unit: Unit file mailman3.service does not exist. root@lists:~#
-----Original Message----- From: Ron / BCLUG <admin@bclug.ca> Sent: Wednesday, February 12, 2025 9:36 AM To: mailman-users@mailman3.org Subject: [MM3-users] Re: Mailman REST API not available. Please start Mailman core.
Christian via Mailman-users wrote on 2025-02-12 09:24:
I would like for Mailman core to start when I reboot the server. How can this be achieved please?
# systemctl enable --now mailman3
or:
$ sudo systemctl enable --now mailman3
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/ RMLYRQY6MWAWELSO6226IT2ELPHGCDJ2/
This message sent to csa@web-analysts.net

Christian wrote on 2025-02-12 10:17:
That command generates an error.
root@lists:~# systemctl enable --now mailman3 Failed to enable unit: Unit file mailman3.service does not exist. root@lists:~#
To find the name of the service file, try:
# systemctl list-units | grep -i mailman
Then, enable --now with the resulting service should work.
If there's no service shown in the output of the grep
, the docs have
example service / unit files., see:
https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-mailman...

On 2/12/25 09:24, Christian via Mailman-users wrote:
Running Debian 4.19.316-1 Python 3.7.3
I am unable to start mailman core
mailman@lists:~$ /opt/mailman/mm/bin/mailman start Usage: mailman start [OPTIONS] Try 'mailman start -h' for help.
Error: A previous run of GNU Mailman did not exit cleanly (stale_lock). Try using --force mailman@lists:~$
I try using --force and it did not work. So how do I start it?
In Mailman's var/locks directory (maybe /opt/mailman/mm/var/locks/) you will see at least two files. The ones of interest are:
master.lck
master.lck|<host_name>|<pid>|<random_integer>
First verify that pid is not running or if it is, that it's not
Mailman's master
process. Then remove all the files from the
var/locks/ directory and Mailman should start.
Bottom line: I would like for Mailman core to start when I reboot the server. How can this be achieved please?
See https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-mailman...
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

That worked.
Now on https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-mailman -automatically it says
"Pay attention to the config file output above and make sure that you see /etc/mailman3/mailman.cfg there. If the config path is different, you should make sure to create a new config file at /etc/mailman3/mailman.cfg and re-run the command."
Well...mailman info yields
GNU Mailman 3.3.5 (Tom Sawyer) Python 3.7.3 (default, Mar 23 2024, 16:12:05) [GCC 8.3.0] config file: /opt/mailman/mm/mailman.cfg db url: postgres://mailman:5DqTHnv8hUQSdd@localhost/mailman devmode: DISABLED REST root url: http://localhost:8001/3.1/ REST credentials: restadmin:restpass
Should I create a new config file at /etc/mailman3/mailman.cfg ?
Lastly, when I ran this command it says "loaded failed failed"
(venv) mailman@lists:/opt/mailman/mm$ systemctl list-units | grep -i mailman gunicorn.service loaded active running GNU Mailman web interfaces ● mailman.service loaded failed failed GNU Mailing List Manager
Please advise. Thank you.
-----Original Message----- From: Mark Sapiro <mark@msapiro.net> Sent: Wednesday, February 12, 2025 10:33 AM To: mailman-users@mailman3.org Subject: [MM3-users] Re: Mailman REST API not available. Please start Mailman core.
On 2/12/25 09:24, Christian via Mailman-users wrote:
Running Debian 4.19.316-1 Python 3.7.3
I am unable to start mailman core
mailman@lists:~$ /opt/mailman/mm/bin/mailman start Usage: mailman start [OPTIONS] Try 'mailman start -h' for help.
Error: A previous run of GNU Mailman did not exit cleanly (stale_lock). Try using --force mailman@lists:~$
I try using --force and it did not work. So how do I start it?
In Mailman's var/locks directory (maybe /opt/mailman/mm/var/locks/) you will see at least two files. The ones of interest are:
master.lck
master.lck|<host_name>|<pid>|<random_integer>
First verify that pid is not running or if it is, that it's not Mailman's
master
process. Then remove all the files from the var/locks/ directory
and Mailman should start.
Bottom line: I would like for Mailman core to start when I reboot the server. How can this be achieved please?
See https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-mailman -automatically
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/ LV5WTFTNRZ455KPDESRQHFV67SJ5VOFH/
This message sent to csa@web-analysts.net

On Wed, Feb 12, 2025 at 11:05 PM Christian via Mailman-users < mailman-users@mailman3.org> wrote:
That worked.
Now on
https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-mailman -automatically <https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-mailman...> it says
"Pay attention to the config file output above and make sure that you see /etc/mailman3/mailman.cfg there. If the config path is different, you should make sure to create a new config file at /etc/mailman3/mailman.cfg and re-run the command."
Well...mailman info yields
GNU Mailman 3.3.5 (Tom Sawyer) Python 3.7.3 (default, Mar 23 2024, 16:12:05) [GCC 8.3.0] config file: /opt/mailman/mm/mailman.cfg db url: postgres://mailman:5DqTHnv8hUQSdd@localhost/mailman devmode: DISABLED REST root url: http://localhost:8001/3.1/ REST credentials: restadmin:restpass
Should I create a new config file at /etc/mailman3/mailman.cfg ?
Lastly, when I ran this command it says "loaded failed failed"
(venv) mailman@lists:/opt/mailman/mm$ systemctl list-units | grep -i mailman gunicorn.service loaded active running GNU Mailman web interfaces ● mailman.service loaded failed failed GNU Mailing List Manager
Please advise. Thank you.
rm -rf /opt/mailman mkdir /opt/mailman chown mailman:mailman /opt/mailman chmod 755 /opt/mailman sudo su mailman cd pwd [should show that you are in /opt/mailman]
Start over again from there.
'mailman info' ideally should say the config file is in /etc/mailman3/mailman.cfg If you follow the manual to the letter, you should have mailman3.service as the filename as per https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-mailman... .
-- 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]

On 2/12/25 12:17, Odhiambo Washington via Mailman-users wrote:
rm -rf /opt/mailman mkdir /opt/mailman chown mailman:mailman /opt/mailman chmod 755 /opt/mailman sudo su mailman cd pwd [should show that you are in /opt/mailman]
Start over again from there.
But if you currently have a working Mailman installation, maybe even a Debian package, and you don't want to start over from scratch, especially because you have Python 3.7.3 and current Mailman requires Python >=3.9,<=3.12, just see <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...>
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 2/12/25 12:05, Christian via Mailman-users wrote:
That worked.
Now on https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-mailman -automatically it says
"Pay attention to the config file output above and make sure that you see /etc/mailman3/mailman.cfg there. If the config path is different, you should make sure to create a new config file at /etc/mailman3/mailman.cfg and re-run the command."
Well...mailman info yields
GNU Mailman 3.3.5 (Tom Sawyer) Python 3.7.3 (default, Mar 23 2024, 16:12:05) [GCC 8.3.0] config file: /opt/mailman/mm/mailman.cfg db url: postgres://mailman:5DqTHnv8hUQSdd@localhost/mailman devmode: DISABLED REST root url: http://localhost:8001/3.1/ REST credentials: restadmin:restpass
Should I create a new config file at /etc/mailman3/mailman.cfg ?
You can, but the easiest thing is just replace the line
Environment="MAILMAN_CONFIG_FILE=/etc/mailman3/mailman.cfg"
in /etc/systemd/system/mailman3.service with
Environment="MAILMAN_CONFIG_FILE=/opt/mailman/mm/mailman.cfg"
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

I followed instructions provided here. Well, I rebooted the server and I'm getting the same error again at the web page of
"Mailman REST API not available. Please start Mailman core."
I again found locks in /opt/mailman/mm/var/locks . Once I removed them I could start mailman.
Perhaps I made a boo boo. I want mailman to start without locks upon reboot.
Help! (thanks)
-----Original Message----- From: Mark Sapiro <mark@msapiro.net> Sent: Wednesday, February 12, 2025 1:12 PM To: mailman-users@mailman3.org Subject: [MM3-users] Re: Mailman REST API not available. Please start Mailman core.
On 2/12/25 12:05, Christian via Mailman-users wrote:
That worked.
Now on https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-m ailman -automatically it says
"Pay attention to the config file output above and make sure that you see /etc/mailman3/mailman.cfg there. If the config path is different, you should make sure to create a new config file at /etc/mailman3/mailman.cfg and re-run the command."
Well...mailman info yields
GNU Mailman 3.3.5 (Tom Sawyer) Python 3.7.3 (default, Mar 23 2024, 16:12:05) [GCC 8.3.0] config file: /opt/mailman/mm/mailman.cfg db url: postgres://mailman:5DqTHnv8hUQSdd@localhost/mailman devmode: DISABLED REST root url: http://localhost:8001/3.1/ REST credentials: restadmin:restpass
Should I create a new config file at /etc/mailman3/mailman.cfg ?
You can, but the easiest thing is just replace the line
Environment="MAILMAN_CONFIG_FILE=/etc/mailman3/mailman.cfg"
in /etc/systemd/system/mailman3.service with
Environment="MAILMAN_CONFIG_FILE=/opt/mailman/mm/mailman.cfg"
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/ NYAIOPZ3PLQCPT3QPLLRKMOUY52UORBM/
This message sent to csa@web-analysts.net

On 2/12/25 15:39, Christian via Mailman-users wrote:
I followed instructions provided here. Well, I rebooted the server and I'm getting the same error again at the web page of
"Mailman REST API not available. Please start Mailman core."
I again found locks in /opt/mailman/mm/var/locks . Once I removed them I could start mailman.
Perhaps I made a boo boo. I want mailman to start without locks upon reboot.
If Mailman is properly shut down, it shouldn't leave locks.
How did you reboot? If your /etc/systemd/system/mailman3.service file
contains an appropriate ExecStop, reboot via a reboot
or shutdown -r
should stop Mailman appropriately.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

How can I resolve this error please? Running GNU Mailman Core version 3.3.5, API version 3.1, Python Version 3.7.3, on Debian 4.19.316-1
Internal Server Error: /archives/
Report at /archives/ Internal Server Error: /archives/
Request Method: GET Request URL: https://lists.ccalternatives.org/archives/?sort=active%22 Django Version: 3.2.15 Python Executable: /opt/mailman/mm/venv/bin/python Python Version: 3.7.3 Python Path: ['/opt/mailman/mm', '/opt/mailman/mm/', '/opt/mailman/mm/bin', '/usr/lib/python37.zip', '/usr/lib/python3.7', '/usr/lib/python3.7/lib-dynload', '/opt/mailman/mm/venv/lib/python3.7/site-packages'] Server time: Tue, 22 Apr 2025 03:34:51 -0700 Installed Applications: ('hyperkitty', 'postorius', 'django_mailman3', 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.messages', 'django.contrib.staticfiles', 'rest_framework', 'django_gravatar', 'compressor', 'haystack', 'django_extensions', 'django_q', 'allauth', 'allauth.account', 'allauth.socialaccount') Installed Middleware: ('django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.middleware.locale.LocaleMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'django.middleware.security.SecurityMiddleware', 'django_mailman3.middleware.TimezoneMiddleware', 'postorius.middleware.PostoriusMiddleware')
Traceback (most recent call last): None
Request information: USER: AnonymousUser
GET: sort = 'active"'
POST: No POST data
FILES: No FILES data
COOKIES: No cookie data
META: HTTP_ACCEPT = '*/*' HTTP_ACCEPT_ENCODING = 'gzip, br, deflate' HTTP_CONNECTION = 'close' HTTP_FROM = 'gptbot(at)openai.com' HTTP_HOST = '127.0.0.1:8000' HTTP_USER_AGENT = 'Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.2; +https://openai.com/gptbot)' HTTP_X_FORWARDED_FOR = '20.171.207.133' HTTP_X_FORWARDED_HOST = 'lists.ccalternatives.org' HTTP_X_FORWARDED_PROTO = 'https' HTTP_X_FORWARDED_SERVER = 'lists.ccalternatives.org' HTTP_X_OPENAI_HOST_HASH = '910456030' PATH_INFO = '/archives/' QUERY_STRING = 'sort=active%22' RAW_URI = '/archives/?sort=active%22' REMOTE_ADDR = '127.0.0.1' REMOTE_PORT = '33220' REQUEST_METHOD = 'GET' SCRIPT_NAME = '' SERVER_NAME = '127.0.0.1' SERVER_PORT = '8000' SERVER_PROTOCOL = 'HTTP/1.0' SERVER_SOFTWARE = 'gunicorn/20.0.4' gunicorn.socket = <socket.socket fd=4, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 8000), raddr=('127.0.0.1', 33220)> wsgi.errors = <gunicorn.http.wsgi.WSGIErrorsWrapper object at 0x7f00da285278> wsgi.file_wrapper = <class 'gunicorn.http.wsgi.FileWrapper'> wsgi.input = <gunicorn.http.body.Body object at 0x7f00da285a20> wsgi.input_terminated = True wsgi.multiprocess = True wsgi.multithread = False wsgi.run_once = False wsgi.url_scheme = 'https' wsgi.version = '(1, 0)'
Settings: Using settings module settings ABSOLUTE_URL_OVERRIDES = {} ACCOUNT_AUTHENTICATION_METHOD = 'username_email' ACCOUNT_DEFAULT_HTTP_PROTOCOL = 'https' ACCOUNT_EMAIL_REQUIRED = True ACCOUNT_EMAIL_VERIFICATION = 'mandatory' ACCOUNT_UNIQUE_EMAIL = True ADMINS = "(('Mailman Admin', 'csa@web-analysts.net'),)" ALLOWED_HOSTS = ['localhost', '127.0.0.1', 'lists.ccalternatives.org', '192.46.218.224', 'zarathustra.ccalternatives.org', '192.168.0.1'] APPEND_SLASH = True AUTHENTICATION_BACKENDS = "('django.contrib.auth.backends.ModelBackend', 'allauth.account.auth_backends.AuthenticationBackend')" AUTH_PASSWORD_VALIDATORS = '********************' AUTH_USER_MODEL = 'auth.User' BASE_DIR = '/opt/mailman/mm' BROWSERID_AUDIENCES = ['http://localhost', 'http://localhost:8000', 'http://127.0.0.1:8000', 'http://lists.ccalternatives.org', 'https://localhost', 'https://localhost:8000', 'https://127.0.0.1:8000', 'https://lists.ccalternatives.org'] CACHES = {'default': {'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache', 'LOCATION': '127.0.0.1:11211'}} CACHE_MIDDLEWARE_ALIAS = 'default' CACHE_MIDDLEWARE_KEY_PREFIX = '********************' CACHE_MIDDLEWARE_SECONDS = 600 COMPRESSORS = {'css': 'compressor.css.CssCompressor', 'js': 'compressor.js.JsCompressor'} COMPRESS_CACHEABLE_PRECOMPILERS = '()' COMPRESS_CACHE_BACKEND = 'default' COMPRESS_CACHE_KEY_FUNCTION = '********************' COMPRESS_CLEAN_CSS_ARGUMENTS = '' COMPRESS_CLEAN_CSS_BINARY = 'cleancss' COMPRESS_CLOSURE_COMPILER_ARGUMENTS = '' COMPRESS_CLOSURE_COMPILER_BINARY = 'java -jar compiler.jar' COMPRESS_CSS_HASHING_METHOD = 'mtime' COMPRESS_DATA_URI_MAX_SIZE = 1024 COMPRESS_DEBUG_TOGGLE = None COMPRESS_ENABLED = True COMPRESS_FILTERS = {'css': ['compressor.filters.css_default.CssAbsoluteFilter'], 'js': ['compressor.filters.jsmin.JSMinFilter']} COMPRESS_JINJA2_GET_ENVIRONMENT = <function CompressorConf.JINJA2_GET_ENVIRONMENT at 0x7f00e0e8d620> COMPRESS_MINT_DELAY = 30 COMPRESS_MTIME_DELAY = 10 COMPRESS_OFFLINE = True COMPRESS_OFFLINE_CONTEXT = {'STATIC_URL': '/static/'} COMPRESS_OFFLINE_MANIFEST = 'manifest.json' COMPRESS_OFFLINE_TIMEOUT = 31536000 COMPRESS_OUTPUT_DIR = 'CACHE' COMPRESS_PARSER = 'compressor.parser.AutoSelectParser' COMPRESS_PRECOMPILERS = "(('text/x-scss', 'sass -t compressed {infile} {outfile}'), ('text/x-sass', 'sass -t compressed {infile} {outfile}'))" COMPRESS_REBUILD_TIMEOUT = 2592000 COMPRESS_ROOT = '/opt/mailman/mm/static' COMPRESS_STORAGE = 'compressor.storage.CompressorFileStorage' COMPRESS_TEMPLATE_FILTER_CONTEXT = {'STATIC_URL': '/static/'} COMPRESS_URL = '/static/' COMPRESS_URL_PLACEHOLDER = '/__compressor_url_placeholder__/' COMPRESS_VERBOSE = False COMPRESS_YUGLIFY_BINARY = 'yuglify' COMPRESS_YUGLIFY_CSS_ARGUMENTS = '--terminal' COMPRESS_YUGLIFY_JS_ARGUMENTS = '--terminal' COMPRESS_YUI_BINARY = 'java -jar yuicompressor.jar' COMPRESS_YUI_CSS_ARGUMENTS = '' COMPRESS_YUI_JS_ARGUMENTS = '' CSRF_COOKIE_AGE = 31449600 CSRF_COOKIE_DOMAIN = None CSRF_COOKIE_HTTPONLY = False CSRF_COOKIE_NAME = 'csrftoken' CSRF_COOKIE_PATH = '/' CSRF_COOKIE_SAMESITE = 'Lax' CSRF_COOKIE_SECURE = False CSRF_FAILURE_VIEW = 'django.views.csrf.csrf_failure' CSRF_HEADER_NAME = 'HTTP_X_CSRFTOKEN' CSRF_TRUSTED_ORIGINS = [] CSRF_USE_SESSIONS = False DATABASES = {'default': {'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': 'mailman', 'USER': 'mailman', 'PASSWORD': '********************', 'HOST': '127.0.0.1', 'PORT': '', 'ATOMIC_REQUESTS': False, 'AUTOCOMMIT': True, 'CONN_MAX_AGE': 0, 'OPTIONS': {}, 'TIME_ZONE': None, 'TEST': {'CHARSET': None, 'COLLATION': None, 'MIGRATE': True, 'MIRROR': None, 'NAME': None}}} DATABASE_ROUTERS = [] DATA_UPLOAD_MAX_MEMORY_SIZE = 2621440 DATA_UPLOAD_MAX_NUMBER_FIELDS = 1000 DATETIME_FORMAT = 'N j, Y, P' DATETIME_INPUT_FORMATS = ['%Y-%m-%d %H:%M:%S', '%Y-%m-%d %H:%M:%S.%f', '%Y-%m-%d %H:%M', '%m/%d/%Y %H:%M:%S', '%m/%d/%Y %H:%M:%S.%f', '%m/%d/%Y %H:%M', '%m/%d/%y %H:%M:%S', '%m/%d/%y %H:%M:%S.%f', '%m/%d/%y %H:%M'] DATE_FORMAT = 'N j, Y' DATE_INPUT_FORMATS = ['%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', '%b %d %Y', '%b %d, %Y', '%d %b %Y', '%d %b, %Y', '%B %d %Y', '%B %d, %Y', '%d %B %Y', '%d %B, %Y'] DEBUG = False DEBUG_PROPAGATE_EXCEPTIONS = False DECIMAL_SEPARATOR = '.' DEFAULT_AUTO_FIELD = 'django.db.models.AutoField' DEFAULT_CHARSET = 'utf-8' DEFAULT_EXCEPTION_REPORTER = 'django.views.debug.ExceptionReporter' DEFAULT_EXCEPTION_REPORTER_FILTER = 'django.views.debug.SafeExceptionReporterFilter' DEFAULT_FILE_STORAGE = 'django.core.files.storage.FileSystemStorage' DEFAULT_FROM_EMAIL = 'noreply@lists.ccalternatives.org' DEFAULT_HASHING_ALGORITHM = 'sha256' DEFAULT_INDEX_TABLESPACE = '' DEFAULT_TABLESPACE = '' DISALLOWED_USER_AGENTS = [] EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend' EMAIL_CONFIRMATION_FROM = 'postmaster@lists.ccalternatives.org' EMAIL_HOST = 'localhost' EMAIL_HOST_PASSWORD = '********************' EMAIL_HOST_USER = '' EMAIL_PORT = 25 EMAIL_SSL_CERTFILE = None EMAIL_SSL_KEYFILE = '********************' EMAIL_SUBJECT_PREFIX = '[Django] ' EMAIL_TIMEOUT = None EMAIL_USE_LOCALTIME = False EMAIL_USE_SSL = False EMAIL_USE_TLS = False FILE_UPLOAD_DIRECTORY_PERMISSIONS = None FILE_UPLOAD_HANDLERS = ['django.core.files.uploadhandler.MemoryFileUploadHandler', 'django.core.files.uploadhandler.TemporaryFileUploadHandler'] FILE_UPLOAD_MAX_MEMORY_SIZE = 2621440 FILE_UPLOAD_PERMISSIONS = 420 FILE_UPLOAD_TEMP_DIR = None FILTER_VHOST = False FIRST_DAY_OF_WEEK = 0 FIXTURE_DIRS = [] FORCE_SCRIPT_NAME = None FORMAT_MODULE_PATH = None FORM_RENDERER = 'django.forms.renderers.DjangoTemplates' HAYSTACK_CONNECTIONS = {'default': {'ENGINE': 'haystack.backends.whoosh_backend.WhooshEngine', 'PATH': '/opt/mailman/mm/fulltext_index'}} HYPERKITTY_DISABLE_SINGLETON_TASKS = True IGNORABLE_404_URLS = [] INSTALLED_APPS = "('hyperkitty', 'postorius', 'django_mailman3', 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.messages', 'django.contrib.staticfiles', 'rest_framework', 'django_gravatar', 'compressor', 'haystack', 'django_extensions', 'django_q', 'allauth', 'allauth.account', 'allauth.socialaccount')" INTERNAL_IPS = [] LANGUAGES = [('af', 'Afrikaans'), ('ar', 'Arabic'), ('ar-dz', 'Algerian Arabic'), ('ast', 'Asturian'), ('az', 'Azerbaijani'), ('bg', 'Bulgarian'), ('be', 'Belarusian'), ('bn', 'Bengali'), ('br', 'Breton'), ('bs', 'Bosnian'), ('ca', 'Catalan'), ('cs', 'Czech'), ('cy', 'Welsh'), ('da', 'Danish'), ('de', 'German'), ('dsb', 'Lower Sorbian'), ('el', 'Greek'), ('en', 'English'), ('en-au', 'Australian English'), ('en-gb', 'British English'), ('eo', 'Esperanto'), ('es', 'Spanish'), ('es-ar', 'Argentinian Spanish'), ('es-co', 'Colombian Spanish'), ('es-mx', 'Mexican Spanish'), ('es-ni', 'Nicaraguan Spanish'), ('es-ve', 'Venezuelan Spanish'), ('et', 'Estonian'), ('eu', 'Basque'), ('fa', 'Persian'), ('fi', 'Finnish'), ('fr', 'French'), ('fy', 'Frisian'), ('ga', 'Irish'), ('gd', 'Scottish Gaelic'), ('gl', 'Galician'), ('he', 'Hebrew'), ('hi', 'Hindi'), ('hr', 'Croatian'), ('hsb', 'Upper Sorbian'), ('hu', 'Hungarian'), ('hy', 'Armenian'), ('ia', 'Interlingua'), ('id', 'Indonesian'), ('ig', 'Igbo'), ('io', 'Ido'), ('is', 'Icelandic'), ('it', 'Italian'), ('ja', 'Japanese'), ('ka', 'Georgian'), ('kab', 'Kabyle'), ('kk', 'Kazakh'), ('km', 'Khmer'), ('kn', 'Kannada'), ('ko', 'Korean'), ('ky', 'Kyrgyz'), ('lb', 'Luxembourgish'), ('lt', 'Lithuanian'), ('lv', 'Latvian'), ('mk', 'Macedonian'), ('ml', 'Malayalam'), ('mn', 'Mongolian'), ('mr', 'Marathi'), ('my', 'Burmese'), ('nb', 'Norwegian Bokmål'), ('ne', 'Nepali'), ('nl', 'Dutch'), ('nn', 'Norwegian Nynorsk'), ('os', 'Ossetic'), ('pa', 'Punjabi'), ('pl', 'Polish'), ('pt', 'Portuguese'), ('pt-br', 'Brazilian Portuguese'), ('ro', 'Romanian'), ('ru', 'Russian'), ('sk', 'Slovak'), ('sl', 'Slovenian'), ('sq', 'Albanian'), ('sr', 'Serbian'), ('sr-latn', 'Serbian Latin'), ('sv', 'Swedish'), ('sw', 'Swahili'), ('ta', 'Tamil'), ('te', 'Telugu'), ('tg', 'Tajik'), ('th', 'Thai'), ('tk', 'Turkmen'), ('tr', 'Turkish'), ('tt', 'Tatar'), ('udm', 'Udmurt'), ('uk', 'Ukrainian'), ('ur', 'Urdu'), ('uz', 'Uzbek'), ('vi', 'Vietnamese'), ('zh-hans', 'Simplified Chinese'), ('zh-hant', 'Traditional Chinese')] LANGUAGES_BIDI = ['he', 'ar', 'ar-dz', 'fa', 'ur'] LANGUAGE_CODE = 'en-us' LANGUAGE_COOKIE_AGE = None LANGUAGE_COOKIE_DOMAIN = None LANGUAGE_COOKIE_HTTPONLY = False LANGUAGE_COOKIE_NAME = 'django_language' LANGUAGE_COOKIE_PATH = '/' LANGUAGE_COOKIE_SAMESITE = None LANGUAGE_COOKIE_SECURE = False LOCALE_PATHS = [] LOGGING = {'version': 1, 'disable_existing_loggers': False, 'filters': {'require_debug_false': {'()': 'django.utils.log.RequireDebugFalse'}}, 'handlers': {'mail_admins': {'level': 'ERROR', 'filters': ['require_debug_false'], 'class': 'django.utils.log.AdminEmailHandler'}, 'file': {'level': 'INFO', 'class': 'logging.handlers.WatchedFileHandler', 'filename': '/opt/mailman/mm/logs/mailmansuite.log', 'formatter': 'verbose'}, 'console': {'class': 'logging.StreamHandler', 'formatter': 'simple'}}, 'loggers': {'django.request': {'handlers': ['mail_admins', 'file'], 'level': 'ERROR', 'propagate': True}, 'django': {'handlers': ['file'], 'level': 'ERROR', 'propagate': True}, 'hyperkitty': {'handlers': ['file'], 'level': 'DEBUG', 'propagate': True}, 'postorius': {'handlers': ['console', 'file'], 'level': 'INFO'}}, 'formatters': {'verbose': {'format': '%(levelname)s %(asctime)s %(process)d %(name)s %(message)s'}, 'simple': {'format': '%(levelname)s %(message)s'}}} LOGGING_CONFIG = 'logging.config.dictConfig' LOGIN_REDIRECT_URL = 'list_index' LOGIN_URL = 'account_login' LOGOUT_REDIRECT_URL = None LOGOUT_URL = 'account_logout' MAILMAN_ARCHIVER_FROM = "('127.0.0.1', '::1', '::ffff:127.0.0.1', '192.46.218.224')" MAILMAN_ARCHIVER_KEY = '********************' MAILMAN_REST_API_PASS = '********************' MAILMAN_REST_API_URL = '********************' MAILMAN_REST_API_USER = '********************' MANAGERS = [] MEDIA_ROOT = '' MEDIA_URL = '/' MESSAGE_STORAGE = 'django.contrib.messages.storage.fallback.FallbackStorage' MESSAGE_TAGS = {40: 'danger'} MIDDLEWARE = "('django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.middleware.locale.LocaleMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'django.middleware.security.SecurityMiddleware', 'django_mailman3.middleware.TimezoneMiddleware', 'postorius.middleware.PostoriusMiddleware')" MIGRATION_MODULES = {} MONTH_DAY_FORMAT = 'F j' NUMBER_GROUPING = 0 PASSWORD_HASHERS = '********************' PASSWORD_RESET_TIMEOUT = '********************' PASSWORD_RESET_TIMEOUT_DAYS = '********************' POSTORIUS_TEMPLATE_BASE_URL = 'https://lists.ccalternatives.org' PREPEND_WWW = False Q_CLUSTER = {'timeout': 300, 'save_limit': 100, 'orm': 'default'} ROOT_URLCONF = 'urls' SECRET_KEY = '********************' SECURE_BROWSER_XSS_FILTER = False SECURE_CONTENT_TYPE_NOSNIFF = True SECURE_HSTS_INCLUDE_SUBDOMAINS = False SECURE_HSTS_PRELOAD = False SECURE_HSTS_SECONDS = 0 SECURE_PROXY_SSL_HEADER = "('HTTP_X_FORWARDED_PROTO', 'https')" SECURE_REDIRECT_EXEMPT = [] SECURE_REFERRER_POLICY = 'same-origin' SECURE_SSL_HOST = None SECURE_SSL_REDIRECT = False SERVER_EMAIL = 'noreply@lists.ccalternatives.org' SESSION_CACHE_ALIAS = 'default' SESSION_COOKIE_AGE = 1209600 SESSION_COOKIE_DOMAIN = None SESSION_COOKIE_HTTPONLY = True SESSION_COOKIE_NAME = 'sessionid' SESSION_COOKIE_PATH = '/' SESSION_COOKIE_SAMESITE = 'Lax' SESSION_COOKIE_SECURE = False SESSION_ENGINE = 'django.contrib.sessions.backends.db' SESSION_EXPIRE_AT_BROWSER_CLOSE = False SESSION_FILE_PATH = None SESSION_SAVE_EVERY_REQUEST = False SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer' SETTINGS_MODULE = 'settings' SHORT_DATETIME_FORMAT = 'm/d/Y P' SHORT_DATE_FORMAT = 'm/d/Y' SIGNING_BACKEND = 'django.core.signing.TimestampSigner' SILENCED_SYSTEM_CHECKS = [] SITE_ID = 3 SOCIALACCOUNT_PROVIDERS = {'google': {'SCOPE': ['profile', 'email'], 'AUTH_PARAMS': {'access_type': 'online'}}, 'gitlab': {'SCOPE': ['read_user']}} STATICFILES_DIRS = '()' STATICFILES_FINDERS = "('django.contrib.staticfiles.finders.FileSystemFinder', 'django.contrib.staticfiles.finders.AppDirectoriesFinder', 'compressor.finders.CompressorFinder')" STATICFILES_STORAGE = 'django.contrib.staticfiles.storage.StaticFilesStorage' STATIC_ROOT = '/opt/mailman/mm/static' STATIC_URL = '/static/' TEMPLATES = [{'BACKEND': 'django.template.backends.django.DjangoTemplates', 'DIRS': [], 'APP_DIRS': True, 'OPTIONS': {'context_processors': ['django.template.context_processors.debug', 'django.template.context_processors.i18n', 'django.template.context_processors.media', 'django.template.context_processors.static', 'django.template.context_processors.tz', 'django.template.context_processors.csrf', 'django.template.context_processors.request', 'django.contrib.auth.context_processors.auth', 'django.contrib.messages.context_processors.messages', 'django_mailman3.context_processors.common', 'hyperkitty.context_processors.common', 'postorius.context_processors.postorius']}}] TEST_NON_SERIALIZED_APPS = [] TEST_RUNNER = 'django.test.runner.DiscoverRunner' THOUSAND_SEPARATOR = ',' TIME_FORMAT = 'P' TIME_INPUT_FORMATS = ['%H:%M:%S', '%H:%M:%S.%f', '%H:%M'] TIME_ZONE = 'America/Los_Angeles' USE_I18N = True USE_L10N = True USE_SSL = True USE_THOUSAND_SEPARATOR = False USE_TZ = True USE_X_FORWARDED_HOST = True USE_X_FORWARDED_PORT = False WSGI_APPLICATION = 'wsgi.application' X_FRAME_OPTIONS = 'DENY' YEAR_MONTH_FORMAT = 'F Y'

This reply will probably not help you, but... when I encountered a similar error, restarting the server-side Mailman services solved it, and it was a one time issue that didn't recur.
Albeit if it happens again after a restart, or even better, you find a reliable way to reproduce it, I suggest to wait for the response of the pros/devs, as I'm also a new user of Mailman 3.

Christian wrote:
Request Method: GET Request URL: https://lists.ccalternatives.org/archives/?sort=active%22 Request information: USER: AnonymousUser GET: sort = 'active"' QUERY_STRING = 'sort=active%22' RAW_URI = '/archives/?sort=active%22' HTTP_FROM = 'gptbot(at)openai.com' HTTP_HOST = '127.0.0.1:8000' HTTP_USER_AGENT = 'Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.2; +https://openai.com/gptbot)'
At the end of the provided query string was a double quote, which is an invalid sort mode parameter and produced the error. The %22 is a URL encoded double quote.
If the HTTP_FROM and HTTP_USER_AGENT are legitimate, this this appears to be an OpenAI crawler bot, specifically the GPTBot.
participants (10)
-
'Ron / BCLUG'
-
Christian
-
German Rodriguez
-
Lichtinger, Bernhard
-
Mark Sapiro
-
Markus Grandpré
-
MegaBrutal
-
Odhiambo Washington
-
Ron / BCLUG
-
Stephen J. Turnbull