- Mailman-users - lists.mailman3.org

Hyperkitty displaying example.com
by Mark Dale Sept. 22, 2022

Sept. 22, 2022

Hi On a new installation I'm seeing "example.com" displayed at the top of the HyperKitty pages. I was expecting to see "lists.mydomainname.com", so I think I've missed something somewhere. Also, when a user signs up, the confirmation email reads as: ////////////////////////// SUBJECT: [example.com] Please Confirm Your E-mail Address FROM: postorius(a)lists.mydomainname.com BODY: Hello from example.com! You're receiving this e-mail because user yogibear has given your e- mail address to register an account on example.com. To confirm this is correct, go to https://lists.mydomainname.com/mailman3/accounts/confirm-email/NQ:1obAI3:Yw… Thank you for using example.com! example.com ////////////////////////// Any clues greatly appreciated. Thanks, Mark

2 2

Messages not being archived
by Mark Dale Sept. 20, 2022

Sept. 20, 2022

Hi I've just installed Mailman 3 using the Debian 11 package. Mailman-Version: 3.3.3 HyperKitty version 1.3.4 Postorius Version 1.3.4 The first list that I've added is receiving and sending mail okay, however the messages are not being archived. The logs report a HyperKitty error. I've copy-pasted that in at the end of this email. I've checked the following: ============================== /etc/mailman3/mailman.cfg contains: [archiver.hyperkitty] class: mailman_hyperkitty.Archiver enable: yes configuration: /etc/mailman3/mailman-hyperkitty.cfg ============================= The list has archiving configured on in Postorius. - Archive policy: Private archives - Active archivers: hyperkitty ============================= /etc/mailman3/mailman-hyperkitty.cfg has: [general] base_url: https://lists.mydomain.com/mailman3/archives #base_url: https://lists.mydomain.com/mailman3/hyperkitty/ api_key: aaaaaaaaaaaaaaaaaaaaaa ============================= /usr/share/mailman3-web/settings_local.py contains: ALLOWED_HOSTS = [ "localhost", '*' ] MAILMAN_ARCHIVER_KEY = 'aaaaaaaaaaaaaaaaaaaaaa' ============================= The headers of the emails received from the list show blanks for Archived-At and List-Archive: X-Mailman-Version: 3.3.3 Precedence: list Archived-At: <> List-Archive: <> ============================= /var/log/mailman3/mailman.log The errors in the log contain messages (that I'm clueless about) regarding HyperKitty. Sep 20 01:05:54 2022 (1293) HyperKitty failure on https://lists.mydomain.com/mailman3/archives/api/mailman/archive Sep 20 01:05:54 2022 (1293) Exception in the HyperKitty archiver: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> ... <title>503 Service Unavailable</title> ... Sep 20 01:05:54 2022 (1293) Traceback (most recent call last): File "/usr/lib/python3/dist-packages/mailman_hyperkitty/__init__.py", line 154, in _archive_message url = self._send_message(mlist, msg) File "/usr/lib/python3/dist-packages/mailman_hyperkitty/__init__.py", line 210, in _send_message raise ValueError(result.text) ... ============================= If anyone can point me in the right direction to get the archive happening, that'd be grand. Cheers, Mark

1 1

How to delete non-users
by Allan Hansen Sept. 17, 2022

Sept. 17, 2022

