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

[MM3-users] Re: Permission denied for fulltext_index

by Jan Eden

On 2022-11-30 10:22, Mark Sapiro wrote: > On 11/30/22 08:41, Jan Eden via Mailman-users wrote: > > > > Changing the PATH value to a full path (/opt/mailman/fulltext_index) > > and restarting mailman-web generates a different error: > > > Yes, it should be a full path. I encountered yet another problem with emails not getting archived anymore: > ERROR 2022-12-01 09:18:00,111 1337915 hyperkitty.views.mailman Access to the archiving API endpoint was forbidden from IP XXX.XXX.XXX.XXX, your MAILMAN_ARCHIVER_FROM setting may be misconfigured where XXX.XXX.XXX.XXX is my server's public IP. This was probably caused by the switch to uwsgi_pass/a file socket, and could be fixed by adding MAILMAN_ARCHIVER_FROM = ('XXX.XXX.XXX.XXX', '::1') to /etc/mailman3/settings.py. > > > ERROR 2022-11-30 16:38:37,953 1028315 django.request Internal Server Error: /archives/list/testing@lists.eden.one/thread/T6MCILAVQYV5QIOGHJB3JNJ26Z7E2Z35/reattach-suggest > > > Traceback (most recent call last): > > > File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/exception.py", line 55, in inner > > > response = get_response(request) > > > File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/base.py", line 197, in _get_response > > > response = wrapped_callback(request, *callback_args, **callback_kwargs) > > > File "/opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/lib/view_helpers.py", line 137, in inner > > > return func(request, *args, **kwargs) > > > File "/opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/views/thread.py", line 454, in reattach_suggest > > > sugg_thread = msg.object.thread > > > AttributeError: 'NoneType' object has no attribute 'thread' > > > This says that searching the archive for this list for messages matching the > current message subject returns None. It is probably a bug that we don't > test for this, but what exactly are you doing? > See the post at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > for the only way I've been able to create an error like this. There are currently 5 (test) threads in the archive. After changing the PATH in the HAYSTACK_CONNECTIONS dict to /opt/mailman/fulltext_index, and fixing the issue with MAILMAN_ARCHIVER_FROM above, /opt/mailman/web/logs/mailmanweb.log does not display new error messages, but I do not get any suggestions for reattaching threads, and a search for a specific thread subject ("Third test") does not return any results. So reattachment works in principle, but the suggest/search function does not. - Jan

2 years, 7 months

[MM3-users] Re: Errors while importing mm2 list archives - SOLVED

by Odhiambo Washington

On Tue, Dec 20, 2022 at 8:32 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 12/20/22 06:48, Odhiambo Washington wrote: > > > > There is a WARNING on > > > https://docs.list.org/en/latest/install/virtualenv.html#virtualenv-install > > which says one must create the config file as /etc/mailman3/mailman.cfg > > How to force mailman to read that file is something I haven't understood, > > but turns out to be what has taken me days trying to get things right. > > > If you run the `mailman` command without any -C option, it will look for > a config in /etc/mailman3/mailman.cfg > In my case, running `mailman` without any arguments just makes it grok :) (venv) [mailman@gw ~/mm]$ mailman info GNU Mailman 3.3.7 (Tom Sawyer) Python 3.9.15 (main, Dec 6 2022, 09:25:59) [Clang 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a *config file: /opt/mailman/mm/mailman.cfg* db url: mysql+pymysql://mailman_user:XXXXXXXX@localhost /mailman3db?charset=utf8mb4&use_unicode=1 devmode: DISABLED REST root url: https://localhost:8001/3.1/ REST credentials: restadmin:restpass (venv) [mailman@gw ~/mm]$ mailman Usage: mailman [OPTIONS] COMMAND [ARGS]... The GNU Mailman mailing list management system Copyright 1998-2018 by the Free Software Foundation, Inc. http://www.list.org Options: --version Show the version and exit. --run-as-root Running mailman commands as root is not recommended and mailman will refuse to run as root unless this option is specified. -C, --config FILE Configuration file to use. If not given, the environment variable MAILMAN_CONFIG_FILE is consulted and used if set. If neither are given, a default configuration file is loaded. -h, --help Show this message and exit. .... > Ultimately, when I did the import, there was only one email from the > > archives that failed to be imported - which I honestly don't mind, but > > maybe there is a solution for this > > "'utf-8' codec can't encode character '\udcae' in position 331: > surrogates > > not allowed" ?? > > > If you provide a copy of that message from the mbox, either on the list > or to me directly, I'll investigate. > A mbox file containing that email and the associated thread can be downloaded from here: https://webmail.kictanet.or.ke/~wash/chunk_7.txt.gz -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

