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

2 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

3 years, 5 months

[MM3-users] Re: Fwd: [Django] ERROR (EXTERNAL IP): Internal Server Error: /archives/search

by Dave Hall

Hello, Please pardon a slightly off-topic comment, but I would like to highlight a part of Odhiambo's post. Heavily nested inline replies also reflect the issue I wish to comment on, so I'm not going to. Granted, I am a slow learner, and perhaps already so mixed up after reading > the myriad HOWTOs for > installing MM3 that are available online. I am tempted to say there are > many like me who are likely to > miss "where to obtain" other settings from. and > Is it possible to modify the documentation to somehow make it obvious (in a > language that a layman can easily understand, I have seen this with several open source projects lately. There's no big picture, just 'hundreds' of cross-linked little bits of disjointed information that almost seem like documentation for individual modules. I once joined a large commercial project for a major US computer company (sorry, I won't share details). They were quite proud of their extensive documentation. The docs for their equivalent of the kernel syscall interface, when printed (two-sided) and stacked, would easily approach 2 meters tall. Yet, every bit of it was incomprehensible unless and until you called the developer and had them explain it to you. The problem that we all have, us humans, is that when we are very familiar with something, like the code we've been working on, it is very hard to describe its purpose to somebody who knows nothing about it. ("It's obvious to me, so it should be obvious to you."). So, a challenge for us all: When writing and reviewing your documentation, imagine that you're explaining your whole project face-to-face to your grandmother, or to anybody who never learned to program. From experience I promise that it's easy once you get the hang of it. Thank you and sorry for the speech. -Dave -- Dave Hall Binghamton University On Sat, Jan 28, 2023 at 2:54 AM Odhiambo Washington <odhiambo(a)gmail.com> wrote: > On Fri, Jan 27, 2023 at 9:34 PM Mark Sapiro <mark(a)msapiro.net> wrote: > > > On 1/27/23 05:53, Odhiambo Washington wrote: > > > On Mon, Jan 23, 2023 at 11:48 PM Mark Sapiro <mark(a)msapiro.net> wrote: > > >> > > >> Note that when following > > >> https://docs.mailman3.org/en/latest/install/virtualenv.html you > create > > >> /etc/mailman3/settings.py and it contains > > >> ``` > > >> from mailman_web.settings.base import * > > >> from mailman_web.settings.mailman import * > > >> ``` > > >> to establish a base set of settings that can be augmented or > overridden > > >> in /etc/mailman3/settings.py. mailman_web.settings.mailman in turn > > contains > > >> ``` > > >> HAYSTACK_CONNECTIONS = { > > >> 'default': { > > >> 'ENGINE': 'haystack.backends.whoosh_backend.WhooshEngine', > > >> 'PATH': "fulltext_index", > > >> ``` > > >> which is a relative path for fulltext_index and may need to be set to > an > > >> absolute path. > > >> > > > > > > Mi Mark, > > > > > > I have read this page - > > > https://docs.mailman3.org/en/latest/install/virtualenv.html and > further > > - > > > > > > https://docs.mailman3.org/en/latest/install/virtualenv.html#initial-config > > > - without clicking any external links. > > > I still don't see the HAYSTACK_CONNECTIONS in the settings.py included > > on > > > that page. > > > I am missing something obvious, no? > > > > > > Please reread what I wrote above. HAYSTACK_CONNECTIONS is not in the > > suggested settings.py but it is in mailman_web.settings.mailman and is > > imported by the suggested settings.py. > > > I have reread what you wrote now and I'm beginning to get the hang of this > method. > My observation is that it can only be _obvious_ to someone very familiar > with Python config > to decipher that *additional* settings *that can be augmented or > overridden > in /etc/mailman3/settings.py* can be obtained from: > /PATH-TO/mailman_web/settings/{base|mailman}.py after they have noticed > these two lines in > the sample settings given in /etc/mailman3/settings.py: > > from mailman_web.settings.base import *from > mailman_web.settings.mailman import * > > [At first instance, it is not obvious that mailman_web.settings.base and > mailman_web.settings.mailman are > actually paths in Python - which magically translates to > mailman_web/settings/base.py and mailman_web/settings/mailman.py] > Granted, I am a slow learner, and perhaps already so mixed up after reading > the myriad HOWTOs for > installing MM3 that are available online. I am tempted to say there are > many like me who are likely to > miss "where to obtain" other settings from. > For example, my mind all along has been tuned to having a settings_local.py > for overriding the settings.py. > However, with this particular documentation, it would appear that > everything is intended to just go into /etc/mailman3/settings.py. > > Is it possible to modify the documentation to somehow make it obvious (in a > language that a layman can easily understand, > that those two "import *" _DO establish a base set of settings that can be > augmented or overridden in /etc/mailman3/settings.py_ > and that those settings are in what file(s) ? > > I am not saying @Johannes Rohr <johannes(a)rohr.org> is a layman like me, > but > I think that is what hit him. > > > -- > Best regards, > Odhiambo WASHINGTON, > Nairobi,KE > +254 7 3200 0004/+254 7 2274 3223 > "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) > _______________________________________________ > 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 kdhall(a)binghamton.edu >

2 years, 5 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

1 year, 3 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

2 years, 5 months

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

1 year, 4 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/

4 years, 2 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 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'

1 year

[MM3-users] Re: moving list from mm3 -> mm3

by Jens Günther

Thanks Mark for our answers, I already got a bit further. Am 09.12.23 um 00:27 schrieb Mark Sapiro: >> But it returns {"title": "405 Method Not Allowed"} and I don't know >> where to look in the docs, since it shows almost always a way through >> mailman shell. > You need a PUT command, not POST. Try the above with `-X PUT`. With the `-X PUT`-command, there is the following error: {"title": "400 Bad Request", "description": "Unexpected parameters: bounces_address, created_at, digest_last_sent_at, fqdn_listname, http_etag, join_address, last_post_at, leave_address, list_name, mail_host, next_digest_number, no_reply_address, owner_address, post_id, posting_address, request_address, usenet_watermark, volume"} -> I don't know why, since I tried it with the exact same example-list from where I got all these parameters (ex- and then import) ... do I still miss something? Or does it only work on "fresh" lists? > You can use Postorius -> Mass operations -> Mass subscribe to add the > members, but you can't do that for owners and moderators. Also you lose > information about the members such as Delivery status, Delivery mode and > other user settings. Is there another way to preserve these information about the members? (in general I don't think a lot of people put in effort to customize there memeberships ... and furthermore they would need to register, right?) >> ## registered users > > That is not the answer. Those are Mailman core users, not Django (web > login) users. You need to get the relevant entries from the auth_users > and account_emailaddress tables and add them to the new DB. Ok, that would be fine. Are there any more relations to other tables/columns that need to be set? (I just realised, that there are 2 different id in each table ... the one in auth_users is the user_id in account_emailaddress :-) scary). Do you have any suggestions on how to add them correctly? Thank you in advance for now and another big one in general to all of you on this list that try to help continouisly with all these problems. It's a great pleasure to be able to ask for help on a list like that. Thank you! Have a good rest of the year. Regards, Jens.

1 year, 6 months

Search results for query "sapiro"