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

[MM3-users] Re: Bounce processing

by Mark Sapiro

On 4/23/20 2:27 PM, Andrew Hodgson wrote: > > When users are set to disabled after their bounce score reaches a certain threshold, I seem to recall on Mailman 2 they were sent an email with a link to reactivate their subscription. On Mailman 3 they are told to contact the list admin, I have had messages from a few subscribers regarding this asking how they can re-enable delivery. The message the user is sent in built from the list:user:notice:warning template. The next release of Postorius will offer that template as one you can edit, but the current release doesn't. You can make an edited template in the var/templates/ directory. The logged-in user can go to her settings pages in Postorius at accounts/subscriptions/ to set delivery status. The generic template can't be that specific because Mailman Core doesn't even know if you have Postorius. > I am also getting bounces that look like they are coming from Qmail (Yahoo addresses) which are being forwarded to the list owner as unrecognised bounces. Should the type of bounces that Mailman 2 was handling be handled in Mailman 3 or is the way that the addresses are extracted different? I have disabled the relevant users but do have the bounces to hand. The bounce recognition for Mailman 3 is essentially the same as Mailman 2.1. If you post one of these complete bounce messages, we'll investigate why it isn't recognized. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 10 months

[MM3-users] Re: Mailman3 not working following distribution upgrade from Debian 10 to 11.

by Mark Sapiro

On 1/26/22 14:34, gordon(a)dickens.com wrote: > > However, mailman3-web (or mailman-web) is not working, I think because of a permissions issue. The installation instructions specify that mailman3-web (or mailman-web) run as user=mailman and group=mailman. However, the debian installation specifies the data files as user=www-data and group=www-data which is what apache runs as. For instance, I have my static files stored in the /var/lib/mailman3/web/static directory and the previous Debian mailman3 version set all the ownerships and groups to www-data for /var/lib/mailman3/web, /var/lib/mailman3/web/static along with all of the directories and files in the static subdirectory. So, > when I run "mailman-web collectstatic" it bombs on the following permissions error: > > PermissionError: [Errno 13] Permission denied: '/var/lib/mailman3/web/static/hyperkitty/js/hyperkitty-common.js' > > So, my question is as follows. Should I continue to run mailman3-web as user mailman and change the ownership of the /var/lib/mailman3/web directory to mailman or should I leave the permissions of the /var/lib/mailman3/web directory alone and have mailman3-web run as user and group www-data? As David later said, owner and group of all Mailman's files and directories should be `mailman` and what ever the wsgi interface is (uwsgi, gunicorn, mod_wsgi) should run the wsgi process as user:group mailman:mailman -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years

[MM3-users] Re: Removing all moderatortors (and owners) from a list in one go

by Mark Sapiro

On 8/12/24 04:07, Henrik Rasmussen wrote: > > Isn't there an easier way? And why not like https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… ? The next release of Mailman core will include a `mailman admins` command for adding and removing list owners and moderators. You could back port it simply by downloading and installing https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/commands/cli_a… The documentation is at https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/commands/d… but I suspect this isn't what you want anyway because it does owners and moderators separately and you need to provide their email addresses. You could modify the script at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… to remove all owners and moderators from a list. E.g., ``` import os import sys from mailman.core import initialize from mailman.database.transaction import transaction from mailman.interfaces.listmanager import IListManager from zope.component import getUtility os.environ['MAILMAN_CONFIG_FILE'] = '/path/to/mailman.cfg' initialize.initialize() def delete_admins(list_id): mlist = getUtility(IListManager).get(list_id) if not mlist: print(f'No such list {list_id}', file = sys.stderr) sys.exit(1) with transaction(): for admin in mlist.administrators.members: admin.unsubscribe() if __name__ == '__main__': delete_admins(sys.argv[1]) ``` Running this with an argument of the list-id or list posting address will remove all owners and moderators from a list. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 6 months

[MM3-users] Re: share directories between postfix and mailman 3

by Mark Sapiro