2 years, 6 months

[MM3-users] Re: Turn off social logins?

by Abhilash Raj

This is kind of a top-post, because I am not sure which message should my reply quote. Please excuse that part. My thinking on this topic resonates with what Steve said, I don't think we should be forcing the Mailman Administrators to handle username passwords. Dare I say that most social auth providers have more incentive and money to keep their database secure than Mailman Administrators. Having said that, it doesn't have to be either or between "social logins enabled by default" and "I don't want to see a Facebook button". I have actually thought about this before, but never have been able to get to it. I opened an issue too but can't find it right now. Anyway, so the idea is that most social providers need some soft of configuration from the Admin. Today, we enable them by default, but they don't work by default. I think we could make both sides happy if we were to just not show the social providers that aren't configured. What do others think? Only two providers that I know of in Mailman's default list, which don't need any configuration, are Fedora and OpenID. I am happy to remove OpenID from default since I have never been able to actually get that to work. I am okay with removing Fedora too, which is a special case in Mailman 3 because of fedoralists.org being the first customer for Mailman 3 and Hyperkitty. I don't have cycles to do that myself right now, so I would encourage people to step up to tackle this. I would obviously help them out with any Python, Mailman or Django related questions they might have. Now, about the ease of being able to disable social logins, I think it should be possible to disable social logins with just a boolean flag in settings. Why haven't we done it yet? We didn't need to. What we provided was a **sample configuration**, with a huge emphasis on sample. We weren't maintaining it as an official set of configurations, but just something that one could use as a starting point. But that obviously didn't happen since people just downloaded and used it, some of which is ofc my own fault since the official docs doesn't say that what precisely you should be worried about changing from the sample. The beauty (and ugliness) of Django's settings.py is that it is Python. We can disable social login if your CPU heats up[1], or if the stock price of the company goes below (or above? :P) a threshold, or heck, if the network firewall detects a packet heading out to their servers. How Django's configuration works has been left kind-of open by the Django devs themselves, making every downstream project handle their own use case separately. We chose to just go with what was provided out of box, but that doesn't mean we can't do any better. We can do ini-style configs, it gets a tad bit complicated when there are unknown Python data structures that can't easily be represented in ini-style. We could do YAML, which supports more complicated data structures (nested maps and lists). OR, we could do JSON, but I find that less human readable. Next topic, people worrying about customizing settings in settings_local.py and worrying about not getting newer updates. Isn't this how rest of the packaging and configuration world works? If you customize the `/etc/postfix/main.cf` you don't get the updates to default config (apt asks you, but you will choose not to update with your custom settings, right?) when you upgrade your postfix package from Debian and you need to pull in any new settings that package supports manually. I have been (silently) working[2] on making the `mailman_suite` project a Python package (mailman3-web), like the Debian Maintainers did. That would be the right place to put whatever configuration logic we want to expose to our users. We can move to a model where you'd import all the settings from `mailman3_web.settings.base` and then customize all the fields that you do care about. But there will be downsides to it, like us updating a setting that changes the behavior of an already working site, and we can sure document those changes in release notes in big bold letters, but I still worry there will be people running `pip install -U` without thinking what does that even mean. I don't know what should we do? What do other people managing configurations do? Maybe Debian Maintainers can chime in here? [1]: https://xkcd.com/1172/ [2]: https://gitlab.com/maxking/mailman-suite/commits/master On Fri, Feb 15, 2019, at 8:43 AM, Mark Sapiro wrote: > On 2/14/19 11:10 PM, Stephen J. Turnbull wrote: > > Torge Riedel writes: > > > > > - there is a way to do this now via settings_local.py, but feels > > > a little bit risky if default configuration changes on update of > > > mailman > > > > This should not be true. If it is, we need to fix that. Will check. > > > It is more or less true. The issue is that unlike mm_cfg.py and > Defaults.py in Mailman 2.1, the recommended way to set up Django in > Mailman 3 is to point Django at settings.py for the default config, and > the last thing in settings.py is > > try: > from settings_local import * > except ImportError: > pass > > Thus,the only way settings_local.py can change something like > INSTALLED_APPS is to redefine INSTALLED_APPS in it's entirety which > leads to the possibility of INSTALLED_APPS changing in settings.py and > those changes not being picked up in settings_local.py. > > The way around this is to remove the import of settings_local from > settings.py and then put > > from settings import * > > at the beginning of settings_local.py and then point Django at > settings_local rather than settings. > > Then you can do things like > > try: > INSTALLED_APPS.remove('allauth.socialaccount.providers.google') > except ValueError: > pass > > in settings_local.py except there are still issues because, e.g., > INSTALLED_APPS is defined as a tuple (immutable) and not a list in > settings.py. > > -- > 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/ > -- thanks, Abhilash Raj (maxking)

