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

[MM3-users] Re: Disabled by bounce

by Allan Hansen

Thank you, Mark. By "However, all of the above can be avoided without any DMARC changes by enabling bounce probes." Do you mean that I can get rid of the 'From' mangling, which has been a frequent source of embarrassment because the list address is captured and reused by type-ahead when sending non-list messages and those messages instead going to 1000 subscribers. __ Allan On 2/1/23, 09:59, "Mark Sapiro" <mark(a)msapiro.net> wrote: On 1/31/23 22:32, Allan Hansen wrote: > Hi all, > > Apparently Google just started to get very aggressive about DKIM settings. Some hundreds of my subscribers have had their subscriptions disabled because of Google's bounces. > > I tried to 'Enable' some of them, expecting that their bounce scores would be reset, but when I list the users, the bounce scores are still 5. > > Please advise. Will enabling them without the bounce score being reset just cause the server to disable them again. Yes, Google has started enforcing a policy which is effectively DMARC p=reject even for senders whose domains don't publish DMARC p=reject or quarantine. To avoid this issue, you may need to set DMARC Mitigate unconditionally to Yes as well as DMARC mitigation action to Replace From: with list address if it isn't already. As far as enabling without resetting the bounce score is concerned, I think you are correct that they will just be disabled again on the next bounce. This is a bug and should be fixed. However, all of the above can be avoided without any DMARC changes by enabling bounce probes. in the [mta] section of mailman.cfg, set ``` verp_probes: yes ``` Since the probe is sent From: the list's domain, it should pass googles SPF and DKIM checks and not bounce. -- 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: mailman-users(a)mailman3.org <https://lists.mailman3.org/archives/list/<a href=>/message/56WVO6NIOGOBAOOS2B4YCIDJN7VCIXTF/">https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… This message sent to hansen(a)rc.org

3 years, 5 months

[MM3-users] Re: Held messages: Long time waiating for response of the Mailman API

by Stephan Krinetzki

Mark Sapiro wrote: > On 1/26/22 00:11, Stephan Krinetzki wrote: > > After we enabled the "slow query log", we got in the postgresql database the following output: > > 2022-01-25 12:49:41.538 CET [16126] LOG: unexpected EOF on client connection with an open transaction > > 2022-01-25 15:34:36.047 CET [16864] LOG: duration: 30760.028 ms statement: DELETE FROM pendedkeyvalue WHERE pendedkeyvalue.id = XXX > > 2022-01-25 15:34:36.047 CET [3900] LOG: duration: 9372.471 ms statement: DELETE FROM pendedkeyvalue WHERE pendedkeyvalue.id = XXX > > 2022-01-25 16:42:07.243 CET [3900] LOG: unexpected EOF on client connection with an open transaction > > > > > > Pretty sounds like a database problem? > > The unexpected EOF is because the gunicorn worker timed out and was killed. > There are two DELETE FROM pendedkeyvalue WHERE pendedkeyvalue.id = XXX > transactions because the first one timed out. These came from > https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/app/moderator.p... > The accept action is processed and ultimately we get to > https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/app/moderator.p... > and that in turn is doing the DELETE at > https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/model/pending.p... > There must be some kind of database locking causing this, but I have no > clue as to what it might be. If you haven't done so, I would stop all > the mailman services and the database server and then start them again. > I don't know if that would help, but it might. We did this and nothing changed. I even tried to lookup up potential DB locks, but they are no locks in the database. Side note: Wie have a 37GB big Database with ~4.000 Mailinglists and ~70.000 addresses > > sometimes the log (mailmansuite.log) show us this error > > That too is from the gunicorn worker timing out and being killed. Okay. We already set the timout of the gunicorn process of the mailmancore higher (6 Min) I think there is a communication problem in the chain: apache -> uwsgi -> mailmancore/API ->database but i can't dig deeper there. Let me know if i should provide more details or logs

4 years, 6 months

[MM3-users] Re: user mail not accepted

by Christian Stalberg

