Search results for query "sapiro"
- 5707 messages
[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
[MM3-users] Re: Restore/export existing Mailman lists + hyperkitty archives on a new server
by alexs＠ecoscentric.com
Mark Sapiro wrote:
...
> I thing just dumping and loading the databases and copying mailman.cfg
> and the Django settings should do it. Are the domains the same on the
> new server? If not there may be issues with that. I'd need to see the
> exception and traceback to say more.
I am migrating from mailman 3.2.1 & mailman3-web 0+20180916-8 on Debian Buster to mailman 3.3.8 & mailman3-web 0+20200530-2.1 on Debian bookworm, have mailman3 and mailman3-web configured (and running on bookworm) from the initial install. But when I use the mailman3-web 0+20180916-8 database (after stopping mailman3 and mailman3-web) on bookworm, unfortunately migrate fails:
# mailman-web showmigrations
account
[X] 0001_initial
[X] 0002_email_max_length
admin
[X] 0001_initial
[X] 0002_logentry_remove_auto_add
[X] 0003_logentry_add_action_flag_choices
auth
[X] 0001_initial
[X] 0002_alter_permission_name_max_length
[X] 0003_alter_user_email_max_length
[X] 0004_alter_user_username_opts
[X] 0005_alter_user_last_login_null
[X] 0006_require_contenttypes_0002
[X] 0007_alter_validators_add_error_messages
[X] 0008_alter_user_username_max_length
[X] 0009_alter_user_last_name_max_length
[X] 0010_alter_group_name_max_length
[X] 0011_update_proxy_permissions
[X] 0012_alter_user_first_name_max_length
contenttypes
[X] 0001_initial
[X] 0002_remove_content_type_name
...
# mailman-web migrate --plan
Planned operations:
contenttypes.0001_initial
Create model ContentType
Alter unique_together for contenttype (1 constraint(s))
auth.0001_initial
Create model Permission
Create model Group
Create model User
account.0001_initial
Create model EmailAddress
Create model EmailConfirmation
account.0002_email_max_length
Alter field email on emailaddress
admin.0001_initial
Create model LogEntry
admin.0002_logentry_remove_auto_add
Alter field action_time on logentry
admin.0003_logentry_add_action_flag_choices
Alter field action_flag on logentry
contenttypes.0002_remove_content_type_name
Change Meta options on contenttype
Alter field name on contenttype
Raw Python operation
Remove field name from contenttype
...
But the migrate fails at the first operation:
# mailman-web migrate
Operations to perform:
Apply all migrations: account, admin, auth, contenttypes, django_mailman3, django_q, hyperkitty, postorius, sessions, sites, socialaccount
Running migrations:
Applying contenttypes.0001_initial...Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 82, in _execute
return self.cursor.execute(sql)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/django/db/backends/mysql/base.py", line 73, in execute
return self.cursor.execute(query, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 209, in execute
res = self._query(query)
^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 315, in _query
db.query(q)
File "/usr/lib/python3/dist-packages/MySQLdb/connections.py", line 239, in query
_mysql.connection.query(self, query)
MySQLdb._exceptions.OperationalError: (1050, "Table 'django_content_type' already exists")
...
Indeed the table django_content_type already exists on 0+20180916-8 . Apart from fields changes, there are an additional 4 tables in mailman3-web 0+20200530-2.1
I managed to import the mailman 3.2.1 database to the mailman 3.3.8 database, and all lists, subscriptions and settings looks fine.
So how can I upgrade my existing mailman3-web database?
1 year, 9 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/
3 years, 7 months
[MM3-users] Re: how to unhold a hold message from a nonmmeber in hold list.
by Guillermo Hernandez (Oldno7)
El 21/4/23 a las 10:37, Odhiambo Washington escribió:
>
>
> On Fri, Apr 21, 2023 at 11:20 AM Guillermo Hernandez (Oldno7) via
> Mailman-users <mailman-users(a)mailman3.org> wrote:
>
> I'm having troubles with Django and cannot access to web admin.
>
> I need to unhold a message while figures out what is happening.
>
> Searching the mailman cli help commands didn't help me.
>
> Anyone who knows how to unhold a message, please?
>
>
> TBH, I find it a lot easier to fix the web UI than mess with the
> python shell :-)
>
> While you wait for @Mark Sapiro <mailto:mark@msapiro.net> to save you,
> you can be reading the following:
>
> https://docs.mailman3.org/projects/mailmanclient/en/latest/src/mailmanclien…
Thanks: it seems the place to do it (I didn't find it)
I'm fighting the web UI problem. It seems that something in wsgi has
changed and is no more compatible with my version of things. Error log
from apache shows:
mod_wsgi (pid=30632): Failed to exec Python script file
'/usr/local/mailman3/wsgi.py'.
mod_wsgi (pid=30632): Exception occurred processing WSGI script
'/usr/local/mailman3/wsgi.py'.
Traceback (most recent call last):
File "/usr/local/mailman3/wsgi.py", line 34, in <module>
from django.core.wsgi import get_wsgi_application
File "/usr/local/lib/python3.9/site-packages/django/core/wsgi.py", line
2, in <module>
from django.core.handlers.wsgi import WSGIHandler
File
"/usr/local/lib/python3.9/site-packages/django/core/handlers/wsgi.py",
line 3, in <module>
from django.conf import settings
File "/usr/local/lib/python3.9/site-packages/django/conf/__init__.py",
line 19, in <module>
from django.utils.deprecation import RemovedInDjango50Warning,
RemovedInDjango51Warning
File
"/usr/local/lib/python3.9/site-packages/django/utils/deprecation.py",
line 4, in <module>
from asgiref.sync import iscoroutinefunction, markcoroutinefunction,
sync_to_async
ImportError: cannot import name 'iscoroutinefunction' from
'asgiref.sync' (/usr/local/lib/python3.9/site-packages/asgiref/sync.py)
Yesterday all were running without problems, today is another day X)
>
> --
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
> [How to ask smart questions:
> http://www.catb.org/~esr/faqs/smart-questions.html]
--
___________________________________________
Mailman's content filtering has removed the
following MIME parts from this message.
Content-Type: image/png
Name: firma-GHP-emails.png
Replaced multipart/alternative part with first alternative.
2 years, 2 months
[MM3-users] Re: moving individual list to different domain
by Johannes Rohr
Dear Mark,
thanks as always for your very thorough explanation. I guess, it is
simply not practical then...
Cheers,
Johannes
Am 21.03.23 um 19:11 schrieb Mark Sapiro:
> On 3/21/23 06:21, Johannes Rohr wrote:
>> Dear all,
>>
>> on mailman2 it was possible to move a list to a different domain
>> within the same mailman instance.
>>
>> I have found no information on how the same can be accomplished on
>> mailman3.
>>
>> Is this possible at all?
>
>
> In mailman 2.1, a list was identified by its name only without the
> domain and those names had to be globally unique. A site could be
> configured to support multiple virtual hosts and a list had a
> host_name attribute which could be changed if desired to assign the
> list to a different virtual host, but there couldn't be two lists with
> the same name even if they had different host names.
>
> Mailman 3 is different. In order to remove the restriction that list
> names (without the domain) had to be globally unique, in MM 3 the
> domain is part of the list name. I.e., we can now have
> list(a)example.com and list(a)example.net as two distinct lists in the
> same installation.
>
> Suppose we want to rename list(a)example.com to list(a)example.net. This
> becomes involved in Mailman 3 because it affects not only Mailman
> core, but also mail delivery and archiving. Furthermore, the list with
> fqdn_listname list(a)example.com has the list_id list.example.com. If we
> change the fqdn_listname to list(a)example.net, the list_id should
> remain list.example.com per RFC 2919 Sec. 4.
> <https://www.rfc-editor.org/rfc/rfc2919>. We can just change the
> list's mail_host attribute via REST
> <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…>
> or via a database query, but this leads to confusion. I.e., a URL like
> https://example.com/mailman3/lists/list.example.com/ will still work
> but https://example.com/mailman3/lists/list@example.com/.
>
> To avoid this, we could also change the list_id, but we can't do that
> via REST as it's a read-only property, and changing the list_id says
> this is really a new list, not the same list with a new name.
>
> Also, none of this addresses archiving.
>
2 years, 3 months