6 years, 4 months

[MM3-users] Re: Default values for lists in Mailman 3

by Markus Grandpré

Thank you very much for your answer. Best regards, Markus Am 19.09.24 um 22:03 schrieb Mark Sapiro: > On 9/19/24 05:46, Markus Grandpré wrote: >> Dear list, >> >> I would like to activate the invitation setting for all lists as >> default. In Mailman 2.1 I have done this in the file </etc/mailman/ >> mm_cfg.py>: >> >> >> DEFAULT_SUBSCRIBE_OR_INVITE = Yes >> >> >> How can I do this in Mailman 3? > > There is a draft merge request at https://gitlab.com/mailman/ > postorius/-/merge_requests/930 which implements a framework for setting > Postorius defaults and creates a setting to set the default for pre- > verified on the mass subscription page. Once merged, this can easily be > extended to provide a default for Invitation. > > In the mean time, you can only do this by patching src/postorius/forms/ > list_forms.py like > ``` > --- a/src/postorius/forms/list_forms.py > +++ b/src/postorius/forms/list_forms.py > @@ -1283,7 +1283,7 @@ class ListMassSubscription(forms.Form): > > invitation = forms.BooleanField( > label=_('Invitation'), > - initial=False, > + initial=True, > required=False, > help_text=_( > 'If checked, the other checkboxes are ignored and the > users will ' > ``` >> Can I also transfer other default values like: >> >> ... >> DEFAULT_SERVER_LANGUAGE = 'en' >> DEFAULT_SEND_REMINDERS = 1 >> DEFAULT_SUBSCRIBE_OR_INVITE = Yes >> DEFAULT_PRIVATE_ROSTER = 2 >> DEFAULT_ARCHIVE = Off >> DEFAULT_ARCHIVE_PRIVATE = 1 >> ... >> >> from the very same configuration file to Mailman 3? Is there a >> documentation of the default values for lists in Mailman 3? > > This is done by creating a list style with the desired defaults. See > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/styles/ > docs/styles.html for documentation of styles and see https://gitlab.com/ > mailman/example-mailman-plugin for an example of creating a plugin in > Mailman core to make a persistent style. > > There is no specific doc for the list settings. You need to look at > https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/styles/ > base.py for the various settings and https://gitlab.com/mailman/ > mailman/-/blob/master/src/mailman/styles/default.py to see which default > classes are applied for various styles. > -- Markus Ludwig Grandpré Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre, B803, Tel: ++49 7531 88 4342

9 months, 2 weeks

[MM3-users] Re: Issues with @gmail.com addresses

by Allan Hansen