No. there was no response received by the user a la "results of your email commands" message. Simply the original email sent to the list. -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Monday, April 26, 2021 5:25 PM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: user mail not accepted On 4/26/21 5:00 PM, Christian Stalberg via Mailman-users wrote: >>From smtp.log > > Apr 26 00:17:39 2021 (807) ('127.0.0.1', 38370) Data: b'DATA' > Apr 26 00:17:39 2021 (807) ('127.0.0.1', 38370) Data: b'QUIT' > Apr 26 00:17:39 2021 (807) ('127.0.0.1', 38370) connection lost Apr 26 > 00:17:39 2021 (807) Connection lost during _handle_client() Apr 26 > 00:18:11 2021 (809) > <019301d73a31$8e8e54e0$abaafea0$(a)ncboliviapartners.org> smtp to > ncpoa(a)lists.ccalternatives.org for 83 recips, completed in > 29.13376259803772 seconds Apr 26 00:18:11 2021 (809) > <019301d73a31$8e8e54e0$abaafea0$(a)ncboliviapartners.org> post to > ncpoa(a)lists.ccalternatives.org from christian(a)ncboliviapartners.org, > 5811 bytes Apr 26 00:18:11 2021 (809) > <161939626169.810.9530678025639681522(a)zarathustra.ccalternatives.org> > smtp to ncpoa(a)lists.ccalternatives.org for 1 recips, completed in > 0.0420069694519043 seconds > Apr 26 00:18:11 2021 (809) > <161939626169.810.9530678025639681522(a)zarathustra.ccalternatives.org> > post to ncpoa(a)lists.ccalternatives.org from > ncpoa-bounces(a)lists.ccalternatives.org, 869 bytes Apr 26 11:52:22 2021 > (819) > <161943793957.929.15640398646519288095(a)zarathustra.ccalternatives.org> > smtp to ssan(a)lists.ccalternatives.org for 1 recips, completed in > 0.22335004806518555 seconds > Apr 26 11:52:22 2021 (819) > <161943793957.929.15640398646519288095(a)zarathustra.ccalternatives.org> > post to ssan(a)lists.ccalternatives.org from > ssan-bounces(a)lists.ccalternatives.org, > 765 bytes > Apr 26 11:52:22 2021 (819) > <161943793960.929.13309139087156940549(a)zarathustra.ccalternatives.org> > smtp to ssan(a)lists.ccalternatives.org for 2 recips, completed in > 0.05862092971801758 seconds > Apr 26 11:52:22 2021 (819) > <161943793960.929.13309139087156940549(a)zarathustra.ccalternatives.org> > post to ssan(a)lists.ccalternatives.org from > noreply(a)lists.ccalternatives.org, 810 bytes Apr 26 11:55:22 2021 (819) > <161943812108.929.10391982256874011271(a)zarathustra.ccalternatives.org> > smtp to ssan(a)lists.ccalternatives.org for 1 recips, completed in > 0.1459965705871582 seconds > Apr 26 11:55:22 2021 (819) > <161943812108.929.10391982256874011271(a)zarathustra.ccalternatives.org> > post to ssan(a)lists.ccalternatives.org from > ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.ccalternat > ssan-confirm+ives.o > rg, 1526 bytes > Apr 26 12:01:30 2021 (817) Available AUTH mechanisms: LOGIN(builtin) > PLAIN(builtin) > Apr 26 12:01:30 2021 (817) Peer: ('127.0.0.1', 38556) Apr 26 12:01:30 > 2021 (817) ('127.0.0.1', 38556) handling connection Apr 26 12:01:30 > 2021 (817) ('127.0.0.1', 38556) Data: b'LHLO > zarathustra.ccalternatives.org' > Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) Data: b'MAIL > FROM:<christian(a)sewagesludgeactionnetwork.com>' > Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) sender: > christian(a)sewagesludgeactionnetwork.com > Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) Data: b'RCPT > TO:<ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.ccalte > rnativ > es.org>' > Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) recip: > ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.ccalternat > ssan-confirm+ives.o > rg > Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) Data: b'DATA' > Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) Data: b'QUIT' It looks like the above 12:01:30 are the relevant entries, and that message was sent to ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.ccalternativ ssan-confirm+es.org which is not the list, but the list's -confirm address. Was the response received by the user a "results of your email commands" message? > Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) connection lost Apr 26 > 12:01:30 2021 (817) Connection lost during _handle_client() Apr 26 > 12:01:34 2021 (819) > <161943849287.814.5890052642238479423(a)zarathustra.ccalternatives.org> > smtp to ssan(a)lists.ccalternatives.org for 2 recips, completed in > 0.06680631637573242 seconds > Apr 26 12:01:34 2021 (819) > <161943849287.814.5890052642238479423(a)zarathustra.ccalternatives.org> > post to ssan(a)lists.ccalternatives.org from > noreply(a)lists.ccalternatives.org, 821 bytes Apr 26 12:01:34 2021 (819) > <161943849292.814.6140111398379700592(a)zarathustra.ccalternatives.org> > smtp to ssan(a)lists.ccalternatives.org for 1 recips, completed in > 0.04269862174987793 seconds > Apr 26 12:01:34 2021 (819) > <161943849292.814.6140111398379700592(a)zarathustra.ccalternatives.org> > post to ssan(a)lists.ccalternatives.org from > ssan-request(a)lists.ccalternatives.org, > 1335 bytes > > > Message sent that only the user receives: What I wanted to see was not the message sent to the list, but the message received by the one user from the list. If you are saying this message is that, it didn't come from any Mailman list. > Return-Path: <christian(a)sewagesludgeactionnetwork.com> > Delivered-To: ces(a)ecovillage.cc > Received: from box.ecovillage.cc ([127.0.0.1]) > by box.ecovillage.cc with LMTP id MDucNBythmCTSwAAMoO61A > for <ces(a)ecovillage.cc>; Mon, 26 Apr 2021 05:07:56 -0700 > X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on > box.ecovillage.cc > X-Spam-Level: > X-Spam-Status: No, score=-1.1 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, > DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE autolearn=ham > autolearn_force=no > version=3.4.2 > X-Spam-Report: > * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP > * 0.0 HTML_MESSAGE BODY: HTML included in message > * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature > * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not > necessarily > * valid > * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from > * author's domain > X-Spam-Score: -1.1 > Received: from authenticated-user (box.ecovillage.cc [45.79.28.18]) > (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 > bits)) > (No client certificate requested) > by box.ecovillage.cc (Postfix) with ESMTPSA id 6EADF3E8CC > for <ssan(a)lists.naturalintelligence.us>; Mon, 26 Apr 2021 05:07:54 > -0700 (PDT) > DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; > d=sewagesludgeactionnetwork.com; s=mail; t=1619438876; > bh=1M7F/uIS0bNG6cWjecy/a9QjskrHVwJHkjWRv+ffpM4=; > h=From:To:References:In-Reply-To:Subject:Date:From; > b=jXOswVZgFeHBB+sjIDqVkNBQqIbfZCj9ZUfpVwl10NQEkGaoxckPHNOKT6x9zIqsW > BZ7iZqqi2mWprVQ8LrK48Lp7gvCQ/ipqspMeLt3t+uljzTtryHmV6uJFEAU3hqM33Y > nQqX6Z8la8Ko40F9Ayb4h4e/MOfPdA4nadgf5hZzt/DzPFZvzUbG3V8lWcHuyJNA2y > SQkhbNubQ6iNEEB0SyBjoOjl3g3LVxjxY+9kMGGmX+1PFfW90CpDDShRmKkkscEWaA > NiV0fX6U5LENBBnc6Q9ImLgXuaLdCqlBRBumJBk+eUUr007rpXXVAPck2NvUzGyM2v > kNNGlT68hGzEg== > From: <christian(a)sewagesludgeactionnetwork.com> > To: <ssan(a)lists.naturalintelligence.us> > References: > In-Reply-To: > Subject: How US chemical industry lobbying and cash defeated > regulation in Trump era > Date: Mon, 26 Apr 2021 05:07:37 -0700 > Message-ID: > <020501d73a94$cbe17440$63a45cc0$(a)sewagesludgeactionnetwork.com> > MIME-Version: 1.0 > Content-Type: multipart/alternative; > boundary="----=_NextPart_000_0206_01D73A5A.1F831170" > Thread-Index: Adc6h7I/qzBKx1yOT6aPOuipppacoQACatZAAADW1wA= > Content-Language: en-us > > How US chemical industry lobbying and cash defeated regulation in > Trump era Industry's congressional allies defeated nearly all PFAS > legislation while the Trump EPA killed, watered down or slowalked new > rules > > https://www.theguardian.com/environment/2021/apr/26/us-chemical-compan > ies-lo > bbying-donation-defeated-regulation > > -- 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/

