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

[MM3-users] Re: No digest.mmdf

by Mark Sapiro

On 3/28/21 8:18 AM, Christine wrote: > I have mailman3 running now, more or less. Mailman did not send messages > to my list, giving a permiission error on the digest.mmdf file, which > was not there. I created the file and made list.list the owner, now it > sends messages. > I don't know what should have created the file or what set the > permissions to the directory, I just thought I'd let you know. Mailman core creates and writes the lists/LIST-ID/digest.mmdf file to accumulate messages for the digest. When a digest is sent the file is removed only to be recreated on the next post, and you will probably run into this issue again. The issue is the user that Mailman core is currently running as does not have permission to create that file. This usually results from having run core as root at some point in the past causing some files and directories to have been created by root and not writable by the mailman user now running core. You need to ensure that Mailman processes are always run as the Mailman user, often `mailman` but in the case of Debian/Ubuntu packages, `list`. You probably need to ``` sudo chown xxx:xxx path_to_mailman_var/ ``` where xxx is the Mailman user. -- 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: "autorespond to list owner" setting when importing from mailman2 to mailman3

by Mark Sapiro

On 2/25/22 08:32, bob B via Mailman-users wrote: > In mailman2 a list was moderated, the admin would also get an email to approve the message, our lists mainly have admins and no moderators. The admins did the moderation. > > In mailman3 it looks this is now a setting "autorespond to list owner" was this a setting in mailman 2? Yes, in MM 2.1 this was in the Auto-responder section of the admin UI, but this isn't what you wan. > Anyway, in importing email list from mailman 2 to 3, it appears that this setting is set to "No automatic response", is that right? Probably. It is =correct if that was the MM 2.1 setting. > So does this means if I import all my lists from mailman 2, then the admins will not get moderation notifications until I make that setting change on each list? No. The setting you want was Mailman 2.1's General Options -> admin_immed_notify which should be correctly imported to what Postorius shows as Settings -> Automatic Responses -> Admin immed notify and whether that is Yes or No, they should get periodic notices as long as cron is running `mailman notify`. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 5 months

[MM3-users]Re: Sass and where to find core rest logs

by Mark Sapiro

On 05/04/2016 09:45 AM, Andrew Hodgson wrote: > Anyway, I have compiled Mailman3, and the web interface is coming up. Bringing up the list of lists initially gave me an exception, and I saw a 5xx error in the mailman.log file in /opt/mailman/var/logs. I read up on this and as a result downgraded Falcon<1.0 in the Python 3.4 venv. > > I am still unable to browse the list of lists with a 500 error, only this time I am not getting an entry in the mailman.log indicating there is an issue, and I am wondering if there are more detailed logs that can be switched on? There are the web server logs and there is the mailman-web configured in LOGGING:handlers:file in (using bundler) mailman-bundler/mailman-web/production.py (or testing.py). The production default is /var/log/mailman-web/mailman-web.log; the testing default is /opt/mailman/var/mailman-web/hyperkitty.log. > The other question I have is on Sassc. I believe the default Mailman web interface has now switched to the Ruby implementation of Sass, but is this correct? The documentation on the Mailman-Bundler site seems to suggest that Sassc is still the default. I think the bundler doc is out of date on this. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

10 years, 3 months

[MM3-users] Re: How to promote non-members to members?

by Mark Sapiro

On 3/17/22 12:25, Quanah Gibson-Mount wrote: > > I've done nothing in regard to this user. Neither command returns > anything. Well, something has deleted the user, but ... >> If the user is gone, you should be able to replace >> ``` >> ... sub_mgr.confirm(token) >> ``` >> in the above with >> ``` >> ... wfm = getUtility(IWorkflowStateManager) >> ... pendings.confirm(token, expunge=True) >> ... wfm.discard(token) >> ``` >> to clear the pending subscription and workflow and then be able to mass >> subscribe the user. > > I did this, and can confirm that they no longer show up in the list of > pending subscriptions via the mailman shell interface for that list. > > However, if I go to mass subscribe them via the interface, I get: > > HTTP Error 409: b'Subscription request already pending' I don't understand. If there is no entry for that address when you do ``` >>> for token, data in pendings.find(pend_type='subscription'): ... if data['token_owner'] != 'subscriber': ... continue ... if data['email'] != 'user(a)example.com': ... continue ... print(data['email']) ... ``` You should not be getting that 'Subscription request already pending' response. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 5 months

[MM3-users] Re: Moderation request email from a non existing user

by Mark Sapiro

On 5/31/22 02:15, David Lopez via Mailman-users wrote: > Every day mailman (MM 3.3.3 (Tom Sawyer)) sends me an email with a held unsubcription request from X user. This user is not subcribed to that list anymore but every day an email is sending to the list owner. On the web interface there's nothing pending for approval or similar. Is there anyway to avoid receiving this anoyning email every day? Thanks in advance. Postorius >=1.3.5 has an `Unsubscription Requests` choice in the `Subscription requests` pull down. This choice will list the request with and allow you to delete it. For earlier Postorius this needs to be done via the REST API or via mailman shell. For example: ``` $ bin/mailman shell -l list(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 list(a)example.com mailing list >>> pendingsdb = getUtility(IPendings) >>> for token, data in pendingsdb.find(m, pend_type='unsubscription'): ... if data['token_owner'] == 'moderator': ... pendingsdb.confirm(token) ... data about the request will be displayed here >>> commit() >>> ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 2 months

[MM3-users] Re: Performance issues with Mailman 3

by Mark Sapiro

