Search results for "sapiro" - lists.mailman3.org

[MM3-users] Re: Auto discard after max_days_to_hold not working.

by Hitashi mancho

Hi Mark, As you have mentioned about implementation of "Auto discard after max_days_to_hold" in a next release. How do I install that release? I have installed mailman3 using pip in virtual environment and whenever I try to upgrade the release using pip install -U, it gives package already compiled and up to date. My Mailman version is as follows. Mailman version: GNU Mailman 3.3.10 (Tom Sawyer) Python 3.11.9 Rocky Linux 9.5 Regards, Hitachi. On Thu, May 1, 2025 at 12:51 PM Hitashi mancho <huhamails(a)gmail.com> wrote: > Thank you so much, Mark and Stephen, for the quick action and response. > Waiting for the next release. > > On Tue, Apr 29, 2025 at 10:52 AM Mark Sapiro <mark(a)msapiro.net> wrote: > >> On 4/28/25 10:55, Mark Sapiro wrote: >> > >> > `mailman import21` will import the setting, but per the above comment, >> > it doesn't yet work. The setting exists and is exposed in REST, but it >> > appears it is not actually implemented. >> >> >> This is now implemented for the next release. See >> https://gitlab.com/mailman/mailman/-/issues/1215 and >> https://gitlab.com/mailman/mailman/-/merge_requests/1346 for Mailman >> core and https://gitlab.com/mailman/postorius/-/issues/628 and >> https://gitlab.com/mailman/postorius/-/merge_requests/1001 for Postorius. >> >> -- >> Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, >> San Francisco Bay Area, California better use your sense - B. Dylan >> >> _______________________________________________ >> Mailman-users mailing list -- mailman-users(a)mailman3.org >> To unsubscribe send an email to mailman-users-leave(a)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… >> >> This message sent to huhamails(a)gmail.com >> >

7 months, 1 week

[MM3-users] Re: Mailman shell tutorial

by Mark Sapiro

On 6/10/19 6:21 PM, andrew.bernard(a)gmail.com wrote: > is there a tutorial or some examples for using the mailman shell? Is there detailed documentation on it? What documentation there is is at <https://mailman.readthedocs.io/en/latest/src/mailman/commands/docs/shell.ht…> > Anything I try to do such as the following fails: > > $ mailman shell > Welcome to the GNU Mailman shell > >>>> command('mailman shell --details') > Traceback (most recent call last): > File "<console>", line 1, in <module> > NameError: name 'command' is not defined >>>> You could just do `mailman shell --details` at a command prompt. Perhaps you saw the `command('mailman shell --details')` line in the docs at <https://mailman.readthedocs.io/en/latest/src/mailman/commands/docs/shell.ht…> in any case, that requires two things to precede it. The first is part of the doctest infrastructure and is not evident in the docs. that step is from mailman.testing.documentation import cli The second step is in the docs and is command = cli('mailman.commands.cli_withlist.shell') If you do those two steps within `mailman shell`, then the step command('mailman shell --details') will work, but as I said, this is just the same as doing `mailman shell --details` at a command prompt. Beyond that, actually doing stuff within `mailman shell` requires some knowledge of Mailman interfaces, methods and objects as well as Python. Some of this is covered throughout the documentation at <https://mailman.readthedocs.io/en/latest/> but some can only be found in the source code itself. That said, all the interfaces and a few other useful functions are imported for you in `mailman shell` interactive mode. do `dir()` to see what these are. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 10 months

[MM3-users] Re: Subscription confirmation email

by Mark Sapiro

On 3/14/26 07:19, Eric Broens via Mailman-users wrote: > While doing some tests I subscribed to a mailinglist by sending an email to > <list>-join@<domain> > > Mailman correctly emailed the confirmation request, and the mail was > accepted by my ISP. > > For some reason the confirmation mail did not arrive in my mailbox nor in my > spam folder, it seems to have been silently dropped. This is a problem, but we can't help with that. Only your ISP knows why it dropped it. > A day later, I again sent a subscription request to <list>-join@<domain>, > and I received a mail from <list>-bounces@<domain> with subject "The results > of your email commands" saying that I have a pending subscription for that > mailinglist. > > However, no confirmation link is included, nor instructions to visit the > website to confirm the subscription. > > Am I missing something in the configuration? No. The original request is pending and needs to be confirmed or discarded or time out. If you are a list admin you can go to Subscription requests -> Pending Confirmation and discard the pending request. The time out is configured as pending_request_life with a default of 3 days. > I would expect that a confirmation request is mailed again to the > subscriber. Most subscribers don't use the web interface to manage their > subscriptions. I see your concern. Currently the frustrated subscriber whose original confirmation request is lost has to contact the list owner and may not even understand that need. You could submit an RFE at <https://gitlab.com/mailman/mailman/-/issues/new> to request that the pending request response include the confirmation link. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 month, 3 weeks