Once this gets handled, Mohsen, Google has another issue with list servers: If a subscriber who uses GMail posts a message to a list, then that subscriber will not get his/her own message from the server - Google eats it. All other subscribers will get it, but not the author. My subscribers run into this all the time and are up in arms over it. I tell them to complain to Google. Yours, Allan On 9/5/23, 13:18, "Mark Sapiro" <mark(a)msapiro.net <mailto:mark@msapiro.net>> wrote: On 9/5/23 12:59, Mohsen Masoudfar wrote: > Hi, > > since 8/1/2023 I get complains from users with @gmail.com addresses, that they are not getting any emails. > I checked the logs and I see that the emails are going out: > > to=<xxxx(a)gmail.com <mailto:xxxx@gmail.com>>, relay=email-smtp.us-east-1.amazonaws.com[35.169.171.20]:587, delay=0.46, delays=0.03/0.06/0.13/0.24, dsn=2.0.0, status=sent (250 Ok xxx ) > > But it seems the users are getting email delivered to them. > I’ve advised them to check their spam, promotions, and social folders and to add the list address to their email safe-senders lists, but still no success. > Is there any way to help this list members? Even though gmail publishes a DMARC policy of none, it has recently started enforcing a stricter policy for mail From: the gmail.com domain. You need to apply DMARC mitigations to mail From: the gmail.com domain. There are two ways to do this. One way is to set DMARC Mitigations -> DMARC Mitigate unconditionally to Yes (and set DMARC mitigation action appropriately) The other way requires upgrading Postorius and Mailman core to the heads of the GitLab branches (core=3.3.9b1, postorius=1.3.9b1). Doing this enables a DMARC Addresses setting which can be set to `^.*(a)gmail\.com$` to apply DMARC mitigatations to mail From: the gmail.com domain regardless of it's published policy. -- Mark Sapiro <mark(a)msapiro.net <mailto:mark@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 <mailto:mailman-users@mailman3.org> To unsubscribe send an email to mailman-users-leave(a)mailman3.org <mailto:mailman-users-leave@mailman3.org> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/> Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org <mailto:mailman-users@mailman3.org>/message/WZY5IC3OVHVBHIGDT4TE3EWSSGMF6CYI/ This message sent to hansen(a)rc.org <mailto:hansen@rc.org>

1 year, 9 months

[MM3-users] Re: spanish localization

by Victoriano Giralt

On Fri, 2021-02-12 at 09:04 +0100, Guillermo Hernandez (Oldno7) via Mailman-users wrote: > On 11/2/21 20:15, Mark Sapiro wrote: > > On 2/11/21 3:47 AM, Guillermo Hernandez (Oldno7) via Mailman-users > > wrote: > > > I contributed in january to translate to spanish all the items > > > left in > > > Mailman Core, Django-mailman, HyperKitty and Postorius via > > > Weblate. I > > > thought they will be used in the next upgrade, but I cannot see > > > any > > > improvement and there are many words untranslated. > > > > The Spanish translations for Mailman core and HyperKitty are > > currently > > completely up to date with weblate. django-mailman3 differs in one > > string that was translated on Feb 10 and hasn't yet been merged. > > Postorius also differs in a few places from the Feb 10 version that > > hasn't yet been merged. > > Ok. Thanks for checking it. I put my little contribution in Weblate > and I like that it could be used by anyone. Actually, I was going to ask these same questions, because I dedicated some hours to get the Spanish translation nearly finished, it was kind of a "spiritual" need for me, being the person that seeded the efforts for Mailman i18n support back in the late '90s :-) :-) > I tried to run this using the same command as I did for the > "collectstatic" (that solved all my previous problems for the > upgrade) > and "migrate" runs but it shows me an error: > > su -m mailman3 -c "python3 manage.py compilemessages" > CommandError: This script should be run from the Django Git checkout > or your project or app tree, or with the settings module specified. I got this very same error, and was also confused, as manage.py runs at the project level, not application level. > I'm lost. Do not feel bad, Guillermo, an old time pythonist with message translations experience, that uses i18n for some of his applications, is also dazzled and confused :-) Confused-with-translations-ly, Victoriano. -- Victoriano Giralt Innovation Director Digital Transformation Vicerectorate University of Malaga +34952131415 SPAIN ================================================================== Note: signature.asc is the electronic signature of present message A: Yes. > Q: Are you sure ? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email ?

