Search results for query "sapiro"
- 6281 messages
[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
3 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 '^$|^.*#' ¯\_(ツ)_/¯ :-)
3 years, 7 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)
7 years, 5 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
1 year, 10 months
[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>
2 years, 10 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 ?
5 years, 5 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/
5 years, 3 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
>
3 years
[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)
5 years, 5 months
[MM3-users] Re: mailman3 postorius cannot retrieve template
by Wolfgang Bock
Dear Mark,
you wrote:
"When you create a template in Postorius, that uri becomes something like
`https://example.com/mailman3/api/templates/list/<list_id>/<template_name>`
which basically says get the template from Postorius, and the template if
any in var/templates is ignored."
In my case that is not true.
I get an db-entry in the mailman3 table template which doesnt lead to a
suitable link:
https://localhost/postorius/api/templates/list/testliste01.mydomain.de/list:
member:regular:footer
In the next stept it leads to a flood of entries in my syslog because django
is asking for a certificate match for "localhost":
Nov 2 11:47:49 myserver mailman3[175334]: Nov 02 11:47:49 2021 (175334)
Certificate did not match expected hostname: localhost. Certificate: ...
Letsencrypt cannot deliver this match for "localhost", it is impossible to
configurate letsencrypt to do so.
The running script must create a postgres INSERT database command which
includes the correct domain-name including the correct path
.../mailman3/api/templates .... and not ... postorius/api/....
I dont know, where is the place to correct this.
- in mailman-web.py ??
...
ALLOWED_HOSTS ... '*'
or
MAILMAN_REST_API_URL = 'http://localhost:8001'
or
POSTORIUS_TEMPLATE_BASE_URL = 'https://localhost/mailman3/'
- in mailman.cfg ??
the [paths.debian] section
the [webservice] section
- or elsewhere
Thanks in advance for your reply.
Wolfgang
-----Ursprüngliche Nachricht-----
Von: Mark Sapiro <mark(a)msapiro.net>
Gesendet: Sonntag, 31. Oktober 2021 19:15
An: mailman-users(a)mailman3.org
Betreff: [MM3-users] Re: mailman3 postorius cannot retrieve template at ...
(<no authorization>)
On 10/29/21 3:41 AM, Wolfgang Bock via Mailman-users wrote:
>
> the question is: postgres - mailman3web-postorius_emailtemplate table
> vs
> mailman3 - templates table
>
> I installed a brand new mailman3 with mailman Core 3.3.3, Api 3.1,
> Core Python 3.9.2 postgres12 nginx on debian bullseye.
>
> I created a template via postorius -> lists -> (testliste01) ->
> templates
> -> new template -> [list:member:regular:footer] and
> [list:member:digest:footer]
>
> They are shown in the postgres database mailman3 table templates:
> id name context uri username password
> 14 list:member:digest:footer testliste01.mydomain.de
> http://localhost/postorius/api/templates/list/testliste01.mydomain.de/
> list:m
> ember:digest:footer
> 15 list:member:regular:footer testliste01.mydomain.de
> http://localhost/postorius/api/templates/list/testliste01.mydomain.de/
> list:m
> ember:regular:footer
>
> First there where no templates in the /var/lib/mailman3/templates
> folder, which was empty after installation.
This is expected. That is one place where you can put custom templates.
> Later I created in /var/lib/mailman3/templates theses folders and the
> files /list/testliste01.mydomain.de/list:member:digest:footer +
> list:member:regular:footer owned by list:list 644
>
> A testmail went through but instead of the default footer no footer
> was shown.
By default Mailman searches for templates first in the var/templates
directory and then in the templates directory in the Mailman installation.
The details are described at
https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/utilities/i18n.
py#L44.
However, the default search is only applied if there is matching entry for
the template name and context in the `templates` table in the database or if
the uri in the entry is a `mailman://` uri.
When you create a template in Postorius, that uri becomes something like
`https://example.com/mailman3/api/templates/list/<list_id>/<template_name>`
which basically says get the template from Postorius, and the template if
any in var/templates is ignored.
> In the sys.log I found the following error message:
> Oct 29 11:28:04 myserver mailman3[33015]: Message: 'Cannot retrieve
> template at
> http://localhost/postorius/api/templates/list/testliste01.mydomain.de/
> list:m ember:regular:footer (<no authorization>)'
So Mailman is trying to get the Postorius template. What is in the web
server logs for this retrieval?
> How can I solve this problem? What kind of authorisation is meant? list?
> restadmin?
>
> I read in
> https://docs.mailman3.org/en/latest/config-core.html#configure-templates
> ... list specific templates invar/templates/lists/LIST-ID/LC/ ...
> I guess the LC means Language Code. But in the database table templates no
> LC subdirectory is mentioned (in my case must be de).
If you delete the Postorius template, The entry in the templates table
will be removed and the search will revert to var/templates, etc.
> And I read (dont know where) .... The templates created in Postorius are
> created in the postorius_emailtemplate table in Mailman's database and
> referenced via URLs like
>
'https://example.com/mailman3/api/templates/list/<list-id>/<template-name>'.
> I.e., they are not stored in the file system. ...
>
> That's true. I found in postgres database mailman3web in the table
> mailman3web postorius_emailtemplate my
>
> id name data language created_at modified_at
> context identifier
> 15 list:member:digest:footer postorius footer digest 1x linefeed
> 2021-10-29 11:17:40.664689+02 2021-10-29 11:26:48.692628+02 list
> testliste01.mydomain.de
> 16 list:member:regular:footer postorius footer non-digest 1x
> linefeed 2021-10-29 11:18:29.166241+02 2021-10-29
11:27:24.519024+02 list
> testliste01.mydomain.de
>
> But my question is how to integrate this into the mailman3-system. The
> language isn't set either.
It is integrated. The language isn't set because you are getting the
template from Postorius and Postorius knows the language.
On 10/31/21 4:13 AM, Wolfgang Bock via Mailman-users wrote:
> regarding my mail before, here an additional information.
>
> I can show the templates with following command (anonymized):
>
https://active_domain.de/postorius/api/templates/list/testliste01.active_dom
ain.de/list:member:regular:footer
As it should be.
> The complete syslog
>
(edited and reformatted by me)
```
> --- Logging error ---
> Traceback (most recent call last): Oct 30 11:49:52 active_server
mailman3[107630]: File
"/usr/lib/python3/dist-packages/mailman/model/template.py", line 110, in get
> contents = protocols.get(actual_uri, **auth)
> File
"/usr/lib/python3/dist-packages/mailman/utilities/protocols.py", line
39, in get
> response.raise_for_status()
> File "/usr/lib/python3/dist-packages/requests/models.py", line
943, in raise_for_status
> raise HTTPError(http_error_msg, response=self)
> requests.exceptions.HTTPError: 404 Client Error: Not Found for url:
http://localhost/postorius/api/templates/list/testliste01.active_domain.de/l
ist:member:regular:footer
> During handling of the above exception, another exception occurred:
> Traceback (most recent call last):
> File "/usr/lib/python3.9/logging/__init__.py", line 430, in format
> return self._format(record)
> File "/usr/lib/python3.9/logging/__init__.py", line 426, in _format
> return self._fmt % record.__dict__
> KeyError: 't'
> During handling of the above exception, another exception occurred:
Your template is malformed. You have $ strings that are not defined as
Mailman substitution variables. See
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/t
emplates.html#templated-texts
--
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, 8 months