[MM3-users] Re: The future is here?

by Mark Sapiro

On 1/3/21 3:47 PM, ieso(a)johnwillson.com wrote: > > Any ideas on what might cause that? More context below.. > > [uwsgi-daemons] respawning "python3 manage.py qcluster" (uid: 33 gid: 33) > Traceback (most recent call last): > File "manage.py", line 10, in <module> > execute_from_command_line(sys.argv) > File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 364, in execute_from_command_line > utility.execute() > File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 356, in execute > self.fetch_command(subcommand).run_from_argv(self.argv) > File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 206, in fetch_command > klass = load_command_class(app_name, subcommand) > File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 40, in load_command_class > module = import_module('%s.management.commands.%s' % (app_name, name)) > File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module > return _bootstrap._gcd_import(name[level:], package, level) > File "<frozen importlib._bootstrap>", line 1006, in _gcd_import > File "<frozen importlib._bootstrap>", line 983, in _find_and_load > File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked > File "<frozen importlib._bootstrap>", line 677, in _load_unlocked > File "<frozen importlib._bootstrap_external>", line 728, in exec_module > File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed > File "/usr/lib/python3/dist-packages/django_q/management/commands/qcluster.py", line 4, in <module> > from django_q.cluster import Cluster > File "/usr/lib/python3/dist-packages/django_q/cluster.py", line 24, in <module> > from django_q import tasks > File "/usr/lib/python3/dist-packages/django_q/tasks.py", line 12, in <module> > from django_q.cluster import worker, monitor > ImportError: cannot import name 'worker' from 'django_q.cluster' (/usr/lib/python3/dist-packages/django_q/cluster.py) This is a django_q issue. Apparently <https://github.com/Koed00/django-q/issues/331>, fixed by <https://github.com/Koed00/django-q/pull/356> -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 4 months

[MM3-users] Re: disabled users

by Mark Sapiro

On 10/25/23 10:44 AM, Stephen J. Turnbull wrote: > Servizio Informatico U.I.C.I. Sezione territoriale di Brescia writes: > > > Wher I find the disabled user of a mailing list and wher I can > > reactivate them? > > If you are the list owner or superuser, when you visit the list's > information page there will be a horizontal menu across the top. One > of the entries is Users. Click to open the dropdown menu and choose > Members. There doesn't seem to be an explicit notation for disabled > users, but if the entry in the far right column "bounce score" is > None, the member may be disabled. I don't think this is correct. Members with delivery disabled by bounce will normally show 0 rather than None for bounce score. If you have shell access to the server as the Mailman user, you can run this shell interaction to find members with delivery disabled by bounce. ``` $ mm/bin/mailman shell -l test(a)example.com Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. The variable 'm' is the test(a)example.com mailing list >>> for member in m.members.members: ... if member.delivery_status == DeliveryStatus.by_bounces: ... print(member.address.email) ... >>> ``` But the question is, why do you want to re-enable their delivery. Granted, there are situations such as a misconfigured MTA or not applying needed DMARC mitigations that could result in 'spurious' bounced deliveries, but normally bounce processing disables delivery, sends warnings to the bouncing address and ultimately unsubscribes them because the address it truly not deliverable. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 6 months

[MM3-users] Re: Running Mailman3 v3.2.1 on Devuan 10.0, getting a pid permissions error on Mailman3-web

by Mark Sapiro