4 years, 4 months

[MM3-users] Re: user mail not accepted

by Christian Stalberg

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.ccalternatives.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.ccalternativ es.org>' Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) recip: ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.ccalternatives.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' 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: 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-companies-lo bbying-donation-defeated-regulation -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Monday, April 26, 2021 2:05 PM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: user mail not accepted On 4/26/21 5:16 AM, Christian Stalberg via Mailman-users wrote: > I have a user whose moderation rule is 'Accept immediately' yet when > they send a message for distribution to the list, they only receive it > and it is not distributed via the list. Logfile entries below. Please > advise. Btw I have another list on this same instance which is running fine. Thank you. > > [26/Apr/2021:12:06:25 +0000] "GET > /3.1/lists/ssan.lists.ccalternatives.org > HTTP/1.1" 200 453 "-" "GNU Mailman REST client v3.3.2" > [26/Apr/2021:12:06:25 +0000] "POST > /3.1/members/find?list_id=ssan.lists.ccalternatives.org&subscriber=chr > istian %40sewagesludgeactionnetwork.com HTTP/1.1" 200 1257 "-" "GNU > Mailman REST client v3.3.2" > [26/Apr/2021:12:06:25 +0000] "PATCH > /3.1/members/7186cd45bde34d4fa7e7b5ab36b97272 HTTP/1.1" 204 0 "-" "GNU > Mailman REST client v3.3.2" > [26/Apr/2021:12:06:26 +0000] "GET > /3.1/lists/ssan.lists.ccalternatives.org > HTTP/1.1" 200 453 "-" "GNU Mailman REST client v3.3.2" > [26/Apr/2021:12:06:26 +0000] "POST > /3.1/members/find?list_id=ssan.lists.ccalternatives.org&subscriber=chr > istian %40sewagesludgeactionnetwork.com HTTP/1.1" 200 1288 "-" "GNU > Mailman REST client v3.3.2" > [26/Apr/2021:12:06:26 +0000] "GET > /3.1/lists/ssan(a)lists.ccalternatives.org/requests/count?token_owner=mo > derato r HTTP/1.1" 200 73 "-" "GNU Mailman REST client v3.3.2" > [26/Apr/2021:12:06:26 +0000] "GET > /3.1/lists/ssan(a)lists.ccalternatives.org/held/count HTTP/1.1" 200 73 "-" > "GNU Mailman REST client v3.3.2" > [26/Apr/2021:12:06:26 +0000] "GET > /3.1/members/7186cd45bde34d4fa7e7b5ab36b97272/preferences HTTP/1.1" > 200 295 "-" "GNU Mailman REST client v3.3.2" These entries don't tell anything about a post to the list. They are all from Mailman's REST API relating to Postorius interactions with core. However the absence of messages like Apr 26 07:32:39 2021 (17860) ACCEPT: <message_id> and Apr 26 07:32:41 2021 (17857) HyperKitty archived message <message_id> to https://example.com/archives/list/list_adderss/message/message_id_hash/ assuming you are looking at the correct time span, says there wasn't an accepted list post. Mailman's smtp.log may have more info, but the complete, raw message that the user receives may be more helpful. -- 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: Problems after upgrading from bullseye to bookworm

by Odhiambo Washington