5 years, 3 months

[MM3-users] Re: mm3 installation question

by Stephen J. Turnbull

Odhiambo Washington writes: > Mark Sapiro writes: > > Some of the `path` settings are probably not in the same order as > > in that file. The > > > > ``` > > path('mailman3/', include('postorius.urls')), > > path('archives/', include('hyperkitty.urls')), > > ``` > > settings should come after the > > ``` > > path('postorius/', include('postorius.urls')), > > path('hyperkitty/', include('hyperkitty.urls')), > > ``` > > settings (unfortunately, mailman-web 0.0.8 has these in the wrong > > order). Or you can just delete the 'postorius/' and 'hyperkitty/' > > ones or you can add > > ``` > > ProxyPass "/postorius" "http://127.0.0.1:8000/postorius" > > ProxyPass "/hyperkitty" "http://127.0.0.1:8000/hyperkitty" > > ``` > > to your Apache config. > The odd thing is that the HOWTO that he followed never involves the > manipulation of any urls.py at all - it's not even mentioned at any > point. So obviously the issue is caused by something else and I > suspect something within Apache needs to be re-evaluated in the > guide. I believe this is the Apache configuration the OP is using: <IfModule mod_proxy.c> ProxyPreserveHost On ProxyPass "/mailman3" "http://127.0.0.1:8000/mailman3" ProxyPass "/archives" "http://127.0.0.1:8000/archives" ProxyPass "/accounts" "http://127.0.0.1:8000/accounts" ProxyPass "/admin" "http://127.0.0.1:8000/admin" ProxyPass "/user-profile" "http://127.0.0.1:8000/user-profile" </IfModule> Note that Apache doesn't know about the "/postorius" and "/hyperkitty" URI paths. It is quite unclear to me how this works at all with either the path('mailman3/', include('postorius.urls')), path('archives/', include('hyperkitty.urls')), path('postorius/', include('postorius.urls')), path('hyperkitty/', include('hyperkitty.urls')), version of urls.py or the reverse order version path('postorius/', include('postorius.urls')), path('hyperkitty/', include('hyperkitty.urls')), path('mailman3/', include('postorius.urls')), path('archives/', include('hyperkitty.urls')), I think Mark must have a configuration with ProxyPass "/" "http://127.0.0.1:8000/" in the Apache configuration in mind? Or an alias or rewrite rule. Otherwise I don't see how "/postorius" and "/hyperkitty" paths ever get transmitted to the WSGI server. Steve

