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

[MM3-users] Re: GDPR - save subscriptions confirmation emails

by Mark Sapiro

On 06/03/2018 12:34 PM, contact(a)maadix.net wrote: > Thanks Selva for you answer. > > In my Mailman 3 installation there is no /var/log/mailman/subscribe Correct. Mailman 2.1 had a subscribe log. Mailman 3 does not. Many things are logged in the 'mailman' log, but subscription confirmations are not. > I have logs about confirmations emails in > mailman/var/logs/smtp.log > > the format is the following: > > Jun 03 13:45:27 2018 (20764) ('127.0.0.1', 40145) handling connection > Jun 03 13:45:27 2018 (20764) ('127.0.0.1', 40145) Data: b'LHLO > mails.example.com' > Jun 03 13:45:27 2018 (20764) ('127.0.0.1', 40145) Data: b'MAIL > FROM:<contact(a)maadix.net>' > Jun 03 13:45:27 2018 (20764) ('127.0.0.1', 40145) sender: > contact(a)example.net > Jun 03 13:45:27 2018 (20764) ('127.0.0.1', 40145) Data: b'RCPT > TO:<prueba-confirm+7c010b0d89513b26d72cb4642e80447a2280ac86(a)list.example.org>' > Jun 03 13:45:27 2018 (20764) ('127.0.0.1', 40145) recip: > prueba-confirm+7c010b0d89513b26d72cb4642e80447a2280ac86(a)list.example.org > Jun 03 13:45:27 2018 (20764) ('127.0.0.1', 40145) Data: b'DATA' > Jun 03 13:45:27 2018 (20764) ('127.0.0.1', 40145) Data: b'QUIT' > > So, one solution that comes to my mind is to grep this log file. > > This is not a perfect solution and the full confirmation email is still > missing. > > I am not sure if this would be GDPR compliant. Also, while I don't think it is currently possible to confirm a subscription via REST, not to mention Postorius, it may be in the future and this would bypass email all together. I think the best thing is to implement logging. Of course, you might be able to get your MTA to save all mail to the LIST-confirm address to a separate mailbox in addition to delivering it to Mailman. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 6 months

[MM3-users] Re: What to backup?

by Mark Sapiro

On 5/26/19 12:17 PM, Alain Kohli wrote: > Thanks for the great explanation, that helped a lot! I'll try to work on > that issue if I find some time. In the meantime it would be neat to try > to clean up the old messages right before the backup. How can you > distinguish messages that have been moderated already? I couldn't really > find that in the database or the models. You could run the following in `mailman shell` $ /path/to/mailman shell Welcome to the GNU Mailman shell >>> lm = getUtility(IListManager) >>> ms = getUtility(IMessageStore) >>> for mlist in lm.mailing_lists: ... requestdb = IListRequests(mlist) ... for rq in requestdb.held_requests: ... key, msgdata = requestdb.get_request(rq.id) ... if msgdata['_request_type'] != 'held_message': ... continue ... msg = ms.get_message_by_id(key) ... print(msg['Message-ID-Hash']) ... U6QVO2GXMEQ5ZDQR2XCLDOH2FXPKJTWX 32HA6GKYE5FOVORLER7YAC3264BHG264 JM4NP3JRXBKKAL7UMM5XEXX644DQBAFJ L7FX6XKOOBP3YFFXUHA6EEJCQXX5BCHX DOJX55MRY6OYPZ4XFFTAQDD4I5MWJ3AD >>> What that prints is the names of all the files in the var/messages/ hierarchy which are currently held messages. Presumably the others are ones already handled. You could modify the above to write the list to a file and then wrap the whole thing in a shell script which would make the list and then do something like for f in `find var/messages -type f`;do n=`cut -d / -f5 <<<$f` for keep in `cat list` ;do k=0 if [ $n == $keep ] ;then k=1 break fi done if [ $k -eq 0 ]; then rm $f fi done in the above, list is the list of names to keep bade by the first script and -f5 in the cut command assumes the list from find is lines of the form var/messages/TJ/YF/TJYF5FETCRLOQZJ2H6Y4PMZP6M7GNLES. i.e. two subdirectories between messages/ and the file. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 6 months

[MM3-users] Re: mail stuck in "out" queue

by Mark Sapiro

On 9/16/22 10:49, Dan Caballero wrote: > > We're seeing some messages having the .bak files in the out queue for up to 30, 40 or even 60 minutes. I've increased the number of in and out runners to 8 each. Is there a way to know which runner has which message? If the .bak files eventually go away, this is because the message has a large number of recipients and delivery to the MTA is slow. For the out runner, look in Mailman's smtp.log for messages of the form: <message-id> smtp to <list> for nn recips, completed in tt.ttt seconds to see how long it's taking. If it seems too long (even with full VERP, it should be at least 5 to 10 recips per second), there are things you can do in the MTA to speed processing. In particular, don't do recipient validation at incoming smtp time - possibly configure an alternate submission port for Mailman to use. It shouldn't be necessary to slice the in runner and it processes very quickly. To answer your question, queue entries have a name of the form <timestamp>+<hex hash> with a .pck or .bak extension. The entry is assigned to a particular runner based on the first bits of the hash. For 8 slices this is the first 3 bits of the hash, so if the first hex digit of the hash is 0 or 1, that out queue entry will be processed by the out:0:8 runner; if it's 2 or 3, that out queue entry will be processed by the out:1:8 runner and so on through e or f processed by the out:7:8 runner. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 2 months

[MM3-users] Re: Mailman 3 database restore unexpected behavior

by Mark Sapiro

On 3/28/23 04:00, Tibor Molnar wrote: > Mailman3 built from source using virtual environment. > Version: > GNU Mailman 3.3.8 (Tom Sawyer) > Python 3.9.2 (default, Feb 28 2021, 17:03:44) > [GCC 10.2.1 20210110] > config file: /etc/mailman3/mailman.cfg > > Issue: > I have restored the database number of times recently and experienced that every time after restoration (an hour after) all members getting an email that they are unsubscribed due to bounces, however non of the users are actually unsubscribed from any lists. It looks like there are duplicates in database and all the duplicates are getting unsubscribed? > > Bounces message: > name(a)email.com unsubscribed from [listname] mailing list due to bounces That's an admin notice, not a notice to the user. > Only restoring two files: mailman3 and mailman3web > > Did anyone come acroos this behavior ? This seems sort of like <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…>, but it doesn't seem like that would be the issue here. > It is not right that after restoring a database all 1000 user get an email that they are unsubscribed, but they are actually not. > I may do something wrong during the restoring process. > Please advise me. The code that decides which users are to be removed is at <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/model/member.p…> Somehow you must be restoring members whose delivery status is disabled by bounce and whose total_warnings_sent is >= the list's bounce_you_are_disabled_warnings. What do you get from this query on the mailman3 database SELECT email FROM member JOIN address ON address_id = address.id JOIN preferences ON member.preferences_id = preferences.id WHERE delivery_status = 3 AND total_warnings_sent > 0; -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 8 months

[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 >> >

2 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, 6 months

[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

4 years, 11 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, 1 month

[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

4 years, 10 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

4 years, 7 months

Search results for query "sapiro"