The virtualenv documentation works just fine with Bookworm AFAICT. I didn't need to do anything out of the documentation in my test VM. On Tue, 27 Jun 2023, 18:04 Eggert Ehmke via Mailman-users, < mailman-users(a)mailman3.org> wrote: > Hello Mark, > > thank you. I did change that entries, and now my mailman runs fine on > Debian Bookworm. > > I did a complete reinstall of the venv directory to have a clean start. > Maybe this was not > needed. What's missing in the documentation: > -the directiories web/logs have to be created manually with the ownership > mailman. > -The debian package pkg-config must be installed. > -the package psycopg2-binary can/must be installed without version > restriction on > Bookworm > Maybe this info helps some other people. > > Cheers, Eggert > > Am Montag, 26. Juni 2023, 22:22:37 CEST schrieb Mark Sapiro: > > On 6/26/23 12:35 PM, Ken Alker wrote: > > > I'm brand new to this, so take this with a grain of sale, but, I had a > > > similar problem a few days ago, however, mine was "flufl.i18n>=3.2". > > > Perhaps the same thing is happening with flufl.lock (but that didn't > bite > > > me). > > > > > > I solved my problem by following this: > > > <https://gitlab.com/mailman/mailman/-/issues/1085> and, ultimately > > > modifying > > > > "$VENV_ROOT/lib/$PYVERSION/site-packages/mailman-3.3.8.egg-info/requires. > > > txt" per that thread (see > > > <https://gitlab.com/mailman/mailman/-/issues/1085#note_1442207929> by > > > Thomas Ward section called "The WORKAROUND"). Maybe you need to do the > > > same thing, but for flufl.lock. > > Yes, the same issue now affects flufl.lock as well as flufl.i18n. You > > will need to change both flufl.lock->flufl_lock and > flufl.i18n->flufl_i18n. > > > > ___________________________________________ > Mailman's content filtering has removed the > following MIME parts from this message. > > Replaced multipart/alternative part with first alternative. > _______________________________________________ > 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 odhiambo(a)gmail.com >

2 years

[MM3-users] Re: Member Issue Discovered

by Brian Carpenter

On 10/19/20 9:04 PM, Mark Sapiro wrote: > I suppose it could be considered a bug, but what's happening is your > initial subscribe created a user and and address and set the user's > preferred address to the created address. It also set the display_name > of the address and it subscribed the user to the list or possibly the > address to the list depending on what actually did the subscribe. > > When the user/address was unsubscribed, it is removed from the list's > membership and the list was removed from the user's memberships, but the > user and address still existed. > > Then when you resubscribed, the existing user/address was made a member > of the list, but not updated so the "new" display_name was ignored. I > think this is also the case if the original address had no display_name. > > You could say this is a bug and the display_name associated with this > new subscription should replace the prior one, but what if that address > was subscribed to other lists and didn't want the display_name changed > on those lists. > > Ideally (perhaps) there could be multiple address records with the same > email address and different display_names, but address records are keyed > by email address, so this can't be. > > One workaround would be for a user who wanted to have an address with > different display_names for different lists to have multiple addresses > likeaddress+list1@example.com,address+list2@example.com, etc. > > Is this really an issue that should be fixed or just a curiosity? No. No. No. No one set their preferred address here at all. The first incident was an imported list member who was not a registered user. They wanted their real name changed to something else. The list owner tried to figured out how to do that, found no way to do it, figured out it was just easier to unsubscribe them, and resubscribed them to the list using a different name. The old name showed up again. This is a bug and please fix it soon. This has nothing to do with being subscribed to other lists. I can probably come up with a workaround using Affinity (one of the benefits of moving away from Postorius) but I can't imagine this not being a serious issue as Mailman 3/Postorius is more widely adopted. -- Brian Carpenter Harmonylists.com Emwd.com

4 years, 8 months

[MM3-users] Re: Mailman, etc. upgrade woes and persistent bugs

by Abhilash Raj