2 years, 4 months

[MM3-users] Re: SPF check fails for lists subdomain

by Jan Eden

On 2023-01-05 11:13, Odhiambo Washington wrote: > On Thu, Jan 5, 2023 at 10:56 AM Jan Eden via Mailman-users < > mailman-users(a)mailman3.org> wrote: > > > On 2023-01-04 15:07, Mark Sapiro wrote: > > > On 1/4/23 14:02, Jan Eden via Mailman-users wrote: > > > > Although I could specify the IP address in my SPF records directly (as > > > > you suggested), I do hope that my understanding of DNS records laid out > > > > above is not entirely misguided. My current setup does work as expected > > > > for eden.one, after all. > > > > > > As I said at < > > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > > > > > I was misreading your DNS and now I am as puzzled as you about the > > failure. > > > > It gets even more mysterious. I tried sending messages from both > > lists.eden.one and janeden.net (my other domain) to a gmail account and > > to another mail provider. Both messages passed the SPF checks on both > > services (s. the relevant headers quoted below). Now because I send > > those messages via my SMTP user (smtpuser(a)eden.one) and use SRS, the SPF > > check operates (and succeeds) on e.g. > > > > srs0=jdm+=5c=lists.eden.one=testlist-bounces+gmailuser=googlemail.com(a)eden.one > > (and not on somethingsomething(a)lists.eden.one or > > somethingsomething(a)janeden.net) Could this be the reason for the failed > > SPF checks in Yahoo's and Google's DMARC reports? > > > - Jan > > Might you be willing to use proven tools instead of trying so hard to > understand the myth? > > I use https://easydmarc.com/tools#spf-tools > It allows me to generate, lookup, test SPF, DKIM, DMARC, etc. I did use adequate tools to generate and test my DNS records, and this is why the DMARC reports quoted in my initial message are mysterious to me. Trying hard to solve a mystery might not be productive in every case, but I do not want to stop being curious. - Jan

