May 2025 - Mailman-users - lists.mailman3.org

Heads up: settings.ACCOUNT_AUTHENTICATION_METHOD is deprecated
by Andreas Vetter Aug. 1, 2025

Aug. 1, 2025

Hello, I have a venv installation of: mailman postorius django-mailman3 hyperkitty mailman-web I just did a pip install -U --upgrade-strategy eager When running mailman-web runjobs -l I get the following Warning: System check identified some issues: WARNINGS: ?: settings.ACCOUNT_AUTHENTICATION_METHOD is deprecated, use: settings.ACCOUNT_LOGIN_METHODS = {'email', 'username'} I guess this is from allauth (version django-allauth-65.4.1). Changing ACCOUNT_AUTHENTICATION_METHOD to ACCOUNT_LOGIN_METHODS in /etc/mailman3/settings.py is not enough. One has to edit venv/lib/python3.11/site-packages/mailman_web/settings/mailman.py -- Mit freundlichen Gruessen, Andreas Vetter

4 9

Upgrading other python packages than the mailman ones in a venv results in dependency conflicts
by Ulf R. July 29, 2025

July 29, 2025

Hello, I know this should be the way to upgrade: https://docs.mailman3.org/en/latest/upgrade-guide.html I have 3.3.10 installed. I saw that some python packages are outdated an tried this which install all outdated packages in a row: pip list --outdated --format=json | jq '.[].name' | xargs -n1 pip install -U One outdated package was django and this part happened: ------------------------------- vDownloading Django-5.1.4-py3-none-any.whl (8.3 MB) Installing collected packages: Django Attempting uninstall: Django Found existing installation: Django 4.2.16 Uninstalling Django-4.2.16: Successfully uninstalled Django-4.2.16 ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts. hyperkitty 1.3.12 requires django<5.1,>=4.2, but you have django 5.1.4 which is incompatible. mailman-web 0.0.9 requires django<4.3,>=4.0, but you have django 5.1.4 which is incompatible. postorius 1.3.13 requires django<5.1,>=4.2, but you have django 5.1.4 which is incompatible. django-mailman3 1.3.15 requires django<5.1,>=4.2, but you have django 5.1.4 which is incompatible. Successfully installed Django-5.1.4 ------------------------------- So I made a roll back. Is this really the only secure way to update the venv?: pip install -U mailman postorius django-mailman3 hyperkitty mailman-web May be yes and I have to ignore the rest? ;-) Thank you und regards

5 6

Enforcing SSO and subscription options
by dlb-ml＠anl.gov July 21, 2025

July 21, 2025

Contrary to the messages I found in the archive, rather trying to delete or remove the social login portion of the sign in page, I'm looking to see if there's any way to isolate the third-party login section and prevent local account sign in and sign up. This way, we can ensure that the people within our organization are using a stronger auth method that prioritizes MFA, rather than just username/password. To do this, our plan is to block signups using "ACCOUNT_ADAPTER = 'django_mailman3.views.user_adapter.DisableSignupAdapter'" and to remove the portions of the login template such that the username/password/forgot password fields are removed, leaving just the button to our SSO instance. I'm anticipating that this should be sufficient to block username/password sign ins, and is resistant to page manipulation due to CSRF tokens, but I wanted to ask to see if there was a better way, like an official configuration (which I have not found yet). I did see that there is the SOCALACCOUNT_ONLY option, as provided by allauth (https://docs.allauth.org/en/latest/socialaccount/configuration.html) but that broke any attempt to display the sign in page, and I'm assuming is not supported with the current version of MM3. Is my plan to modify the templates viable? Additionally, because external users would not have access to their own dashboards within the web UI, and since we are planning on disabling anonymous subscriptions with "SHOW_ANONYMOUS_SUBSCRIBE_FORM=False", the only two viable ways to subscribe to a list for them would be: 1) Send a request directly to the list owner or a superadmin to subscribe/unsubscribe the address 2) Allow email commands to subcribe/unsubscribe users (i.e. $LISTNAME-join@$DOMAIN) Given the discussions on disabling the anonymous subscription form, are the email commands a less spam-susceptible solution or are they just as vulnerable as the form? Thanks

4 7

redirecting -bounces replies
by Hirayama, Pat June 26, 2025

June 26, 2025