On 1/23/24 12:30, Thomas Schachtner via Mailman-users wrote: > > > Mark Sapiro wrote: >> >> Why do you think Mailman needs the contents of the postfix >> configuration file.. I don't think so. > I thought so, as mailman does not start if there's not > /etc/postfix/main.cf file is there. > > The following messages are logged: > Jan 23 21:20:35 mailman mailman3[491404]: RuntimeError: command failure: > /usr/sbin/postmap /var/lib/mailman3/data/postfix_lmtp, 1, Operation not > permitted > Jan 23 21:20:35 mailman mailman3[491404]: command failure: > /usr/sbin/postmap /var/lib/mailman3/data/postfix_domains, 1, Operation > not permitted Mailman itself is not looking for Postfix main.cf, but when Pustfix is the MTA, it invokes the postmap command to create the .db files for postfix_lmtp and postfix_domains. Apparently postmap fails if there is not a Postfix main.cf. You can avoid this by using regexp tables instead of hash tables. See <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h…>. >>> This seemed to work pretty fine, as all files and directories seemed >>> to be available, but when starting mailman 3, the following error >>> message was shown: >>> FileExistsError: A race condition might have happened. >>> /var/lib/mailman3 actually exists and is not a directory. >>> >>> Any idea why this message is shown? >> >> Possibly because the uid and gid of /var/lib/mailman3 on the postfix >> machine do not map to the appropriate Mailman uid and gid on the >> mailman machine. > You refer to the uid and gid of the "list" user? They are both 38 (uid > and gid) on both machines. > Then that isn't the reason. I don't know then why Mailman would complain that /var/lib/mailman3 actually exists and is not a directory. This message comes from mailman.utilities.filesystem.makedirs(). The code is at <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/utilities/file…>. makedirs() calls first_inexistent_directory() which checks if the directory exists with os.path.isdir() which apparently says it isn't a directory which makes no sense unless there is an actual race condition and you are creating the /var/lib/mailman3 directory on the mailman machine at the same time as you are starting mailman. BTW, you say you are doing sshfs root@postfix.example.com:/var/lib/mailman3 /var/lib/mailman3 on the mailman machine. Presumably on the mailman machine /var/lib/mailman3 has lots of content. How does that work? -- 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: Custom Archiver

by Mark Sapiro

On 4/1/23 09:39, pknowles(a)tpnsolutions.com wrote: > I'm playing around with installing Mailman Core, and want to have messages on a "per-list" basis sent to a special "archiver" address which I intend to make archives available at via a custom built "read-only" IMAP client. > > How would I go about having messages sent to this external address, short of adding the address as a subscriber? See https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/archiving/prot… for an example of an archiver that implements Mailman's IArchiver interface. You could make something similar with an archive_message() method that sends the message to your IMAP server, or possibly you could just implement your IMAP client to serve messages from the existing var/archives/prototype/ hierarchy. Messages for lists with the prototype archiver enabled are stored there in maildir format by list name. To enable the prototype archiver, you may need to put [archiver.prototype] enable: yes in your mailman.cfg. To make your own archiver, create a python module, say my_archive.py, that defines a My_Archive class implementing the IArchiver interface. Put that module somewhere where mailman can import it and put something like [archiver.my_archiver] class: import.path.my_archive.My_Archive enable: yes where import.path.my_archive.My_Archive is the actual path that is imported. For example if Mailman is installed in a venv, you could put my_archiver.py in the venv's site-packages directory and then the class would be just class: my_archive.My_Archive -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 10 months

[MM3-users] Re: EMWD/Affinity/Empathy in 2023

by Mark Sapiro