3 years, 6 months

[MM3-users] Re: Missing bits of French translation

by iMark

>> On 5/12/26 17:30, iMark wrote: >> >> 3. Page text fails. eg. >> ENGLISH: You have to sign in to visit the archives of this list. >> FRENCH: Is in English. >> >> Looking at the .po file ... >> >> /opt/mailman/venv/lib/python3.11/site-packages/mailman/messages/fr/LC_MESSAGES/mailman.po >> >> "PO-Revision-Date: 2024-06-25 17:09+0000\n" ====================================== > On 2026-05-13 02:19, Mark Sapiro wrote: > That file is out of date. It may or may not be from the latest > Postorius released version but it has been subsequently updated for > the next release. > > That particular string is marked fuzzy in the current .po - see > <https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/locale/fr/…> > > It is marked fuzzy because the msgid was changed at some point from > ``` > msgid "You have to login to visit the archives of this list." > ``` > to > ``` > msgid "You have to sign in to visit the archives of this list." > ``` > > The translations are managed at Weblate. The particular French > translation for Postorius is at > <https://hosted.weblate.org/projects/gnu-mailman/postorius/fr/>. > > The above string is one of 19 that are marked for edit. > > You are more than welcome to create an account at Weblate and fix > whatever needs fixing in the French translation and Weblate will > submit a merge request to update the .po on GitLab. We would be > grateful for your help. ======================================= Thanks Mark. I edited the .po file (on my installation) for Postorius ... /opt/mailman/venv/lib/python3.11/site-packages/postorius/locale/fr/LC_MESSAGES/django.po ... for example ... msgid "You have to sign in to visit the archives of this list." msgstr "Vous devez vous identifier pour consulter les archives de cette liste." ... and recompiled the .mo file ... msgfmt -o /opt/mailman/venv/lib/python3.11/site-packages/postorius/locale/fr/LC_MESSAGES/django.mo /opt/mailman/venv/lib/python3.11/site-packages/postorius/locale/fr/LC_MESSAGES/django.po ... and the text on the webpage is now displayed in French. Happy days! I've created an account at Weblate and will get onto the .po file there. Thank you again for your help.

2 months, 2 weeks

[MM3-users] Re: Unable to get Postfix to bounce messages to non-existent lists

by skenny＠scss.tcd.ie

Thanks Mark Sapiro and Stephen J. Turnbull for your responses. Re the output of mailq - this was initially confusing (to me anyway). The diagnostic for the message stuck in the queue was "connection timed out", but the IP listed was the Postfix mail server's not Mailman's. At a guess, Postfix was trying to send the message to Postfix's local domain after it failed to LMTP it over to the Mailman server, and was unable to do that too. Since I posted yesterday, I hit upon a solution that seems to work ... I set relay_recipient_maps to the same value as transport_maps, so that the relevant config lines now look like this: transport_maps = regexp:/var/mailman-data/postfix_lmtp local_recipient_maps = $alias_maps relay_domains = regexp:/var/mailman-data/postfix_domains relay_recipient_maps = regexp:/var/mailman-data/postfix_lmtp This seems to have the desired effect (and, I hope, no unintended consequences). If I fire a message at a non-existent list now, I get an immediate bounce message in my mail client - "Recipient address rejected: User [nonexistent-list(a)lists.scss.tcd.ie] unknown in relay recipient table". No longer is the message loitering in the Postfix queue. The Postfix documentation for relay_recipient_maps says "Optional lookup tables with all valid addresses in the domains that match $relay_domains. [...] Technically, tables listed with $relay_recipient_maps are used as lists: Postfix needs to know only if a lookup string is found or not, but it does not use the result from the table lookup." For transport_maps, it says "Optional lookup tables with mappings from recipient address to (message delivery transport, next-hop destination). " Postfix does what we want now: bounce the message is the list name isn't found in relay_recipient_maps, forward it on to the Mailman server via LMTP (transport_maps setting) if it is. Re Stephen J. Turnbull's comment about the patch allowing Postfix to query Mailman's database and more, I think I'll hold off for the moment, but good to know. We will reconfigure when it makes it into an official release (we're using Maxking's Docker images). As ever I'm really grateful for your taking the time to respond, many thanks. Kind regards.