On Fri, Feb 12, 2021, at 11:52 AM, Mark Sapiro wrote: > On 2/11/21 10:22 PM, hansen(a)rc.org wrote: > > I just had my Mailman suite upgraded. When it got started, I starting receiving messages that hundreds of subscribers to the lists had been disables, including several of the list moderators. This version started supporting bounce processing, but how in the world was this upgrade allowed to act on bounces that were being collected PRIOR to enabling bounce processing?? > > > I'm sorry about that. It's too late now, but the avoidance is discussed > at > <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…>. > > > > I got many angry emails, messages and phone calls asking what was going on, as they were bona fide list members. I was very surprised myself. > > > > I then looked at several of the disabled accounts, but the subscription info page in Postorius had no information about whether an account was enabled or disabled. Why is this not displayed???. The members can't see if their account is enabled. Is this another example of the disconnect between Mailman and Postorius? > > > If the user has a Django account, she can see all that info at (e.g. for > this list) <https://lists.mailman3.org/mailman3/accounts/subscriptions/> > She gets there from `Mailman settings` in the dropdown under her user > name. She can also get there via the `Manage Subscription` button on the > list's Info page. That takes her to `List-based preferences` for the > list. Any setting not selected there is inherited from the Address-based > preferences or Global Mailman preferences IIUC, I think what Allan is trying to point out is that if your account was disabled due to bounces, there is no real visual indication about that if you go to any of the Preferences pages (either, Global preferences, List based preferences of address based preferences). Even if you login as an admin and go to Member Option's view, you won't see any visual indication about the delivery being disabled. The is definitely a bug, caused due to the fact that "Delivery Status" field only has two options, "Enabled" and "Disabled". Internally, this field can have 4 values, "enabled", "by_user" (maps to "Disabled" in Postorius), "by_admin" (means disabled by admin) and "by_bounces" (means disabled due to bounces). So, when the value of the field is among the last two options, it appears as "unset" with no options selected, which unfortunately is also how it looks by default since all options are "unset" from start. The "fix" for this issue would be simply adding a new choice to the delivery_status field with a caveat that it is only a Readonly option to see that delivery is disabled due to bounces and not choosable as a valid delivery_status value by user or admin when submitting the form. https://gitlab.com/mailman/postorius/-/issues/469 We could also go a step further and show it on the List's info page when their delivery is disabled due to excessive bounce and allow the them to re-enable it themselves without admin intervention. This would ofcourse show only when you log into your account and go to the list's info page, but I guess that is the first place you'd go to debug when you get an email that your delivery was disabled? https://gitlab.com/mailman/postorius/-/issues/470 I don't know if there are any downsides to letting users re-enable their delivery on their own. > > > > Further, even after the upgrade, the moderators still cannot access the list memberships even though all the lists are set to allow that. I would have asked the moderators to do this if this access bug had been fixed, but they can't get there. > > You've already reported this at > <https://gitlab.com/mailman/postorius/-/issues/462>, and it's been > previously reported at <https://gitlab.com/mailman/postorius/-/issues/369>. > > > > As a result of these bugs, after consulting with Brian, who helped with the upgrade, I spent many hours re-enabling the several hundred accounts that had been disabled. I had to go through each email notification to find the address of a disabled account, then find the list, then the member, in Postorius, and finally enable the account (at which time Postorius DID show the enabled status). > > > I'm sorry you had to go through this. The potential issue and the > avoidances should be better documented. Unfortunately, they aren't. > > > > Please, can the next upgrade include these very basic fixes/enhancements, which I requested a long time ago: > > > > a. The ability of moderators to see the list membership (a bug). > > As I note above, this is a known issue. We are a small project with very > feew core developers, all of whom are volunteers. There is a merge > request at <https://gitlab.com/mailman/postorius/-/merge_requests/423> > which purports to fix > <https://gitlab.com/mailman/postorius/-/issues/369>, but as you can see > from the comment thread, it is not complete and the author has > apparently disappeared. > > If you would like to take it over and address the deficiencies, we would > welcome that. > > > > b. The ability of members to change their addresses for all lists they are subscribed to. > > > Users can add addresses to their account and can then change their > subscribed address at (again, e.g. for this list) > <https://lists.mailman3.org/mailman3/accounts/list-options/mailman-users.mai…> > (Get there via the `Manage Subscription` button on the list's Info > page.) > > If one is subscribed to lists via their `primary` address, one can go to > `E-mail Addresses` in their account settings and make a new address > `primary` and that will change all their subscriptions. > > > > and further, now: > > > > c. That when members go to look at their subscription info, they can actually see the settings. > > > They can if they go to `Mailman settings` in the dropdown or the `Manage > Subscription` button on the list's Info page and look at all the tabs. > > -- > 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/ > -- thanks, Abhilash Raj (maxking)

4 years, 4 months

Search results for query "sapiro"