On 1/16/23 07:58, jaboyib556--- via Mailman-users wrote: > > However, I saw reports of EMWD being a one-man show and the owner sadly passing away in 2021; but I've also seen threads here referring to the Affinity and Empathy projects in 2022. It wasn't clear to me if EMWD is still an active business and Affinity and Empathy are still active offerings. Does anyone here have any direct contact/relationship/experience with EMWD/Affinity/Empathy following the owner's passing? Or knowledge of any other offerings publicly available today that are similar to Affinity/Empathy? I have had some contact, but not much. As far as I know, they are still in business and offering list hosting including Mailman 3 lists with Affinity and Empathy. They no longer offer support for installation and maintenance of Mailman on other people's servers. When we first were developing Mailman 3, we designed it in a modular fashion with a REST API for the core engine so that users who were so inclined could develop their own web UIs for archiving and list management. We also recognized that we needed to develop our own to make a complete package. Thus, we developed HyperKitty and Postorius for that, but we have always hoped that the community would develop others (hopefully open source and Python based). As far as I know, it was only EMWD that did this and for business reasons, kept it proprietary. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 1 month

[MM3-users] Re: My django container keeps getting shutdown by oom-killer

by Mark Sapiro

On 11/12/25 17:10, Hirayama, Pat wrote: > > This always happens overnight, usually after midnight, though one time it was around 10:40. I don't see any crontab entries that correlate. And the after midnight issues don't always happen at the same time, so it seemed unlikely that it was a crontab job that was causing it > > I finally looked at the host (rather than the logs of each container) and realized that the oom-killer was killing django-admin. As a temporary workaround, I've limited memory on the mailman-django-uwsgi container to 4 GiB (though, since I just did that this morning, I won't know until after midnight (presumably) if it worked or not), and set the RestartPolicy to always. The above suggests it's one of the Django daily jobs that's hitting the OOM. These jobs are appname - jobname - when - help -------------------------------------------------------------------------------- django_extensions - cache_cleanup - daily - Cache (db) cleanup Job django_extensions - daily_cleanup - daily - Django Daily Cleanup Job hyperkitty - orphan_emails - daily - Reattach orphan emails hyperkitty - recent_threads_cache - daily - Refresh the recent threads cache hyperkitty - sync_mailman - daily - Sync user and list properties with Mailman I don't offhand know which of these might be a memory hog. Further, if one of these dies for out of memory, I don't see it affecting more than that job, not the entire service. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 months, 1 week

[MM3-users] Re: MM3 Postfix FROM header issue

by Mark Sapiro

On 12/17/23 9:42 AM, Mark Sapiro wrote: > On 12/17/23 9:10 AM, eboltz(a)lhtservices.com wrote: >> Mark, >> >> Here is my postconf -n >> >> alias_database = hash:/etc/aliases >> alias_maps = hash:/etc/aliases >> always_add_missing_headers = yes >> append_dot_mydomain = no >> biff = no >> compatibility_level = 2 >> default_destination_concurrency_limit = 15 >> default_destination_recipient_limit = 30 >> header_checks = regexp:/etc/postfix/header_checks >> header_size_limit = 409600 >> inet_interfaces = all >> inet_protocols = ipv4 >> local_recipient_maps = proxy:unix:passwd.byname $alias_maps >> hash:/var/lib/mailman3/data/postfix_lmtp >> mailbox_size_limit = 0 >> mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain >> myhostname = lists.example.com >> mynetworks = 127.0.0.0/8 [::fff:127.0.0.0]/104 [::1]/128 >> myorigin = /etc/mailname >> readme_directory = no >> recipient_delimiter = + >> relay_domains = hash:/var/lib/mailman3/data/postfix_domains >> relayhost = [mail.smtp2go.com]:587 >> smtp_always_send_ehlo = yes >> smtp_sasl_security_options = noanonymous >> smtp_tls_CApath = /etc/postfix/o365_smtp_cert.pem >> smtp_tls_security_level = may >> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache >> smtp_use_tls = yes >> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) >> smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated >> defer_unauth_destination >> smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem >> smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key >> smtpd_tls_security_level = may >> transport_maps = hash:/var/lib/mailman3/data/postfix_lmtp >> unknown_local_recipient_reject_code = 550 >> virtual_alias_maps = hash:/var/lib/mailman3/data/postfix_vmap > > > It looks like you are now following > <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h…>. > > >> What would I have to do to ensure that MM3 and postfix (same new >> server) use the newly created lists.example.org domain, which only >> exists within Postfix when setting up the Postorius domain and lists? >> I want to have it so that whatever the list name is, for example >> 'Staff(a)lists.example.org' will route through Postfix correctly. > > > Have you set an alias_domain for the lists.example.org domain? > > What are the contents of /var/lib/mailman3/data/postfix_vmap and > /var/lib/mailman3/data/postfix_lmtp? If you feel it is necessary to > anonymize the domains in these, please only change the tld so we can see > the actual subdomains. However, it looks like you don't need to follow <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h…> as lists.example.org is not a virtual_alias_domain. You just need to add lists.example.org to mydestination, assuming lists.example.org and lists.example.com are actually different domains, and follow <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h…>. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 2 months