On 10/6/22 15:08, Wong, Wesley wrote: > Hi, I am having some performance problems with Mailman 3 (version 3.3.5) when it sends out a lot of messages to people. We recently migrated from our old Mailman 2.1.x system to Mailman 3.x about 3 months ago. We host about 350 lists with membership counts varying between 10 to 1500 members on some of the lists. I noticed that outbound messages from Mailman to our outbound SMTP are getting delayed up to an hour when Mailman is processing a lot of messages going to lists. I suspect the difference is your Mailman 3 instance has full VERP enabled and your Mailman 2.1 instance did not. I.e., In MM 2.1, you did not override the default `VERP_DELIVERY_INTERVAL = 0` in mm_cfg.py, but in MM 3 you have `verp_delivery_interval: 1` in the `mta` section of mailman.cfg. > I was wondering if there are good performance tuning tips to be considered for Mailman 3 (i.e. OS, database and/os Mailman Core). I am running the setup on a VM. Here is my configuration for VM and OS: Search the Titles for `performance` at https://wiki.list.org/. The articles you find are all written for MM 2.1, but you're really dealing with the MTA and the issues are the same for MM 3. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 10 months

[MM3-users] Re: running a script for the mailman-shell (to discard held messages) gives errors about a package argument for relative import

by Mark Sapiro

On 6/15/24 03:10, via Mailman-users wrote: > > Now, obviously, I put these exact lines in a script, so I don't have to type it out every single time, and try to run it using > >> sudo -u list mailman shell -l testlist.our-server.de -r ./mm_discard_held.py > > but that invariably gives me ... > TypeError: the 'package' argument is required to perform a relative import for './mm_discard_held' To run a script named mm_discard_held.py in that way, the script must define a function mm_discard held. The content needs to be something like ``` from mailman.app.moderator import handle_message from mailman.config import config from mailman.interfaces.action import Action from mailman.interfaces.request import IListRequests # The above are needed. These imports are done automatically when # running mailman shell interactively, but not when running a script. def mm_discard_held(mlist) rdb = IListRequests(mlist) for req in rdb.held_requests: if req.request_type == RequestType.held_message: config.db.commit() ``` See `mailman shell --details` > I've tried moving it to the path where the mailman binary lives, as suggested. That is what you should do. -- 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: Pck files stuck in out queue

by Mark Sapiro

On 2/7/25 10:08, Lieuallen, Thomas Otis via Mailman-users wrote: > > I have a remaining issue that baffles me. With my test list, I created a template for ‘list:member:regular:header’. It just has text in it, keeping it simple. I create it and see the entries in the database tables and they are correct. However, when I send a test email, my template text is not inserted, but instead another simple text: “testing hello”. I do the same with list:member:regular:footer, and it works just fine. It is just the header that is working incorrectly. When I remove that postorius header template for the list, that ‘testing hello’ goes away. So, it’s only appearing when I have a postorius template setup for that list. What do you get from the following database queries? SELECT * FROM template WHERE name = 'list:member:regular:header'; SELECT * FROM postorius_emailtemplate WHERE name = 'list:member:regular:header'; Depending on your installation, these tables may be in separate databases, i.e., template table in mailman db and postorius_emailtemplate in mailmanweb db. And what do you get if you go to the uri in the result(s) from the first query? The context in the first results and maybe the second results should also be a clue. -- 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: Is there an option to "disable" a list temporarily? (feature request?!)

by Mark Sapiro

On February 2, 2026 3:26:40 AM PST, Christian Schneider <christian.schneider(a)tu-dortmund.de> wrote: >Hello dear Mailman Team, > >I scanned through the web interface of my mailman instance... >and I did not find an option to disable a list temporarily ("sending" and "access to web interface")... >This might come in handy when a list is abused for sending spams >or when a list owner wants his/her list to be removed... >Instead of removing the list instantly I would disable it for three months first... >(You never know with users... ;-) ) >Preferably I would backup the list (settings and members) and the archives, >but as seen in the discussion there is actually no backup mechanism for lists... > >Is there an option to disable a list (except from resetting passwords and remove/disable mail aliases)? > >If not I'd like to hand this in as a feature request... xD There is an emergency moderation setting. It isn't really what you're asking for, but it might be helpful for spam attacks. As far as backup and restore of lists is concerned, there are issues at <https://gitlab.com/mailman/mailman/-/issues/1182> and <https://gitlab.com/mailman/postorius/-/issues/13>. -- Mark Sapiro <mark(a)msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.

6 months, 2 weeks

[MM3-users] Re: Log rotation

by Mark Sapiro

On 04/10/2018 03:39 PM, Abhilash Raj wrote: > Yes, this is a known thing and the reason for it is that the SIGTERM isn't delivered till the process wakes up next time. We can have the process sleep for a smaller amount of time to fix this, but then it would mean that it will be running much more often. > > It is the Retry runner, which has sleep_time set to 15m. I don't know if you want to retry very often, like 2min or 5min, but you can change it by adding the following snippet to your mailman.cfg A long time ago (in a galaxy far away) Mailman 2.1 had a global DELIVERY_RETRY_WAIT setting. This setting had been ineffective for years, relying instead on the retry runner's sleep time. In 2.1.26, for what turned out to be a probably spurious reason, I made DELIVERY_RETRY_WAIT effective again, although the retry runner still sleeps for 15 minutes. We could implement something similar in MM 3 to allow the retry runner to have a much shorter sleep time without actually retrying the delivery that often. The down side of that is even though we aren't retrying delivery each time the runner wakes up, we are dequeueing and requeueing the message each time and this would have a file system impact. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 4 months

Search results for query "sapiro"