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

Speed up importing mailman2 lists
by t.maintz＠fz-juelich.de Feb. 24, 2025

Feb. 24, 2025

We are currently planning to migrate from mailman2 to mailman3 as a container, have around 1500 lists and would like to complete the migration ideally in a few hours. We would like to switch off mailman2 to have a defined state of the lists and import them to mailman3. The import of all lists via script takes about 3 days. Parallelizing the imports does not work due to lockings in the database. However, we cannot accept a downtime of 3 days. Does anyone have tips on how we can speed up the procedure or are there best practices for larger environments? Thanks and best regards, Thomas

4 8

clean up spambot generated accounts
by Johannes Rohr Feb. 23, 2025

Feb. 23, 2025

Dear all, I'm trying to find a way to clean up hundreds of spambot generated accounts on my system. I was pointed to this script that should be capable of doing the task: https://www.msapiro.net/scripts/clean_users.py However, it seems outdated. First, the path to the interpreter is not what I find on my mailman3 installation. It says: #! /opt/mailman/mm/venv/bin/python However, the python command is located in /opt/mailman/venv/bin/python instead, no "mm" After fixing this, the script still throws an error: (venv) mailman@ida:~$ clean_users.py Traceback (most recent call last): File "/usr/local/bin/clean_users.py", line 55, in <module> django.setup() File "/opt/mailman/venv/lib/python3.10/site-packages/django/__init__.py", line 19, in setup configure_logging(settings.LOGGING_CONFIG, settings.LOGGING) File "/opt/mailman/venv/lib/python3.10/site-packages/django/conf/__init__.py", line 102, in __getattr__ self._setup(name) File "/opt/mailman/venv/lib/python3.10/site-packages/django/conf/__init__.py", line 89, in _setup self._wrapped = Settings(settings_module) File "/opt/mailman/venv/lib/python3.10/site-packages/django/conf/__init__.py", line 217, in __init__ mod = importlib.import_module(self.SETTINGS_MODULE) File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1050, in _gcd_import File "<frozen importlib._bootstrap>", line 1027, in _find_and_load File "<frozen importlib._bootstrap>", line 1004, in _find_and_load_unlocked ModuleNotFoundError: No module named 'settings' Can somebody explain to me, why this module is not found and what I can do to fix it, if anything? Thanks a lot in advance! Johannes

2 2

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

Feb. 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

2 3

Hyperkitty performance problem
by Tobias Diekershoff Feb. 20, 2025

Feb. 20, 2025

Hey all, last week we caught some AI bots causing high LOAD on our mailman3 servers archive, that we blocked with nginx rules. I'm not sure if it is related to this incident, but we noticed this when analyzing the log files at the time. In the mailman.log hyperkitty is listed 10k times and more to archive a single mail over the time of 2h, seemingly all with the same process ID > (1186) HyperKitty archived message [...] The mailman3-web.log has matching log entries that the mail was archived > hyperkitty.views.mailman Archived message every 0.5 seconds. In the web interface to the archive, the mail is only listed once though. My suspicion is, that these archiving processes are now overloading the system, preventing a timely catching up work of the queued messages. I could not find anything in the Mailman3 nor Hyperkitty documentation to better distribute the system resources to the Mailman runner or prevent Hyperkitty to restart archiving a mail over and over again. Any hint about where to look for the reason of this is highly appreciated. Best, Tobias -- Tobias Diekershoff >>> System Hacker Free Software Foundation Europe Schönhauser Allee 6/7, 10119 Berlin, Germany | t +49-30-27595290 Registered at Amtsgericht Hamburg, VR 17030 | fsfe.org/support OpenPGP-Key ID ... 0x25FE376FF17694A1 Fingerprint ...... 23EE F484 FDF8 291C BA09 A406 25FE 376F F176 94A1

6 16

Mailman Core: REST API: Member Subscription Invitation
by Peter Knowles Feb. 20, 2025

Feb. 20, 2025

Product: Mailman Core Version: 3.3.10 When I post an "invite" to the REST API: http://localhost:8001/3.1/members Params: list_id = list.domain.tld subscriber = some(a)email.address display_name = Some Name invitation = true Should Mailman Core be attempting to send an "invitation" email to the "subscriber" address, or is this the job of the "client" calling the API? I understand the API does return "token", and "token_owner" on success, which I assume the "token" would be used for a subsequent "verification" process. I'm developing my own "frontend" for "subscribers", "moderators", "list admins", and "system admins" respectively. Sort of working through understanding what Core does and does not do itself.

