Re: user mail not accepted
by Mark Sapiro
On 4/26/21 5:00 PM, Christian Stalberg via Mailman-users wrote:
>>From smtp.log
>
> Apr 26 00:17:39 2021 (807) ('127.0.0.1', 38370) Data: b'DATA'
> Apr 26 00:17:39 2021 (807) ('127.0.0.1', 38370) Data: b'QUIT'
> Apr 26 00:17:39 2021 (807) ('127.0.0.1', 38370) connection lost
> Apr 26 00:17:39 2021 (807) Connection lost during _handle_client()
> Apr 26 00:18:11 2021 (809)
> <019301d73a31$8e8e54e0$abaafea0$(a)ncboliviapartners.org> smtp to
> ncpoa(a)lists.ccalternatives.org for 83 recips, completed in 29.13376259803772
> seconds
> Apr 26 00:18:11 2021 (809)
> <019301d73a31$8e8e54e0$abaafea0$(a)ncboliviapartners.org> post to
> ncpoa(a)lists.ccalternatives.org from christian(a)ncboliviapartners.org, 5811
> bytes
> Apr 26 00:18:11 2021 (809)
> <161939626169.810.9530678025639681522(a)zarathustra.ccalternatives.org> smtp
> to ncpoa(a)lists.ccalternatives.org for 1 recips, completed in
> 0.0420069694519043 seconds
> Apr 26 00:18:11 2021 (809)
> <161939626169.810.9530678025639681522(a)zarathustra.ccalternatives.org> post
> to ncpoa(a)lists.ccalternatives.org from
> ncpoa-bounces(a)lists.ccalternatives.org, 869 bytes
> Apr 26 11:52:22 2021 (819)
> <161943793957.929.15640398646519288095(a)zarathustra.ccalternatives.org> smtp
> to ssan(a)lists.ccalternatives.org for 1 recips, completed in
> 0.22335004806518555 seconds
> Apr 26 11:52:22 2021 (819)
> <161943793957.929.15640398646519288095(a)zarathustra.ccalternatives.org> post
> to ssan(a)lists.ccalternatives.org from ssan-bounces(a)lists.ccalternatives.org,
> 765 bytes
> Apr 26 11:52:22 2021 (819)
> <161943793960.929.13309139087156940549(a)zarathustra.ccalternatives.org> smtp
> to ssan(a)lists.ccalternatives.org for 2 recips, completed in
> 0.05862092971801758 seconds
> Apr 26 11:52:22 2021 (819)
> <161943793960.929.13309139087156940549(a)zarathustra.ccalternatives.org> post
> to ssan(a)lists.ccalternatives.org from noreply(a)lists.ccalternatives.org, 810
> bytes
> Apr 26 11:55:22 2021 (819)
> <161943812108.929.10391982256874011271(a)zarathustra.ccalternatives.org> smtp
> to ssan(a)lists.ccalternatives.org for 1 recips, completed in
> 0.1459965705871582 seconds
> Apr 26 11:55:22 2021 (819)
> <161943812108.929.10391982256874011271(a)zarathustra.ccalternatives.org> post
> to ssan(a)lists.ccalternatives.org from
> ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.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'
It looks like the above 12:01:30 are the relevant entries, and that
message was sent to
ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.ccalternatives.org
which is not the list, but the list's -confirm address.
Was the response received by the user a "results of your email commands"
message?
> Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) connection lost
> Apr 26 12:01:30 2021 (817) Connection lost during _handle_client()
> Apr 26 12:01:34 2021 (819)
> <161943849287.814.5890052642238479423(a)zarathustra.ccalternatives.org> smtp
> to ssan(a)lists.ccalternatives.org for 2 recips, completed in
> 0.06680631637573242 seconds
> Apr 26 12:01:34 2021 (819)
> <161943849287.814.5890052642238479423(a)zarathustra.ccalternatives.org> post
> to ssan(a)lists.ccalternatives.org from noreply(a)lists.ccalternatives.org, 821
> bytes
> Apr 26 12:01:34 2021 (819)
> <161943849292.814.6140111398379700592(a)zarathustra.ccalternatives.org> smtp
> to ssan(a)lists.ccalternatives.org for 1 recips, completed in
> 0.04269862174987793 seconds
> Apr 26 12:01:34 2021 (819)
> <161943849292.814.6140111398379700592(a)zarathustra.ccalternatives.org> post
> to ssan(a)lists.ccalternatives.org from ssan-request(a)lists.ccalternatives.org,
> 1335 bytes
>
>
> Message sent that only the user receives:
What I wanted to see was not the message sent to the list, but the
message received by the one user from the list. If you are saying this
message is that, it didn't come from any Mailman list.
> Return-Path: <christian(a)sewagesludgeactionnetwork.com>
> Delivered-To: ces(a)ecovillage.cc
> Received: from box.ecovillage.cc ([127.0.0.1])
> by box.ecovillage.cc with LMTP id MDucNBythmCTSwAAMoO61A
> for <ces(a)ecovillage.cc>; Mon, 26 Apr 2021 05:07:56 -0700
> X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on box.ecovillage.cc
> X-Spam-Level:
> X-Spam-Status: No, score=-1.1 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED,
> DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE autolearn=ham
> autolearn_force=no
> version=3.4.2
> X-Spam-Report:
> * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
> * 0.0 HTML_MESSAGE BODY: HTML included in message
> * -0.1 DKIM_VALID Message has at least one valid DKIM or DK
> signature
> * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not
> necessarily
> * valid
> * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
> * author's domain
> X-Spam-Score: -1.1
> Received: from authenticated-user (box.ecovillage.cc [45.79.28.18])
> (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
> bits))
> (No client certificate requested)
> by box.ecovillage.cc (Postfix) with ESMTPSA id 6EADF3E8CC
> for <ssan(a)lists.naturalintelligence.us>; Mon, 26 Apr 2021 05:07:54
> -0700 (PDT)
> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
> d=sewagesludgeactionnetwork.com; s=mail; t=1619438876;
> bh=1M7F/uIS0bNG6cWjecy/a9QjskrHVwJHkjWRv+ffpM4=;
> h=From:To:References:In-Reply-To:Subject:Date:From;
> b=jXOswVZgFeHBB+sjIDqVkNBQqIbfZCj9ZUfpVwl10NQEkGaoxckPHNOKT6x9zIqsW
> BZ7iZqqi2mWprVQ8LrK48Lp7gvCQ/ipqspMeLt3t+uljzTtryHmV6uJFEAU3hqM33Y
> nQqX6Z8la8Ko40F9Ayb4h4e/MOfPdA4nadgf5hZzt/DzPFZvzUbG3V8lWcHuyJNA2y
> SQkhbNubQ6iNEEB0SyBjoOjl3g3LVxjxY+9kMGGmX+1PFfW90CpDDShRmKkkscEWaA
> NiV0fX6U5LENBBnc6Q9ImLgXuaLdCqlBRBumJBk+eUUr007rpXXVAPck2NvUzGyM2v
> kNNGlT68hGzEg==
> From: <christian(a)sewagesludgeactionnetwork.com>
> To: <ssan(a)lists.naturalintelligence.us>
> References:
> In-Reply-To:
> Subject: How US chemical industry lobbying and cash defeated regulation in
> Trump era
> Date: Mon, 26 Apr 2021 05:07:37 -0700
> Message-ID: <020501d73a94$cbe17440$63a45cc0$(a)sewagesludgeactionnetwork.com>
> MIME-Version: 1.0
> Content-Type: multipart/alternative;
> boundary="----=_NextPart_000_0206_01D73A5A.1F831170"
> Thread-Index: Adc6h7I/qzBKx1yOT6aPOuipppacoQACatZAAADW1wA=
> Content-Language: en-us
>
> How US chemical industry lobbying and cash defeated regulation in Trump era
> Industry's congressional allies defeated nearly all PFAS legislation while
> the Trump EPA killed, watered down or slowalked new rules
>
> https://www.theguardian.com/environment/2021/apr/26/us-chemical-companies-lo
> bbying-donation-defeated-regulation
>
>
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
4 years, 2 months
Re: user mail not accepted
by Christian Stalberg
No. there was no response received by the user a la "results of your email
commands"
message. Simply the original email sent to the list.
-----Original Message-----
From: Mark Sapiro <mark(a)msapiro.net>
Sent: Monday, April 26, 2021 5:25 PM
To: mailman-users(a)mailman3.org
Subject: [MM3-users] Re: user mail not accepted
On 4/26/21 5:00 PM, Christian Stalberg via Mailman-users wrote:
>>From smtp.log
>
> Apr 26 00:17:39 2021 (807) ('127.0.0.1', 38370) Data: b'DATA'
> Apr 26 00:17:39 2021 (807) ('127.0.0.1', 38370) Data: b'QUIT'
> Apr 26 00:17:39 2021 (807) ('127.0.0.1', 38370) connection lost Apr 26
> 00:17:39 2021 (807) Connection lost during _handle_client() Apr 26
> 00:18:11 2021 (809)
> <019301d73a31$8e8e54e0$abaafea0$(a)ncboliviapartners.org> smtp to
> ncpoa(a)lists.ccalternatives.org for 83 recips, completed in
> 29.13376259803772 seconds Apr 26 00:18:11 2021 (809)
> <019301d73a31$8e8e54e0$abaafea0$(a)ncboliviapartners.org> post to
> ncpoa(a)lists.ccalternatives.org from christian(a)ncboliviapartners.org,
> 5811 bytes Apr 26 00:18:11 2021 (809)
> <161939626169.810.9530678025639681522(a)zarathustra.ccalternatives.org>
> smtp to ncpoa(a)lists.ccalternatives.org for 1 recips, completed in
> 0.0420069694519043 seconds
> Apr 26 00:18:11 2021 (809)
> <161939626169.810.9530678025639681522(a)zarathustra.ccalternatives.org>
> post to ncpoa(a)lists.ccalternatives.org from
> ncpoa-bounces(a)lists.ccalternatives.org, 869 bytes Apr 26 11:52:22 2021
> (819)
> <161943793957.929.15640398646519288095(a)zarathustra.ccalternatives.org>
> smtp to ssan(a)lists.ccalternatives.org for 1 recips, completed in
> 0.22335004806518555 seconds
> Apr 26 11:52:22 2021 (819)
> <161943793957.929.15640398646519288095(a)zarathustra.ccalternatives.org>
> post to ssan(a)lists.ccalternatives.org from
> ssan-bounces(a)lists.ccalternatives.org,
> 765 bytes
> Apr 26 11:52:22 2021 (819)
> <161943793960.929.13309139087156940549(a)zarathustra.ccalternatives.org>
> smtp to ssan(a)lists.ccalternatives.org for 2 recips, completed in
> 0.05862092971801758 seconds
> Apr 26 11:52:22 2021 (819)
> <161943793960.929.13309139087156940549(a)zarathustra.ccalternatives.org>
> post to ssan(a)lists.ccalternatives.org from
> noreply(a)lists.ccalternatives.org, 810 bytes Apr 26 11:55:22 2021 (819)
> <161943812108.929.10391982256874011271(a)zarathustra.ccalternatives.org>
> smtp to ssan(a)lists.ccalternatives.org for 1 recips, completed in
> 0.1459965705871582 seconds
> Apr 26 11:55:22 2021 (819)
> <161943812108.929.10391982256874011271(a)zarathustra.ccalternatives.org>
> post to ssan(a)lists.ccalternatives.org from
> ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.ccalternat
> ssan-confirm+ives.o
> rg, 1526 bytes
> Apr 26 12:01:30 2021 (817) Available AUTH mechanisms: LOGIN(builtin)
> PLAIN(builtin)
> Apr 26 12:01:30 2021 (817) Peer: ('127.0.0.1', 38556) Apr 26 12:01:30
> 2021 (817) ('127.0.0.1', 38556) handling connection Apr 26 12:01:30
> 2021 (817) ('127.0.0.1', 38556) Data: b'LHLO
> zarathustra.ccalternatives.org'
> Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) Data: b'MAIL
> FROM:<christian(a)sewagesludgeactionnetwork.com>'
> Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) sender:
> christian(a)sewagesludgeactionnetwork.com
> Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) Data: b'RCPT
> TO:<ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.ccalte
> rnativ
> es.org>'
> Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) recip:
> ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.ccalternat
> ssan-confirm+ives.o
> rg
> Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) Data: b'DATA'
> Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) Data: b'QUIT'
It looks like the above 12:01:30 are the relevant entries, and that message
was sent to
ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.ccalternativ
ssan-confirm+es.org
which is not the list, but the list's -confirm address.
Was the response received by the user a "results of your email commands"
message?
> Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) connection lost Apr 26
> 12:01:30 2021 (817) Connection lost during _handle_client() Apr 26
> 12:01:34 2021 (819)
> <161943849287.814.5890052642238479423(a)zarathustra.ccalternatives.org>
> smtp to ssan(a)lists.ccalternatives.org for 2 recips, completed in
> 0.06680631637573242 seconds
> Apr 26 12:01:34 2021 (819)
> <161943849287.814.5890052642238479423(a)zarathustra.ccalternatives.org>
> post to ssan(a)lists.ccalternatives.org from
> noreply(a)lists.ccalternatives.org, 821 bytes Apr 26 12:01:34 2021 (819)
> <161943849292.814.6140111398379700592(a)zarathustra.ccalternatives.org>
> smtp to ssan(a)lists.ccalternatives.org for 1 recips, completed in
> 0.04269862174987793 seconds
> Apr 26 12:01:34 2021 (819)
> <161943849292.814.6140111398379700592(a)zarathustra.ccalternatives.org>
> post to ssan(a)lists.ccalternatives.org from
> ssan-request(a)lists.ccalternatives.org,
> 1335 bytes
>
>
> Message sent that only the user receives:
What I wanted to see was not the message sent to the list, but the message
received by the one user from the list. If you are saying this message is
that, it didn't come from any Mailman list.
> Return-Path: <christian(a)sewagesludgeactionnetwork.com>
> Delivered-To: ces(a)ecovillage.cc
> Received: from box.ecovillage.cc ([127.0.0.1])
> by box.ecovillage.cc with LMTP id MDucNBythmCTSwAAMoO61A
> for <ces(a)ecovillage.cc>; Mon, 26 Apr 2021 05:07:56 -0700
> X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
> box.ecovillage.cc
> X-Spam-Level:
> X-Spam-Status: No, score=-1.1 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED,
> DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE autolearn=ham
> autolearn_force=no
> version=3.4.2
> X-Spam-Report:
> * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
> * 0.0 HTML_MESSAGE BODY: HTML included in message
> * -0.1 DKIM_VALID Message has at least one valid DKIM or DK
signature
> * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not
> necessarily
> * valid
> * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
> * author's domain
> X-Spam-Score: -1.1
> Received: from authenticated-user (box.ecovillage.cc [45.79.28.18])
> (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
> bits))
> (No client certificate requested)
> by box.ecovillage.cc (Postfix) with ESMTPSA id 6EADF3E8CC
> for <ssan(a)lists.naturalintelligence.us>; Mon, 26 Apr 2021 05:07:54
> -0700 (PDT)
> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
> d=sewagesludgeactionnetwork.com; s=mail; t=1619438876;
> bh=1M7F/uIS0bNG6cWjecy/a9QjskrHVwJHkjWRv+ffpM4=;
> h=From:To:References:In-Reply-To:Subject:Date:From;
> b=jXOswVZgFeHBB+sjIDqVkNBQqIbfZCj9ZUfpVwl10NQEkGaoxckPHNOKT6x9zIqsW
> BZ7iZqqi2mWprVQ8LrK48Lp7gvCQ/ipqspMeLt3t+uljzTtryHmV6uJFEAU3hqM33Y
> nQqX6Z8la8Ko40F9Ayb4h4e/MOfPdA4nadgf5hZzt/DzPFZvzUbG3V8lWcHuyJNA2y
> SQkhbNubQ6iNEEB0SyBjoOjl3g3LVxjxY+9kMGGmX+1PFfW90CpDDShRmKkkscEWaA
> NiV0fX6U5LENBBnc6Q9ImLgXuaLdCqlBRBumJBk+eUUr007rpXXVAPck2NvUzGyM2v
> kNNGlT68hGzEg==
> From: <christian(a)sewagesludgeactionnetwork.com>
> To: <ssan(a)lists.naturalintelligence.us>
> References:
> In-Reply-To:
> Subject: How US chemical industry lobbying and cash defeated
> regulation in Trump era
> Date: Mon, 26 Apr 2021 05:07:37 -0700
> Message-ID:
> <020501d73a94$cbe17440$63a45cc0$(a)sewagesludgeactionnetwork.com>
> MIME-Version: 1.0
> Content-Type: multipart/alternative;
> boundary="----=_NextPart_000_0206_01D73A5A.1F831170"
> Thread-Index: Adc6h7I/qzBKx1yOT6aPOuipppacoQACatZAAADW1wA=
> Content-Language: en-us
>
> How US chemical industry lobbying and cash defeated regulation in
> Trump era Industry's congressional allies defeated nearly all PFAS
> legislation while the Trump EPA killed, watered down or slowalked new
> rules
>
> https://www.theguardian.com/environment/2021/apr/26/us-chemical-compan
> ies-lo
> bbying-donation-defeated-regulation
>
>
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
_______________________________________________
Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send
an email to mailman-users-leave(a)mailman3.org
https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
4 years, 2 months
Re: SMTPSenderRefused - howto enable STARTTLS for local mail drop
by Stefan Bauer
Unfortunately i need this, as the postfix is listening on all interfaces
and we have the policy to enforce TLS only. Nothing special in the logs:
Dec 07 08:14:14 2021 (12303) Using agent: <mailman.mta.bulk.BulkDelivery
object at 0x7fbc29b1c4a8>
Dec 07 08:14:14 2021 (12303) Connecting to localhost:25
Dec 07 08:14:14 2021 (12303) envsender: v-test-bounces@domain, recipients:
['recipient(a)own.domain'], size(msgtext): 5809
Dec 07 08:14:14 2021 (12303)
<kcEE.aBI3BVc2RCi6kAxA4PJ0hg.ADrcCDrr1wE(a)mailsrv103.my.domain> smtp to
v-test@domain for 1 recips, completed in 0.008081912994384766 seconds
Dec 07 08:14:14 2021 (12303)
<kcEE.aBI3BVc2RCi6kAxA4PJ0hg.ADrcCDrr1wE(a)mailsrv103.my.domain> post to
v-test@domain from v-test@domain, 5336 bytes
Dec 07 08:14:47 2021 (12297) Peer: ('127.0.0.1', 43210)
Dec 07 08:14:47 2021 (12297) ('127.0.0.1', 43210) handling connection
Dec 07 08:14:47 2021 (12297) b'220 ml01.my.domain GNU Mailman LMTP runner
2.0\r\n'
Dec 07 08:14:47 2021 (12297) ('127.0.0.1', 43210) EOF received
Dec 07 08:14:47 2021 (12297) Connection lost during _handle_client()
Dec 07 08:14:47 2021 (12297) ('127.0.0.1', 43210) connection lost
Dec 07 08:15:00 2021 (12297) Peer: ('127.0.0.1', 43516)
Dec 07 08:15:00 2021 (12297) ('127.0.0.1', 43516) handling connection
Is my mailman version maybe too old for this setting?
I'm running GNU Mailman 3.1.1 (Between The Wheels)
Thank you.
Am Mo., 6. Dez. 2021 um 19:04 Uhr schrieb Mark Sapiro <mark(a)msapiro.net>:
> On 12/6/21 2:51 AM, Stefan Bauer wrote:
> > Need to bring this up again. Django now sends with STARTTLS, but mailman
> > itself, does still only drop mails in cleartext.
> > Dec 6 11:47:33 al01 postfix/lmtp[7598]: A6422600510:
> > to=<remote-party@remote>, relay=127.0.0.1[127.0.0.1]:8024, delay=0.01,
> > delays=0.01/0/0/0.01, dsn=2.0.0, status=sent (250 Ok)
> > Dec 6 11:47:33 al01 postfix/qmgr[29156]: A6422600510: removed
> > Dec 6 11:47:35 al01 postfix/smtpd[8092]: disconnect from localhost[::1]
> > ehlo=1 mail=2 rcpt=2 data=2 commands=7
> >
> > No starttls=1 at all :(
> >
> > Does the above settings work for anyone?
> >
> > etc/mailman3/mailman.cfg
> > [mta]
> > incoming: mailman.mta.postfix.LMTP
> > outgoing: mailman.mta.deliver.deliver
> >
> > smtp_host: localhost
> > smtp_port: 25
> > smtp_user:
> > smtp_pass:
> > smtp_verify_hostname: false
> > smtp_verify_cert: false
> > smtp_secure_mode: starttls
>
>
> This should work. What do you see in Mailman's smtp.log if you add
> ```
> [logging.smtp]
> level: debug
> ```
> to mailman.cfg.
>
> However, do you really need this. It will only affect delivery from
> Mailman to Postfix via the loopback interface on the localhost.
>
> --
> 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, 6 months
Re: Can't deliver mails in queue
by Mark Sapiro
On 5/19/21 10:22 AM, Nathanael Schneider wrote:
>
> I then created a completely new List which did not exists in mm2.1,
> subscribed two addresses and sent myself an EMail. That one worked as
> intended. I then deleted the whole broken list and created it cleanly,
> added the same two people, sent an email and nothing.
This seems strange. If I understand, you are essentially saying the two
lists are the same. I.e., you created a completely new List which did
not exists in mm2.1, and that one worked. Then you deleted the whole
broken list and created it cleanly ... What was different between this
cleanly created list and the completely new List?
> May 19 18:54:40 2021 (8280) Using agent: <mailman.mta.deliver.Deliver object at 0x7fb49b143780>
> May 19 18:54:40 2021 (8280) IndividualDelivery to: nathanael(a)lumenliquid.net
> May 19 18:54:40 2021 (8280) Using agent: <mailman.mta.deliver.Deliver object at 0x7fb4974541d0>
> May 19 18:54:40 2021 (8280) IndividualDelivery to: nathanael(a)lumenliquid.net
The fact that these are the only messages says that the attempt to send
that message via smtp raised no exception as exceptions would have been
logged, yet you say there's nothing in the maillog so there was no
connect to Postfix. What are your settings for smtp_host: and
smtp_port: in the [mta] section of mailman.cfg?
...
> I have no clue what to do with this. I then turned the debug module
> loglevel to debug. Also nothing useful. Just an endless list of
>
> [...]
> May 19 18:17:29 2021 (7209) [outgoing] <function deliver at
> 0x7f2faf384c80>: <B9531076-2480-4925-9A2B-57802B53D5ED(a)gmx.de>
> May 19 18:17:29 2021 (7203) [ArchiveRunner] starting oneloop
> May 19 18:17:29 2021 (7203) [ArchiveRunner] ending oneloop: 0
> May 19 18:17:29 2021 (7209) [OutgoingRunner] finishing filebase:
> 1621441049.4089153+6dff56673dc64b890dd352941267782c264586dd
> May 19 18:17:29 2021 (7209) [OutgoingRunner] doing periodic
> May 19 18:17:29 2021 (7209) [OutgoingRunner] committing transaction
> May 19 18:17:29 2021 (7209) [OutgoingRunner] checking short circuit
> May 19 18:17:29 2021 (7209) [OutgoingRunner] ending oneloop: 1
> May 19 18:17:29 2021 (7209) [OutgoingRunner] starting oneloop
> May 19 18:17:29 2021 (7209) [OutgoingRunner] processing filebase:
> 1621441049.4628382+6a0437ea387a2508ad947c0a51712075cbdb6d2e
> May 19 18:17:29 2021 (7209) [OutgoingRunner] processing onefile
> May 19 18:17:29 2021 (7209) [outgoing] <function deliver at
> 0x7f2faf384c80>: <B9531076-2480-4925-9A2B-57802B53D5ED(a)gmx.de>
> [...]
>
> Which also tells me nothing I can understand.
It says the message in queue entry
1621441049.4089153+6dff56673dc64b890dd352941267782c264586dd is handled
but gets requeued as
1621441049.4628382+6a0437ea387a2508ad947c0a51712075cbdb6d2e which
presumably is handled and requeued again ...
> I have no clue what's
> going wrong. (I've turned on debugging both on the original member list
> and the reduced member list. Both hang on the first delivery they do).
> If I restart mailman, the message gets correctly shunted as it is
> interrupted mid-delivery. My maillogs don't register any activity beside
> the listpost. Any ideas what I need to do to figure out what's not
> working here or where the culprit could be? Not sure if it is related to
> the mailinglist being in mailman2.1 before.
I have no real understanding of why this isn't working. I don't think
it's likely that it has to do with the mailing list being imported from
MM 2.1, but I suppose it could be.
How did you create and import the list? When you say you deleted the
whole broken list and created it cleanly, what did you actually do?
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
4 years, 1 month
Re: Can't deliver mails in queue
by Nathanael Schneider
>>> May 19 18:54:40 2021 (8280) Using agent:
>>> <mailman.mta.deliver.Deliver object at 0x7fb49b143780>
>>> May 19 18:54:40 2021 (8280) IndividualDelivery to:
>>> nathanael(a)lumenliquid.net
>>> May 19 18:54:40 2021 (8280) Using agent:
>>> <mailman.mta.deliver.Deliver object at 0x7fb4974541d0>
>>> May 19 18:54:40 2021 (8280) IndividualDelivery to:
>>> nathanael(a)lumenliquid.net
>>
>> The fact that these are the only messages says that the attempt to send
>> that message via smtp raised no exception as exceptions would have been
>> logged, yet you say there's nothing in the maillog so there was no
>> connect to Postfix. What are your settings for smtp_host: and
>> smtp_port: in the [mta] section of mailman.cfg?
>
> I set nothing explicitly as the default options fit my needs, so
> localhost:25 it is to my knowledge. Postfix itself was configured by
> Plesk and the config for mailman3 was manually added as prescribed. A
> manual telnet on localhost 25 gives me the expected 220 message from
> postfix.
>
>> It says the message in queue entry
>> 1621441049.4089153+6dff56673dc64b890dd352941267782c264586dd is handled
>> but gets requeued as
>> 1621441049.4628382+6a0437ea387a2508ad947c0a51712075cbdb6d2e which
>> presumably is handled and requeued again ...
>
> Ok. Then I just need to figure out why it gets requeued. That also
> explains why the out-queue folder keeps creating a single message with
> different filenames over and over. But the logs keep silent about the
> reason..
Ok I figured out what happened.. First I tried to get more infos by
running the runner manually once. And indeed, now I see that the runner
"can't connect to SMTP":
(venv) mailman@h2831057:~$ runner -C /etc/mailman3/mailman.cfg -o -v
--runner=out:0:1
May 20 12:17:24 2021 (20303) out runner started.
May 20 12:17:24 2021 (20303) out runner started.
May 20 12:17:24 2021 (20303) Using agent: <mailman.mta.deliver.Deliver
object at 0x7f8a51649be0>
May 20 12:17:24 2021 (20303) Using agent: <mailman.mta.deliver.Deliver
object at 0x7f8a51649be0>
May 20 12:17:24 2021 (20303) IndividualDelivery to: business(a)lumenliquid.net
May 20 12:17:24 2021 (20303) IndividualDelivery to: business(a)lumenliquid.net
May 20 12:17:24 2021 (20303) Starting new HTTP connection (1):
localhost:8000
May 20 12:17:24 2021 (20303) Starting new HTTP connection (1):
localhost:8000
May 20 12:17:24 2021 (20303) Cannot connect to SMTP server localhost on
port 25
May 20 12:17:24 2021 (20303) Cannot connect to SMTP server localhost on
port 25
May 20 12:17:24 2021 (20303) out runner exiting.
May 20 12:17:24 2021 (20303) out runner exiting.
Which turns out is the completely wrong error message. SMTP works fine,
it is the connection before (localhost:8000) that fails. After some more
digging on that particular error I found a thread that linked this error
with the use of templates. And indeed, if I add a footer template to my
working list, it stops working. If I remove the footer from the broken
list, it starts working. So there is something wrong with the templates.
After some more digging I looked into the database how my footers were
saved and indeed, if I did a wget on the url it timed out because it
didn't work. I then dug a little bit more and found the setting
"POSTORIUS_TEMPLATE_BASE_URL" which apparently you also have to set. I
didn't know because it was mentioned nowhere in the starting guide. So I
set it to the url of my frontend and bang, it works (after fixing the
urls in the database aswell).
It would have been nice though to have a more refined error to figure
this out. But its solved now and hopefully this will help someone else
as well.
--
Nathanael Schneider
4 years, 1 month
Re: REST API http://.../3.1/users/../preferred_address returns 404 for GET and POST
by Eric Vyncke
Humm after some more investigations, it seems that my mailman3 installation via debian packages is completely mixed up :-( This would explain the issue if the REST API is using 3.2.2 code and postorius is expecting 3.3.5...
drwxr-xr-x 29 root root 4096 Nov 18 2021 /usr/lib/python3/dist-packages/mailman
drwxr-xr-x 2 root root 4096 Nov 18 2021 /usr/lib/python3/dist-packages/mailman-3.2.2.egg-info
drwxr-xr-x 8 root root 4096 Nov 18 2021 /usr/lib/python3/dist-packages/mailmanclient
drwxr-xr-x 2 root root 4096 Nov 18 2021 /usr/lib/python3/dist-packages/mailmanclient-3.2.2.egg-info
drwxr-xr-x 4 root root 4096 Apr 13 14:29 /usr/lib/python3/dist-packages/mailman_hyperkitty
drwxr-xr-x 2 root root 4096 Apr 13 14:28 /usr/lib/python3/dist-packages/mailman_hyperkitty-1.1.0.egg-info
drwxr-sr-x 30 root staff 4096 Apr 13 09:32 /usr/local/lib/python3.8/dist-packages/mailman
drwxr-sr-x 2 root staff 4096 Nov 18 2021 /usr/local/lib/python3.8/dist-packages/mailman-3.3.5.dist-info
drwxr-sr-x 9 root staff 4096 Nov 18 2021 /usr/local/lib/python3.8/dist-packages/mailmanclient
drwxr-sr-x 2 root staff 4096 Nov 18 2021 /usr/local/lib/python3.8/dist-packages/mailmanclient-3.3.3.dist-info
drwxr-sr-x 4 root staff 4096 Apr 12 20:47 /usr/local/lib/python3.8/dist-packages/mailman_web
drwxr-sr-x 2 root staff 4096 Nov 18 2021 /usr/local/lib/python3.8/dist-packages/mailman_web-0.0.5.dist-info
2 years, 2 months
Re: can't get mail into mailman3 in docker
by bob B
I see nothing for today when the error happens
in /opt/mailman/var/logs/smtp.log
But the log has a bunch of these, but these stopped around the 4th
Aug 04 19:46:04 2021 (28) Available AUTH mechanisms: LOGIN(builtin) PLAIN(builtin)
Aug 04 19:46:04 2021 (28) Peer: ('127.0.0.1', 33912)
Aug 04 19:46:04 2021 (28) ('127.0.0.1', 33912) handling connection
Aug 04 19:46:04 2021 (28) ('127.0.0.1', 33912) EOF received
Aug 04 19:46:04 2021 (28) ('127.0.0.1', 33912) Connection lost during _handle_client()
Aug 04 19:46:04 2021 (28) ('127.0.0.1', 33912) connection lost
3 years, 10 months
Re: archiving problem & updates
by Christian Stalberg
I see two messages waiting to be archived. Below is excerpt from the
logfile:
Feb 10 13:40:49 2021 (974) held message approved, message-id:
<CAGrL7FsaX8EG9pMUZreJrQt1xkEyR3ySuw2-xn3m443O0N3j1A(a)mail.gmail.com>
[10/Feb/2021:13:40:49 +0000] "POST
/3.1/lists/ncpoa(a)lists.ccalternatives.org/held/5 HTTP/1.1" 204 0 "-" "GNU
Mailman REST client v3.3.1"
[10/Feb/2021:13:40:49 +0000] "GET
/3.1/lists/ncpoa(a)lists.ccalternatives.org/held?count=0&page=1 HTTP/1.1" 200
90 "-" "GNU Mailman REST client v3.3.1"
[10/Feb/2021:13:40:49 +0000] "GET
/3.1/lists/ncpoa(a)lists.ccalternatives.org/held?count=10&page=1 HTTP/1.1" 200
90 "-" "GNU Mailman REST client v3.3.1"
[10/Feb/2021:13:40:50 +0000] "GET
/3.1/lists/ncpoa(a)lists.ccalternatives.org/requests HTTP/1.1" 200 90 "-" "GNU
Mailman REST client v3.3.1"
[10/Feb/2021:13:40:50 +0000] "GET
/3.1/lists/ncpoa(a)lists.ccalternatives.org/held?count=50&page=1 HTTP/1.1" 200
90 "-" "GNU Mailman REST client v3.3.1"
Feb 10 13:40:55 2021 (846) HyperKitty failure on
https://lists.ccalternatives.org/archives/api/mailman/archive: <html>^M
<head><title>413 Request Entity Too Large</title></head>^M
<body bgcolor="white">^M
<center><h1>413 Request Entity Too Large</h1></center>^M
<hr><center>nginx/1.14.2</center>^M
</body>^M
</html>^M
(413)
Feb 10 13:40:55 2021 (846) Exception in the HyperKitty archiver: <html>^M
<head><title>413 Request Entity Too Large</title></head>^M
<body bgcolor="white">^M
<center><h1>413 Request Entity Too Large</h1></center>^M
<hr><center>nginx/1.14.2</center>^M
</body>^M
</html>^M
Feb 10 13:40:55 2021 (846) Traceback (most recent call last):
File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman_hyperkitty/__init_
_.py", line 154, in _archive_message
url = self._send_message(mlist, msg)
File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman_hyperkitty/__init_
_.py", line 210, in _send_message
raise ValueError(result.text)
ValueError: <html>^M
<head><title>413 Request Entity Too Large</title></head>^M
<body bgcolor="white">^M
<center><h1>413 Request Entity Too Large</h1></center>^M
<hr><center>nginx/1.14.2</center>^M
</body>^M
Feb 10 13:40:56 2021 (846) HyperKitty failure on
https://lists.ccalternatives.org/archives/api/mailman/archive: <html>^M
<head><title>413 Request Entity Too Large</title></head>^M
<body bgcolor="white">^M
<center><h1>413 Request Entity Too Large</h1></center>^M
<hr><center>nginx/1.14.2</center>^M
</body>^M
</html>^M
(413)
Feb 10 13:40:56 2021 (846) Exception in the HyperKitty archiver: <html>^M
<head><title>413 Request Entity Too Large</title></head>^M
<body bgcolor="white">^M
<center><h1>413 Request Entity Too Large</h1></center>^M
<hr><center>nginx/1.14.2</center>^M
</body>^M
</html>^M
Feb 10 13:40:56 2021 (846) Traceback (most recent call last):
File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman_hyperkitty/__init_
_.py", line 154, in _archive_message
url = self._send_message(mlist, msg)
File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman_hyperkitty/__init_
_.py", line 210, in _send_message
raise ValueError(result.text)
ValueError: <html>^M
<head><title>413 Request Entity Too Large</title></head>^M
<body bgcolor="white">^M
<center><h1>413 Request Entity Too Large</h1></center>^M
<hr><center>nginx/1.14.2</center>^M
</body>^M
</html>^M
[10/Feb/2021:13:41:38 +0000] "GET /3.1/domains HTTP/1.1" 200 321 "-" "GNU
Mailman REST client v3.3.1"
[10/Feb/2021:13:41:38 +0000] "GET /3.1/domains/lists.ccalternatives.org
HTTP/1.1" 200 216 "-" "GNU Mailman REST client v3.3.1"
[10/Feb/2021:13:41:38 +0000] "POST /3.1/lists/find HTTP/1.1" 200 1013 "-"
"GNU Mailman REST client v3.3.1"
[10/Feb/2021:13:41:53 +0000] "GET /3.1/lists/ncpoa.lists.ccalternatives.org
HTTP/1.1" 200 453 "-" "GNU Mailman REST client v3.3.1"
[10/Feb/2021:13:41:53 +0000] "GET
/3.1/lists/ncpoa.lists.ccalternatives.org/roster/owner HTTP/1.1" 200 668 "-"
"GNU Mailman REST client v3.3.1"
[10/Feb/2021:13:41:53 +0000] "GET
/3.1/lists/ncpoa.lists.ccalternatives.org/roster/moderator HTTP/1.1" 200 90
"-" "GNU Mailman REST client v3.3.1"
[10/Feb/2021:13:41:53 +0000] "GET
/3.1/lists/ncpoa(a)lists.ccalternatives.org/config HTTP/1.1" 200 3173 "-" "GNU
Mailman REST client v3.3.1"
[10/Feb/2021:13:41:53 +0000] "GET
/3.1/lists/ncpoa.lists.ccalternatives.org/archivers HTTP/1.1" 200 100 "-"
"GNU Mailman REST client v3.3.1"
[10/Feb/2021:13:41:53 +0000] "GET
/3.1/lists/ncpoa.lists.ccalternatives.org/archivers HTTP/1.1" 200 100 "-"
"GNU Mailman REST client v3.3.1"
[10/Feb/2021:13:41:53 +0000] "GET
/3.1/lists/ncpoa(a)lists.ccalternatives.org/requests HTTP/1.1" 200 90 "-" "GNU
Mailman REST client v3.3.1"
[10/Feb/2021:13:41:54 +0000] "GET
/3.1/lists/ncpoa.lists.ccalternatives.org/member/christian%40safecomputing.o
rg HTTP/1.1" 404 26 "-" "GNU Mailman REST client v3.3.1"
[10/Feb/2021:13:41:54 +0000] "GET
/3.1/lists/ncpoa(a)lists.ccalternatives.org/requests HTTP/1.1" 200 90 "-" "GNU
Mailman REST client v3.3.1"
[10/Feb/2021:13:41:54 +0000] "GET
/3.1/lists/ncpoa(a)lists.ccalternatives.org/held?count=50&page=1 HTTP/1.1" 200
90 "-" "GNU Mailman REST client v3.3.1"
[10/Feb/2021:13:42:19 +0000] "GET /3.1/lists/ncpoa.lists.ccalternatives.org
HTTP/1.1" 200 453 "-" "GNU Mailman REST client v3.3.1"
[10/Feb/2021:13:42:19 +0000] "GET
/3.1/lists/ncpoa.lists.ccalternatives.org/roster/owner HTTP/1.1" 200 668 "-"
"GNU Mailman REST client v3.3.1"
[10/Feb/2021:13:42:19 +0000] "GET
/3.1/lists/ncpoa.lists.ccalternatives.org/roster/moderator HTTP/1.1" 200 90
"-" "GNU Mailman REST client v3.3.1"
-----Original Message-----
From: Mark Sapiro <mark(a)msapiro.net>
Sent: Thursday, February 18, 2021 10:33 AM
To: mailman-users(a)mailman3.org
Subject: [MM3-users] Re: archiving problem & updates
On 2/18/21 10:00 AM, Christian Stalberg via Mailman-users wrote:
> Archiving has stopped working. No changes were made to the server. How can
I diagnose and troubleshoot this please?
Start by looking at Mailman's logs and also see if there are messages to be
archived in Mailman's var/archives/hyperkitty/spool/ directory.
> Are there instructions for how to update mailman3 somewhere? Is there a
listing of bug fixes also?
There are some instructions at
<https://docs.mailman3.org/en/latest/upgrade-3.2.html>. Bug fixes are listed
in each project's 'news', e.g.,
<https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.
html>
for Mailman core and
<https://docs.mailman3.org/projects/hyperkitty/en/latest/news.html> for
HyperKitty.
--
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, 4 months
Re: Can't deliver mails in queue
by Nathanael Schneider
>> I then created a completely new List which did not exists in mm2.1,
>> subscribed two addresses and sent myself an EMail. That one worked as
>> intended. I then deleted the whole broken list and created it cleanly,
>> added the same two people, sent an email and nothing.
>
> This seems strange. If I understand, you are essentially saying the two
> lists are the same. I.e., you created a completely new List which did
> not exists in mm2.1, and that one worked. Then you deleted the whole
> broken list and created it cleanly ... What was different between this
> cleanly created list and the completely new List?
They were in fact not identical, as I changed some stuff in hopes to get
it up and running again quickly. I now changed the completely new List
to be identical with the cleanly created one (as far as postorius shows
me) and it still works just fine.
>> May 19 18:54:40 2021 (8280) Using agent: <mailman.mta.deliver.Deliver object at 0x7fb49b143780>
>> May 19 18:54:40 2021 (8280) IndividualDelivery to: nathanael(a)lumenliquid.net
>> May 19 18:54:40 2021 (8280) Using agent: <mailman.mta.deliver.Deliver object at 0x7fb4974541d0>
>> May 19 18:54:40 2021 (8280) IndividualDelivery to: nathanael(a)lumenliquid.net
>
> The fact that these are the only messages says that the attempt to send
> that message via smtp raised no exception as exceptions would have been
> logged, yet you say there's nothing in the maillog so there was no
> connect to Postfix. What are your settings for smtp_host: and
> smtp_port: in the [mta] section of mailman.cfg?
I set nothing explicitly as the default options fit my needs, so
localhost:25 it is to my knowledge. Postfix itself was configured by
Plesk and the config for mailman3 was manually added as prescribed. A
manual telnet on localhost 25 gives me the expected 220 message from
postfix.
>> I have no clue what to do with this. I then turned the debug module
>> loglevel to debug. Also nothing useful. Just an endless list of
>>
>> [...]
>> May 19 18:17:29 2021 (7209) [outgoing] <function deliver at
>> 0x7f2faf384c80>: <B9531076-2480-4925-9A2B-57802B53D5ED(a)gmx.de>
>> May 19 18:17:29 2021 (7203) [ArchiveRunner] starting oneloop
>> May 19 18:17:29 2021 (7203) [ArchiveRunner] ending oneloop: 0
>> May 19 18:17:29 2021 (7209) [OutgoingRunner] finishing filebase:
>> 1621441049.4089153+6dff56673dc64b890dd352941267782c264586dd
>> May 19 18:17:29 2021 (7209) [OutgoingRunner] doing periodic
>> May 19 18:17:29 2021 (7209) [OutgoingRunner] committing transaction
>> May 19 18:17:29 2021 (7209) [OutgoingRunner] checking short circuit
>> May 19 18:17:29 2021 (7209) [OutgoingRunner] ending oneloop: 1
>> May 19 18:17:29 2021 (7209) [OutgoingRunner] starting oneloop
>> May 19 18:17:29 2021 (7209) [OutgoingRunner] processing filebase:
>> 1621441049.4628382+6a0437ea387a2508ad947c0a51712075cbdb6d2e
>> May 19 18:17:29 2021 (7209) [OutgoingRunner] processing onefile
>> May 19 18:17:29 2021 (7209) [outgoing] <function deliver at
>> 0x7f2faf384c80>: <B9531076-2480-4925-9A2B-57802B53D5ED(a)gmx.de>
>> [...]
>>
>> Which also tells me nothing I can understand.
> It says the message in queue entry
> 1621441049.4089153+6dff56673dc64b890dd352941267782c264586dd is handled
> but gets requeued as
> 1621441049.4628382+6a0437ea387a2508ad947c0a51712075cbdb6d2e which
> presumably is handled and requeued again ...
Ok. Then I just need to figure out why it gets requeued. That also
explains why the out-queue folder keeps creating a single message with
different filenames over and over. But the logs keep silent about the
reason..
>> I have no clue what's
>> going wrong. (I've turned on debugging both on the original member list
>> and the reduced member list. Both hang on the first delivery they do).
>> If I restart mailman, the message gets correctly shunted as it is
>> interrupted mid-delivery. My maillogs don't register any activity beside
>> the listpost. Any ideas what I need to do to figure out what's not
>> working here or where the culprit could be? Not sure if it is related to
>> the mailinglist being in mailman2.1 before.
>
> I have no real understanding of why this isn't working. I don't think
> it's likely that it has to do with the mailing list being imported from
> MM 2.1, but I suppose it could be.
>
> How did you create and import the list? When you say you deleted the
> whole broken list and created it cleanly, what did you actually do?
My steps where basically what the migration guide told me to do. First,
I created the new list in postorius, I then copied the config.pck over
to the mailman directory, chowned it to mailman and imported it in the
venv using
mailman import21 list(a)example.com config.pck
Does import21 expect anything besides the config.pck? Maybe it couldn't
find the required files and botched something? I recreated the list by
deleting it in postorius and creating it anew. It could be that there is
some configuration that does not get cleaned properly? If it helps, I've
also made a document containing all the specific steps I used for my
server as I've tested the setup process first before rolling it out (not
the migration though) on a different server to get it done without a hitch.
--
Nathanael Schneider
4 years, 1 month
mailman3 exim4 and debian 1 problem fconnection lost
by roberto Burceni
[Mailman-Users] mailman3 and exim4 problem in debian bullseye
Good evening,
I'm configuring mailman3 with exim4 on a debian 11.
I followed the official documentation on mailman for exim. It seems to
be all rights, but I have a problem:
when I send a message to a new lists in exim logs I see that exim uses
correctly mailman router and transport.
Unfortunately in smtp.log in mailman3 log folder I have the following
error:
May 04 16:51:01 2021 (2337) ('127.0.0.1', 34746) sender:
servizioinformatico(a)uicbs.it
May 04 16:51:01 2021 (2337) ('127.0.0.1', 34746) Data: b'RCPT TO:
<listtest-unsubscribe(a)uicbs.it>'
May 04 16:51:01 2021 (2337) ('127.0.0.1', 34746) recip:
listtest-unsubscribe(a)uicbs.it
May 04 16:51:01 2021 (2337) ('127.0.0.1', 34746) Data: b'DATA'
May 04 16:51:02 2021 (2337) ('127.0.0.1', 34746) Data: b'QUIT'
May 04 16:51:02 2021 (2337) ('127.0.0.1', 34746) connection lost
May 04 16:51:02 2021 (2337) Connection lost during _handle_client()
This causes that messages are not sent from mailman to users. Have you
an idea of the problem?
Can it be a memory problem that causes that mailman responses are too
slow and exim closes the comunication before the end?
I have no other errors in other log files
Thank you in advance
--
Roberto Burceni
Linux System Admin & PHP developer
Esperto accessibilità siti web
E-mail: roberto(a)robertoburceni.it
Phone: +393358208080
P.iva: 04025840986mbre per il mat
4 years, 2 months