Greetings, Is it possible to redirect the -bounces alias of a specific list so that it also goes to a person, in addition to the normal bounces processing for that list? In Mailman2, I know that I could do that by modifying the aliases table. I've been poking around in Mailman3, but haven't managed to figure out which container I need to be looking at. And rather than keep spinning, I figured that I'd ask the hive mind, since I'm sure one of you can quickly point me to the correct location. Thanks! -p Pat Hirayama Pronouns: he/him/his Systems Engineer IT | Systems Engineering - Infrastructure Fred Hutch Cancer Center O 206.667.4856 phirayam(a)fredhutch.org<mailto:phirayam@fredhutch.org>

5 14

Django-allauth compatibility (ACCOUNT_AUTHENTICATION_METHOD and ACCOUNT_EMAIL_REQUIRED)
by Jan Eden June 17, 2025

June 17, 2025

Hi, after installing Mailman 3 in a new virtual environment, I ran into the compatibility issues with django-allauth discussed by Andreas Vetter and Mark Sapira on this list in February[1] and in March[2] – WARNINGS: settings.ACCOUNT_AUTHENTICATION_METHOD is deprecated, use: settings.ACCOUNT_LOGIN_METHODS = {'email', 'username'} settings.ACCOUNT_EMAIL_REQUIRED is deprecated, use: settings.ACCOUNT_SIGNUP_FIELDS = ['email*', 'username*', 'password1*', 'password2*'] – and solved them with the additions to /etc/mailman3/settings.py suggested by Mark: del ACCOUNT_AUTHENTICATION_METHOD ACCOUNT_LOGIN_METHODS = {'email', 'username'} del ACCOUNT_EMAIL_REQUIRED ACCOUNT_SIGNUP_FIELDS = ['email*', 'username*', 'password1*', 'password2*'] In the second list thread, Mark linked to the current (patched) version of mailman-web's mailman.py[3], which addresses the deprecation of ACCOUNT_AUTHENTICATION_METHOD, but not of ACCOUNT_EMAIL_REQUIRED. Is there any reason why the patch fixes only one of the two issues? - Jan [1] https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… [2] https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… [3] https://gitlab.com/mailman/mailman-web/-/blob/c8b9aef1704b75b1cb6d0c925855a…

4 5

"this held message has been lost"
by Ethan Furman June 10, 2025

June 10, 2025

I have now seen this message on two different occasions. Any ideas on what is happening? Happy to provide additional information if I am told what is needed (and how to get it -- I'm a web moderator for the list without access to the machine it runs on). :) -- ~Ethan~

3 4

Recently active discussions - Hyperkitty
by Sam Darwin June 5, 2025

June 5, 2025

Hi, Sometimes not sure if it's preferable to open a gitlab issue, or chat on the mailing list. I have run a large archive import into mailman3/hyperkitty. After that's done, waited a day, for scheduled cron jobs to complete. In "All Threads", all the email archives are present. The import worked. In "RECENTLY ACTIVE DISCUSSIONS" on the main page, it says: RECENTLY ACTIVE DISCUSSIONS No discussions this month (yet). Nothing there. That means if I direct users to visit the site, the page, it appears empty. That's too bad. :-) It should display recent emails. What would affect this feature during an archive import? Is it a problem with the import script itself, or with a scheduled cron job, or something else? Would you expect "Recently active discussions" be empty when very recent archives do exist? Thanks, Sam

3 8

CPU usage when idle
by roughnecks May 29, 2025

May 29, 2025

Hello, if you look at this graph you'll notice how my VPS "reacted" after mailman3 install. It's a Debian stable host, and I installed packages via apt. I mean, isn't this a bit too much for a software that is idle, because no lists are currently in use? RED is my VPS, the other colors are other machines. Thanks -- roughnecks ___________________________________________ Mailman's content filtering has removed the following MIME parts from this message. Content-Type: image/jpeg Name: raw (1).jpg

4 7

Unable to update templates
by Mark May 29, 2025

May 29, 2025

Hi, I'm unable to update the custom welcome template (list:user:notice:welcome) after it's initial creation. When the custom welcome template is created (in Postorius), and a user then subscribed by the list-owner (using mass subscribe), the welcome message is received as expected. However when I update the template, the databases are updated correctly but the Welcome message is still sent with the old template content. mailman.templates mailmanweb.postorius_emailtemplate Additionally, if I delete the template and create a new one the old content still gets sent. I cannot find where this content is written or is being cached. Any clues on tracking this bugbear down gratefully received. Regards, Mark $ mailman info GNU Mailman 3.3.9 (Tom Sawyer) Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] config file: /etc/mailman3/mailman.cfg db url: postgresql://******:******@localhost/mailman devmode: DISABLED REST root url: http://localhost:8001/3.1/ -- Installed with venv. ===================== Query to DB - mailman ===================== SELECT URI FROM TEMPLATE WHERE NAME = 'list:user:notice:welcome' AND context = 'testlist.example.com'; ====================== Result (all directories and file owned by 'mailman' with '765' permissions) ====================== file:///templates/list/testlist.example.com/list:user:notice:welcome ====================== Content of above Welcome file ====================== This is the second test Welcome message. ====================== Text of the welcome message actually received. (It's the content of the first custom template.) ====================== This is the first test message to Welcome new members.