2 3

REST API: potential bug
by Peter Knowles Feb. 16, 2025

Feb. 16, 2025

I'm starting to develop against the REST API and found what might be a bug in the validation process. Sending a POST request with an "empty" payload returns 201 (created): http://localhost:8001/3.1/domains Since "mail_host" should be required at minimum to create a domain, this seems like there may be a bug with the REST API. The workaround for the moment is to add validation at the application layer, but the API should really be returning a 4xx code and error respectively.

2 5

install v3.3.11
by Jose Bernal Feb. 14, 2025

Feb. 14, 2025

I'd like to install Mailman v3.3.11. Are there instructions for installing from pip? If not, is there an alternate way to install this latest version? When executing: pip install mailman==3.3.11 I get: ERROR: No matching distribution found for mailman==3.3.11 Thank you,

2 2

Re: Moderation action "None" is misleading
by Stephen J. Turnbull Feb. 13, 2025

Feb. 13, 2025

Adding mailman-users(a)mailman3.org. Technical suggestions should go to distro channels or to Mailman's issue tracker: https://gitlab.com/mailman/mailman/-/issues/1176. Further discussion of technical details is best done there. Thomas Krichel writes: > Stephen J. Turnbull writes > > Debian has traditionally been quite slow to update Mailman, > > And now it has the addition issue that Debian testing python > standard it 3.13, so the nntplib is no longer supported. > Thus the current Mailman debian testing appears broken. That's Debian's problem, as we currently don't support Python 3.13, although of course we intend to. This is the only issue that came up in a quick search of Mailman's issue tracker for Python 3.13 (but I did not check the other subprojects such as Postorius). I conclude that not a lot of work has been done on supporting Python 3.13 (rather than the optimistic "there's nothing to be done"). From Mailman's point of view, users have two excellent options for the forseeable future: (1) don't gateway list <-> newsgroups (2) install Mailman into a Python 3.9--3.12 virtual environment. I'm sympathetic to the needs of the Debian developers, and at this point for 99% of software it's perfectly reasonable to aim to use 3.13 in the next Debian release. Unfortunately for Mailman users on Debian hosts that's not high on our list of priorities since we recommend a virtual environment installation in any case. At present there seem to be three ways forward for Debian packaging: 1. Remove NNTP support. (In honor of larsi, I'd rather not.) 2. Add nntplib.py from the Python 3.12 nntplib, as a stopgap until option 3 can be implemented. I can't speak for other developers but we might be willing to add it as a contrib module, especially if that might make life easier for distro packagers. It's suboptimal though since that absolutely has to be considered techical debt that will need to be paid someday. 3. Port Mailman to pynntp (that may need to be Debian packaged, too), which has seen a revival of activity and two feature releases since 2023. My inclination as a Mailman core developer is not to participate actively in development of NNTP support in Mailman for Python 3.13+ unless we see an outpouring of support from site admins. However, I would be happy to answer questions and work on Mailman-side issues that are blocking or inconvenient for the NNTP work. Mark and Abhilash would undoubtedly contribute as well, on a time-available basis. > I certainly would love to build an alternative Mailman Debian > package that would be more up-to-date, but I don't want > to do it on my own. Debian and Python are compatible free software; just take the existing package metadata, in a recent Mailman (presumably the most recent release) drop in the most recent nntplib, and change all the import statements. mailman/src/mailman/mta/nntplib.py seems like a plausible location. IWBNI you could keep all Mailmanisms out of nntplib (because of the GPL) so any bugfixes or improvements could be available to the Python community. I think you could probably be up and running VERY quickly with that approach. Of course it wouldn't just slot into the next iteration of Debian because they have stringent QA (or maybe that could go into unstable?). I'm pretty sure it would be useful right away to a whole lot of people who are willing to use a PPA. Regards, Steve

6 13

Login confusion
by Markus Grandpré Feb. 13, 2025

Feb. 13, 2025

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(a)uni-konstanz.de> and <Markus.Grandpre(a)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

8 16

Heads up: settings.ACCOUNT_AUTHENTICATION_METHOD is deprecated
by Andreas Vetter Feb. 11, 2025

Feb. 11, 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

2 5