On 2/9/21 10:17 AM, rainbear(a)gmail.com wrote: > # service mailman3-web stop > [....] Stopping Mailman3-web uWSGI service: mailman3-webstart-stop-daemon: matching on world-writable pidfile /run/mailman3-web/mailman3-web.pid is insecure > > # ls -l /run/mailman3-web/mailman3-web.pid > -rw-rw-rw- 1 root root 6 Feb 9 13:00 /run/mailman3-web/mailman3-web.pid This would appear to be either a Debian or uWSGI issue. In my case, I use gunicorn as the WSGI interface to Django, and on the server that supports this list, I have > $ cat /etc/init/gunicorn.conf > description "gunicorn for Mailman" > > start on runlevel [2345] > stop on runlevel [016] > > respawn > respawn limit 10 5 > > setuid mailman > setgid mailman > > chdir /opt/mailman/mm/ > > exec /opt/mailman/mm/bin/gunicorn -c /opt/mailman/mm/deployment/gunicorn.conf mailman_web.wsgi:application > $ cat /opt/mailman/mm/deployment/gunicorn.conf > bind = ['127.0.0.1:8000'] > proc_name = "mailman-web" > 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" > #daemon = True > workers = 4 > # Increase timout to allow downloading large archive mboxes. > # Note even 300 is not enough for the entire python-dev(a)python.org archive. > # I added 'disallow: /*/export/' to robots.txt to try to stop crawlers. > timeout = 120 > $ ll /opt/mailman/mm/var/gunicorn.pid > -rw-r--r-- 1 mailman mailman 6 Feb 7 00:13 /opt/mailman/mm/var/gunicorn.pid Some other servers I manage use systemd rather than upstart, but the permissions on the PIP file are the same. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 3 months

[MM3-users] Re: mailman3 exim4 and debian 1 problem fconnection lost

by Mark Sapiro

On 5/6/21 12:03 AM, roberto Burceni wrote: > [Mailman-Users] mailman3 and exim4 problem in debian bullseye > Good evening, > I'm configuring mailman3 with exim4 on a debian 11. > I followed the official documentation on mailman for exim. It seems to > be all rights, but I have a problem: > when I send a message to a new lists in exim logs I see that exim uses > correctly mailman router and transport. > Unfortunately in smtp.log in mailman3 log folder I have the following > error: > May 04 16:51:01 2021 (2337) ('127.0.0.1', 34746) sender: > servizioinformatico(a)uicbs.it > May 04 16:51:01 2021 (2337) ('127.0.0.1', 34746) Data: b'RCPT TO: > <listtest-unsubscribe(a)uicbs.it>' > > May 04 16:51:01 2021 (2337) ('127.0.0.1', 34746) recip: > listtest-unsubscribe(a)uicbs.it > May 04 16:51:01 2021 (2337) ('127.0.0.1', 34746) Data: b'DATA' > May 04 16:51:02 2021 (2337) ('127.0.0.1', 34746) Data: b'QUIT' > May 04 16:51:02 2021 (2337) ('127.0.0.1', 34746) connection lost > May 04 16:51:02 2021 (2337) Connection lost during _handle_client() > > This causes that messages are not sent from mailman to users. Have you > an idea of the problem? The connection lost messages are normal and not an error and not the cause of the message not being delivered to the list members. > I have no other errors in other log files What other log messages are there that might relate to this? Is mailman core running? Are there any entries in mailman's queues? Is the message Archived? Without more information, I can't say why the message isn't delivered. I can only say for certain the the smtp.log messages you show above are not related to the issue. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years

[MM3-users] Re: Mailman3 / Exim4: Router fails

by Mark Sapiro