Hi all, This is a bit of an emergency: I am getting a bunch of complaints from potential list members of my lists that they can't subscribe and they don't get messages. Apparently, the issue is that they are non-members. I have never created any non-members but looking at the docs it seems that if someone sends a message to the list, they automatically become non-members. For individuals I have been able to delete their non-membership and they then could subscribe properly. I have looked at some of my most popular lists and they have hundreds of non-members! It will take me an awful amount of time to remove each one manually, and not doing it - handling each as they complain - is also a lot of waste of time and cause of frustration for all involved. I have tried scripting it with delmember, but it does not take the '-r nonmember' option ('findmember' does!). Can anyone help me find out how to a. delete all non-members of all my lists b. prevent MM3 from creating new non-members in the future (so I don't have to keep removing them) Any help with this is appreciated. Yours, Allan I'm still at Mailman Core Version GNU Mailman 3.3.3 (Tom Sawyer) Mailman Core API Version 3.1 Mailman Core Python Version 3.7.3 (default, Jan 22 2021, 20:04:44) [GCC 8.3.0] My system used to be kept up to date by EMWD, but since Brian died have not been able to get it updated, and I'm too scared (from my attempts at installing MM3) to attempt it myself. If the above can only be solved via an update, I'd appreciate a referral.

3 10

Held message notifications ending up in junk
by Tibor Molnar Sept. 15, 2022

Sept. 15, 2022

Hi there, I wonder if anyone else if having this trouble that all the held message notifications are landing in junk folder. Regards, Tibor

4 5

Messages not going to held queue
by Mail Person Sept. 14, 2022

Sept. 14, 2022

Hi all, Not sure why, but messages set to be held for moderation are appearing to be discarded. I've tried creating a new test list, adjusting settings at the user and list level, but when a user sends a message that should be held for moderation, nothing happens. smtp.log shows the message is going through but it doesn't get to the moderation queue.

3 8

Message-Footer after migrating to Mailman3
by christopher.claus＠tgcamberg1848.de Sept. 13, 2022

Sept. 13, 2022

Hello together, I migrated a number of lists from mailman2 to mailman3 using the import functionality. Everthing works fine and the new lists are in use. Currently I´m using the maxking-docker-images with postorius: Mailman Core Version GNU Mailman 3.3.3 (Tom Sawyer) Mailman Core API Version 3.1 Mailman Core Python Version 3.8.5 (default, Feb 19 2021, 09:27:16) [GCC 9.3.0] After this migration I started a refactoring with the list-styles specially with message-footers. Already the old lists in mailman2 were confused in some configuration details an I was clear to import this "misconfiguration" and clean it up afterwards. But this was much more difficult than expected: some lists are using a footer (from the mailman2-config) and there is no record in the template-section visible. Further I found no configuration item which points to this "old" footer. I found the file [code] /usr/lib/python3.8/site-packages/mailman/templates/de/list:member:generic:footer.txt [/code] which includes the old footer: [code] _______________________________________________ $display_name Mailingliste -- $listname Zur Abmeldung von dieser Mailingliste senden Sie eine Nachricht an ${short_listname}-leave@${domain} [/code] but no configuration item to disable this behaviour. I created a new template list:member:regular:footer for the list to override the footer. But the old footer is still used - in detail: the resulting message sent to all subcribers of the list contains only the footer and the content sent to the list is an attachement of that "footer-message". This is the basic reason why I want to change it. In the logfiles I found an error and a warning: [code] ERROR 2021-05-24 16:22:22,895 1648 django.security.DisallowedHost Invalid HTTP_HOST header: 'tgc_mailman_web:8000'. The domain name provided is not valid according to RFC 1034/1035. WARNING 2021-05-24 16:22:22,896 1648 django.request Bad Request: /postorius/api/templates/list/homepage.gruppe.tgcamberg1848.de/list:member:regular:footer [/code] Obviously I have a problem with the hostname. I set [code] POSTORIUS_TEMPLATE_BASE_URL=http://tgc_mailman_web:8000 [/code] where tgc_mailman_web is my container name. This URL ist stored in the DB-table "template" for the name=list:member:regular:footer. A call to my fqdn or to localhost [code] wget http://localhost:8000/postorius/api/templates/list/homepage.gruppe.tgcamber… [/code] will return the footer itself - this works fine. Therefore, should i set POSTORIUS_TEMPLATE_BASE_URL to http://localhost:8000? I think, resolving this issue will use the newly configured footer. But I started with the intention to remove alle footers due to the attachement situation described above. Does anybody have an idea how to change the configuration of my list? Are these problems probably related to the import? Currently we are using more then 25 lists with a lot of users. Manually recreating all lists is not possible an could only be a test for a single list. Best regards, chrclaus

6 18

"The content of this message was lost."
by skenny＠scss.tcd.ie Sept. 12, 2022

Sept. 12, 2022

I see that this issue has been discussed in a few other postings - it seems to be affecting us here at the moment. We're running Mailman 3.3.5 inside maxking's mailman-core/mailman-web Docker containers (version 0.4.3). This morning I composed a mail message and included two of our mailing lists in the To: field. On the first list I'm a member with address of the form my_addr_1(a)this.com. On the second I'm on it with a different address, my_addr_2(a)that.com. In the case of each list, Mailman held the message for moderation. As administrator, I accepted both. I then got the full message in my inbox at my_addr_1(a)this.com, but in my other inbox at my_addr_2(a)that.com, the body of the message was not present. Instead it read The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list. I'm wondering what's the best thing to do here. Should I maybe downgrade to an earlier version of Mailman (i.e. an earlier version of maxking's Docker containers), pending resolution of this issue ...? Thanks for any advice. Stephen PS: The Mailman web interface "System Information" link reports: Mailman Core Version GNU Mailman 3.3.5 (Tom Sawyer) Mailman Core API Version 3.1 Mailman Core Python Version 3.8.10 (default, May 6 2021, 06:30:44) [GCC 9.3.0]

2 2

How to set uWSGI buffer size in mailman3 with Dcoker
by bob B Sept. 8, 2022

Sept. 8, 2022

Running into an issue where users are getting a 502 bade gateway and we traced it down to the headers that are getting sent when they request web pages. This looks like our issue ********************* By default, uWSGI allocates a very small buffer (4096 bytes) for the headers of each request. If you start receiving “invalid request block size” in your logs, it could mean you need a bigger buffer. Increase it (up to 65535) with the buffer-size option. ********* So any idea on how to set this in mailman3 running in the maxking docker environment?

2 2

mailman3 not working for mailman21 lists
by blup＠fortytwo.ch Sept. 6, 2022

Sept. 6, 2022

I installed mailman3 on a server where mailman21 was installed before. Newly created mailinglists work fine. But if I create mailinglists with a name that was previously used on mailman21 nothing works (same behaviour with and without import of old configs and archives; no logs). I purged all old mailman21 config and data and also old postfix aliases (or at least I do think so). If I send a mail to old list list1(a)a.b and new list list2(a)a.b I get the following logs /var/log/mail.log Aug 21 22:17:40 basilisgg postfix/lmtp[1728]: ED2171120BF: to=<list2(a)c.a.b>, orig_to=<list2(a)a.b>, relay=127.0.0.1[127.0.0.1]:8024, delay=0.31, delays=0.17/0.01/0/0.13, dsn=2.0.0, status=sent (250 Ok) Aug 21 22:17:40 basilisgg postfix/lmtp[1728]: ED2171120BF: to=<list1(a)c.a.b>, orig_to=<list1(a)a.b>, relay=127.0.0.1[127.0.0.1]:8024, delay=0.31, delays=0.17/0.01/0/0.13, dsn=2.0.0, status=sent (250 Ok) /var/log/mailman3/smtp.log ug 21 22:17:40 2022 (934) Available AUTH mechanisms: LOGIN(builtin) PLAIN(builtin) Aug 21 22:17:40 2022 (934) Peer: ('127.0.0.1', 44746) Aug 21 22:17:40 2022 (934) ('127.0.0.1', 44746) handling connection Aug 21 22:17:40 2022 (934) ('127.0.0.1', 44746) Data: b'LHLO c.a.b' Aug 21 22:17:40 2022 (934) ('127.0.0.1', 44746) Data: b'MAIL FROM:<....>' Aug 21 22:17:40 2022 (934) ('127.0.0.1', 44746) sender: .... Aug 21 22:17:40 2022 (934) ('127.0.0.1', 44746) Data: b'RCPT TO:<list2(a)c.a.b>' Aug 21 22:17:40 2022 (934) ('127.0.0.1', 44746) recip: list2(a)c.a.b Aug 21 22:17:40 2022 (934) ('127.0.0.1', 44746) Data: b'RCPT TO:<list1(a)c.a.b>' Aug 21 22:17:40 2022 (934) ('127.0.0.1', 44746) recip: list1(a)c.a.b Aug 21 22:17:40 2022 (934) ('127.0.0.1', 44746) Data: b'DATA' Aug 21 22:17:40 2022 (934) ('127.0.0.1', 44746) Data: b'QUIT' Aug 21 22:17:40 2022 (934) ('127.0.0.1', 44746) connection lost Aug 21 22:17:40 2022 (934) Connection lost during _handle_client() Aug 21 22:17:46 2022 (936) <166111306097.933.1775779871266718007@...> smtp to list2(a)a.b for 1 recips, completed in 3.1437485218048096 seconds How can I get more info on why the mail for list1 isn't processed? Where could old mailman21 or postfix info on list1 be stored that causes mailman3 to not handle the list properly? How can I diff the config between list1 and list2 from the command line? Regards Diana

5 12

FYI: Django security releases issued: 4.0.6 and 3.2.14
by Guillermo Hernandez (Oldno7) Aug. 29, 2022

Aug. 29, 2022

https://www.djangoproject.com/weblog/2022/jul/04/security-releases/ Django security releases issued: 4.0.6 and 3.2.14 Posted by *Mariusz Felisiak* on Julio 4, 2022 In accordance with our security release policy <https://docs.djangoproject.com/en/dev/internals/security/>, the Django team is issuing Django 4.0.6 <https://docs.djangoproject.com/en/dev/releases/4.0.6/> and Django 3.2.14 <https://docs.djangoproject.com/en/dev/releases/3.2.14/>. These release addresses the security issue detailed below. We encourage all users of Django to upgrade as soon as possible. CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments Trunc() and Extract() database functions were subject to SQL injection if untrusted data was used as a kind/lookup_name value. Applications that constrain the lookup name and kind choice to a known safe list are unaffected. This security release mitigates the issue, but we have identified improvements to the Database API methods related to date extract and truncate that would be beneficial to add to Django 4.1 before it's final release. This will impact 3rd party database backends using Django 4.1 release candidate 1 or newer, until they are able to update to the API changes. We apologize for the inconvenience. Thanks Takuto Yoshikai (Aeye Security Lab) for the report. This issue has severity "high" according to the Django security policy. -- ___________________________________________ 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.

5 18