2 years, 5 months

[MM3-users] Re: Unable to update templates

by Mark

On 5/28/25 01:14, Mark wrote: >> >> Then I created a template using Postorius and updated the uri in >> mailman.templates to: >> >> file:///opt/mailman/mm/var/templates/lists/testlist.example.com/en/list:use… >> - and that works. >> >> It's looking promising. Now I just need to modify my script that >> periodically copies the data from the >> "mailmanweb.postorius_emailtemplate" table to a file and updates the >> uri. On 2025-05-28 19:17, Mark Sapiro wrote: > Which says get the template from the file system at that location and > don't ask for it from Postorius at all. This would be the default > action if there were no entry for this template in the > mailman.template table at all. I.e. you now have a template in > Postorius, but it is not used. I have jumped the gun on thinking that the template as a file was working. It's not. It's the same story: the initial file template is good, but it's for sure getting cached somewhere, and an updated file is ignored. The same as when the template was being drawn from the database. Restarting mailman3 and mailmanweb didn't help, neither did rebooting the server. Looking at Gunicorn status, I see a failing connection to 127.0.0.1 which is the error message I was getting when adding a new subscriber - with the custom Welcome template in the database (which is why I moved it to file). 127.0.0.1 and locahost are in the ALLOWED_HOSTS and CSRF_TRUSTED_ORIGINS of the settings.py file I'm at a loss with this caching problem. Any other clues happily received. $ gunicorn --version gunicorn (version 21.2.0) $ gunicorn status [2025-05-29 02:29:41 +0000] [17838] [INFO] Starting gunicorn 21.2.0 [2025-05-29 02:29:41 +0000] [17838] [ERROR] Connection in use: ('127.0.0.1', 8000) [2025-05-29 02:29:41 +0000] [17838] [ERROR] Retrying in 1 second. [2025-05-29 02:29:42 +0000] [17838] [ERROR] Connection in use: ('127.0.0.1', 8000) # ps -ef | grep gunicorn root 1522331 1521736 0 22:57 pts/1 00:00:00 grep gunicorn mailman 1608073 1 0 May20 ? 00:01:24 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/gunicorn -c /etc/mailman3/gunicorn.conf mailman_web.wsgi:application mailman 1608075 1608073 1 May20 ? 02:24:20 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/gunicorn -c /etc/mailman3/gunicorn.conf mailman_web.wsgi:application

1 year, 1 month

[MM3-users] Re: Problem with digests not being sent daily

by Mark