On 5/22/23 07:44, Stephen J Turnbull wrote: > From: "Stephen J. Turnbull" <turnbull.stephen.fw(a)u.tsukuba.ac.jp> > To: ceo(a)sartrack.nz > ... > > > But it fails with this: > > MM3_LISTCHK=/var/lib/mailman3/lists/${local_part}@${domain} > > For reasons I do not understand, although Mailman 3 keeps list > configurations in the RDBMS, when it creates a list it *also* > "touches" a directory for that list in the directory $var_dir/lists. > (If I remember correctly, these are empty. It's a real directory, not > "virtual".) Since I already knew how to search for the > lists/$LIST/config,pck file used by Mailman 2, I used the same method > for Mailman 3. That directory is used to store messages being accumulated for the next digest in a digest.mmdf mailbox file. > $var_dir is set somewhere near the top of mailman.cfg. I don't know > where to find that file in your installation, it's often in > /etc/mailman3. `mailman conf -k var_dir` will show the setting for $var_dir for various layouts and `mailman conf -k layout` will show the layout in use. > Later you wrote: > > > mailman3 create templist(a)sartrack.nz templist.lists.sartrack.nz (?) > > I tried to create it as: > > create templist(a)sartrack.nz templist(a)sartrack.nz > > but it would not accept that. > > I believe that's because "mailman create" wants the posting address > and the list ID. It just wants the posting address, not the list ID. I.e. mailman create templist(a)sartrack.nz `create` is a subcommand of the `mailman command. `create` by itself as opposed to `mailman create` looks like an artifact from cPanel's Mailman 2.1. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 11 months

[MM3-users] Re: Importing config and archives only partially succeeded?

by Mark Sapiro

On 12/12/20 7:40 PM, Eric Broens via Mailman-users wrote: > There are no messages in var/archives/hyperkitty/spool/. At this time of the night (4:40 AM local time), there is no incoming mail. I'm not sure what is causing the repeated access of /archives/api/mailman/urls... This call comes from Mailman core in order to request the URL at which a message will be archived. It is called from mailman/src/mailman/handlers/rfc_2369.py when adding the Archived-At: header and from mailman/src/mailman/handlers/decorate.py in order to get the hyperkitty_url replacement value. I don't understand why it would be called repeatedly for the same message. Are there any clues in mailman.log. > I just noticed when clicking on "All Threads" or "Threads by month", the emails are displayed. The statistic however shows that there were no mails in the past month, while there actually are.When clicking "Recent", "Most Active", etc. the page shows "No discussions this month (yet)." What if you look at "threads by month" and select the current month? > Another observation. For one list, which is one of the more active ones, the bar diagram is not empty, while showing 0 participants and 0 discussions (see attached screenshot).This one however shows the mailthreads when opening the list. I think the basic issue is when you see no messages, HyperKitty, for whatever reason thinks there are no current messages. I'm not sure, but if there are recent posts, are they all in threads started more than 30 days ago? As far as all the participants/discussions counts being zero, I think one of the periodic jobs will fix that (possibly the daily recent_threads_cache job) -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 4 months

[MM3-users] Re: mailman-web migrate error

by Mark Sapiro

On 11/12/25 11:48, pashdown(a)xmission.com wrote: > I'm migrating from Ubuntu 20.04, mailman 3.2.2, postgresql 12 to Debian 13, mailman 3.3.10, postgresql 17. > > After migrating the postgresql databases and assuring the perms and passwords work, this is what I get with a "mailman-web migrate": > > (user(a)domain.com) redacted from the original > > # mailman-web migrate > Operations to perform: > Apply all migrations: account, admin, auth, contenttypes, django_mailman3, django_q, hyperkitty, postorius, \ > sessions, sites, socialaccount > Running migrations: > Applying account.0003_alter_emailaddress_create_unique_verified_email... OK > Applying account.0004_alter_emailaddress_drop_unique_email... OK > Applying account.0005_emailaddress_idx_upper_email... OK > Applying account.0006_emailaddress_lower...Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 89, in _execute > return self.cursor.execute(sql, params) > ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^ > psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "account_emailaddress_user_id_\ > email_987c8728_uniq" > DETAIL: Key (user_id, email)=(24, user(a)domain.com) already exists. This is actually a django-allauth issue. This issue is due to changes in Django allauth to prevent creating multiple addresses differing only in case. The problem is if you have such multiple addresses in your account_emailaddress table, this migration fails. There is a script at https://www.msapiro.net/scripts/UC_fix that will fix this. You may need to adjust the shebang and replace psycopg2 with sqlite3. See https://github.com/pennersr/django-allauth/issues/3019 perhaps starting at This issue is due to changes in Django allauth to prevent creating multiple addresses differing only in case. The problem is if you have such multiple addresses in your account_emailaddress table, this migration fails. There is a script at https://www.msapiro.net/scripts/UC_fix that will fix this. You may need to adjust the shebang. See https://github.com/pennersr/django-allauth/issues/3019 perhaps starting at https://github.com/pennersr/django-allauth/issues/3019#issuecomment-1748028… -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 months, 3 weeks

Search results for query "sapiro"