[MM3-users] Re: Newbie question 2: Rewriting issue for bounced emails

by Mark Sapiro

On 12/27/21 1:36 PM, William Oliver wrote: > > When I send a message to the list from *any* of these three, the > mailman3 accepts it and attempts to broadcast it out. It is delivered > sucessfully to the local email address, but it looks like there's a > relaying problem with external addresses. > > In the syslog snippet below, note that the fp145(a)libertyfp.org mail is > delivered, but the mail to the recipients at billoblog.com get an > "Access denied" ...> > Dec 27 15:33:26 libertyfp postfix/smtpd[419593]: NOQUEUE: reject: RCPT > from mail.libertyfp.org[2.56.57.28]: 554 5.7.1 <billo(a)billoblog.com>: > Recipient address rejected: Access denied; > from=<testlist-bounces+billo=billoblog.com(a)libertyfp.org> > to=<billo(a)billoblog.com> proto=ESMTP helo=<mail.libertyfp.org> > > Dec 27 15:33:26 libertyfp postfix/smtpd[419593]: disconnect from > mail.libertyfp.org[2.56.57.28] ehlo=1 mail=2 rcpt=1/2 data=1 rset=1 > quit=1 commands=7/8 It appears that the MX for billoblog.com is not accepting mail from your server. Can you send non-mailman mail from this server to this address? If not, you need to contact billoblog.com to fin wht they are blocking your mail. > I tried changing the smtp port in mailman.cfg to 587, but that didn't > change anything. because the issue is not in delivery from Mailman to Postfix. It is in delivery from Postfix to billoblog.com. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 1 month

[MM3-users] Re: CPU usage when idle

by Mark Sapiro

On 5/28/25 08:27, roughnecks via Mailman-users wrote: > > It's the manage.py qcluster whatever is called. I have shut down MM for > the time being, because I'm not fully motivated to have it running, so I > can't be more accurate right now. I don't know how qcluster is configured in the Debian packages (which are out of date and possibly buggy anyway). You may be using django-q <https://django-q.readthedocs.io/en/latest/> and if so, you should migrate to django-q2 <https://django-q2.readthedocs.io/en/master/>. Both typically use memcached as a backend. Settings that control this are typically ``` # Set retry > timeout. Q_CLUSTER = { 'timeout': 300, 'retry': 360, 'save_limit': 100, 'orm': 'default', } ``` and possibly a setting like `'workers': 2,` (default is the CPU count of the system but see <https://django-q2.readthedocs.io/en/master/configure.html#f1>). ``` CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache', 'LOCATION': '127.0.0.1:11211', } } ``` although the default if not set is ``` CACHES = { "default": { "BACKEND": "django.core.cache.backends.locmem.LocMemCache", } } ``` It is the `'orm': 'default'` setting that says to use Django's CACHES. See <https://django-q2.readthedocs.io/en/master/brokers.html#django-orm>. You can get info about what qcluster is doing with `manage.py qinfo` and monitor things with `manage.py qmemory` and `manage.py qmonitor`. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 months, 4 weeks

Search results for query "sapiro"