2 7

Re: MM broken after proxy migration (Nginx -> Caddy)
by Andreas Kemper May 28, 2025

May 28, 2025

Hi Stephen, thanks for the comprehensive explanations and sorry for initially not answering to the list (I expected this to be the default behaviour). Afterall it turned out that my mailman.db was somehow broken, even though I couldn't find any fishy / strange things in Postorius. Since anyhow just a few lists are hosted on the server and subscriptions for most of them being managed fron another program, I decided to remove MM3 completely and start with a fresh configuration. BR Andreas Am 28.05.2025 um 18:16 schrieb Stephen J. Turnbull: > Hi Andreas > > Andreas Kemper writes: > > > thanks for the quick response. > > Please reply to list (personal mail doesn't get read any faster) or to > all (I don't mind getting the duplicate). The odds are quite good > that somebody else will be able to reply before I do (I live in Japan, > normally I wouldn't be up now ;-). > > > Agree there, even though I haven't found any "settings.py" file in > > my Debian 12 installation yet. > > Normally the override settings.py is in /etc/mailman3/settings.py. If > you have no overrides, I don't know where Debian would put it. There > are actually several in the distribution where the highest levels are > normally in site-packages/mailman_web/settings/*.py (*not* named > "settings.py", I think they are "base.py" and "mailman.py"). Come to > think of it, I'm not sure whether Debian would put mailman and > mailman_web in site-packages or somewhere else. :-( (I'm a Debian > user since 1997, but my mission-critical applications are installed > from source.) > > > Hmm, executing > > > > sudo -u list mailman stop followed by > > sudo -u list mailman start > > > > first deletes and afterwards recreates the lock files, > > That is the expected behavior if Mailman is running normally. Are you > sure there's actually a recurring problem? Or did Mailman just crash > once, and the problem was the stale master lockfile? > > > where both of them are dated in the future, > > Also expected. I forget exactly what expiration of the lock file > triggers, but there's some regularly scheduled cleanup that happens > then. > > > plus mailman.log has a duplicate line in the end, > > It's a duplicate because the default is for there to be two processes > serving the REST API. This is configurable. See more comments at the > end. > > > even though I couldn't seen any mailman-related process (ps auxw | > > grep mailman) after stopping it. > > If the process is named by the full path to the executable, then you > will see "mailman", but if I recall correctly on Debian the Mailman > processes run under the users "list" for Mailman core, and "www-data" > for the web UIs. The various components run under different names: > master, nntp, lmtp, command, rest, etc. I forget what process names > you would see for the Django processes. > > > In doubt I will simply redirect the specific paths, mainly > > /accounts/fedora, > > That makes sense as the earlier you reject a connection the less > resources are used by your server, and the less information can leak > to an attacker. > > > small addition to my previous post. "ps auxw" shows in total three > > process for MM's rest component, i. e. > > > python3 /usr/lib/mailman3/bin/runner -C /etc/mailman3/mailman.cfg --runner=rest:0:1 > > > To serve ports 8000 and 8001, I would have expected two processes, > > but to see three of them surprises me somewhat. > > It's not uncommon for moderators to go AWOL, or for somebody to spam > the server with either posts or subscription activity, and end up with > hundreds or thousands of entries in the pending requests table. > Serving those queries can take a long timemany seconds or even time > out. Mailman core deals with it in the least complex, most robust way > imaginable: it runs more REST API server processes. (3 total by > default. One is the "master" that handles requests from the Django > apps and communication with Mailman core and starts new workers when > old ones exit or crash. Two are "workers" that actually handle a > certain number of requests then exit.) By default Mailman is > configured to use up to four when really busy, but normally there are > only two. > > Django runs only one -- it deals with concurrent requests in a > different way. > > Steve >

1 0