On 2024-06-22 00:04, Mark Sapiro wrote: >>>> ...The mmdf files don't exist in the list's directory although there >>>> have been many posts to the list throughout the day. > If you look at some point prior to 22:30, are there > /opt/mailman/mm/var/lists/<list_id>/digests.mmdf files at that time? > and if so, what happins if you run `mailman digests --periodic` > manually at that point? I changed the digest and notify crons to 05:00. 0 5 * * * @daily /opt/mailman/venv/bin/mailman digests --periodic 0 5 * * * @daily /opt/mailman/venv/bin/mailman notify At ~04:50 I posted an email to the list. The message was delivered to members and archived. Nothing showed up in /opt/mailman/mm/var/lists/<LISTID> # cd /opt/mailman/mm/var/lists/<LISTID> # ls -la total 8 drwxr-xr-x 2 mailman mailman 4096 Jun 22 04:52 . drwxr-xr-x 6 mailman mailman 4096 Mar 25 21:32 .. Then, as "mailman", I ran "mailman digests --periodic" manually and got the same error (as expected since there is nothing there) ... $ /opt/mailman/venv/bin/mailman digests --periodic Traceback (most recent call last): File "/opt/mailman/venv/bin/mailman", line 8, in <module> sys.exit(main()) ^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/click/core.py", line 1157, in __call__ return self.main(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/click/core.py", line 1078, in main rv = self.invoke(ctx) ^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/mailman/bin/mailman.py", line 69, in invoke return super().invoke(ctx) ^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/click/core.py", line 1688, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/click/core.py", line 1434, in invoke return ctx.invoke(self.callback, **ctx.params) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/click/core.py", line 783, in invoke return __callback(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/click/decorators.py", line 33, in new_func return f(get_current_context(), *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/mailman/commands/cli_digests.py", line 126, in digests maybe_send_digest_now(mlist, force=True) File "/opt/mailman/venv/lib/python3.11/site-packages/mailman/app/digests.py", line 106, in maybe_send_digest_now os.rename(mailbox_path, mailbox_dest) FileNotFoundError: [Errno 2] No such file or directory: '/opt/mailman/mm/var/lists/<LISTID>/digest.mmdf' -> '/opt/mailman/mm/var/lists/<LISTID>/digest.6.3.mmdf'

2 years, 1 month

[MM3-users] Re: Disabling Mass operations

by iMark

> On 1/23/26 17:39, iMark wrote: >> Hi All, >> >> Can anyone give me a pointer on disabling "Mass operations" >> (subscribe/removal) in Postorius. >> >> Just removing the menu link from the list-owners administration pages >> would be a good start. On 2026-01-24 02:01, Mark Sapiro wrote: > > This patch will do that > ``` > --- a/src/postorius/templates/postorius/menu/list_nav.html > +++ b/src/postorius/templates/postorius/menu/list_nav.html > @@ -84,6 +84,7 @@ > {% if user.is_superuser or user.is_list_owner %} > <li class="nav-item"><a href="{% url 'list_template_list' > list.list_id %}" class="nav-link {% nav_active_class current > 'templates' %}">{% trans 'Templates' %}</a></li> > <li class="nav-item"><a href="{% url 'list_settings' > list.list_id %}" class="nav-link {% nav_active_class current > 'list_settings' %} ">{% trans 'Settings' %}</a></li> > + {% if user.is_superuser %} > <li class="dropdown nav-item"> > <a href="#" class="{% nav_active_class current > 'list_mass_ops' %} dropdown-toggle nav-link" data-bs-toggle="dropdown" > role="button" aria-haspopup="true" > aria-expanded="false"> > @@ -98,6 +99,7 @@ > <li><a href="{% url 'mass_removal' list.list_id %}" > class="dropdown-item">{% trans 'Mass removal' %}</a></li> > </noscript> > </li> > + {% endif %} > <li class="nav-item"><a href="{% url 'list_bans' > list.list_id %}" class="{% nav_active_class current 'list_bans' %} > nav-link">{% trans 'Ban List' %}</a></li> > <li class="nav-item"><a href="{% url 'list_header_matches' > list.list_id %}" class="nav-link {% nav_active_class current > 'list_header_matches' %}">{% trans 'Header filters' %}</a></li> > <li class="nav-item"><a href="{% url 'list_delete' > list.list_id %}" class="{% nav_active_class current 'list_delete' %} > nav-link">{% trans 'Delete' %}</a></li> > ``` > Some lines in the above may be wrapped but basically it just adds > > {% if user.is_superuser %} > > and > > {% endif %} > > around the Mass operations code. > Thank you very much Mark. That is perfect. /opt/mailman/venv/lib/python3.11/site-packages/postorius/templates/postorius/menu/list_nav.html Cheers.

6 months

Search results for query "sapiro"