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

[MM3-users] Re: External MTA incoming mail: configuration

by Odhiambo Washington

On Tue, Aug 6, 2024 at 10:46 AM Roland Giesler via Mailman-users < mailman-users(a)mailman3.org> wrote: > On 2024/08/05 19:59, Mark Sapiro wrote: > > I see this reply is now moot as you have now configured list mail to > > go directly to the Mailman server, but ... > > > > On 8/5/24 03:44, Roland Giesler via Mailman-users wrote: > >> > >> In the logs of the MTA I see this however: warning: do not list > >> domain fast.za.net in BOTH virtual_mailbox_domains and relay_domains > >> > >> Mailman creates these entries, but postfix doesn't like it. I don't > >> see any mail delivered to the mailman yet. Is this the problem? > > > > Probably not. It is telling you that mail to the fast.za.net domain > > cannot both be delivered to local mailboxes (virtual_mailbox_domains) > > and relayed to foreign hosts (relay_domains) > > > Thanks, yes, I have since assumed that to be the case. > > > >> In the MTA postfix main.cf: > >> > >> relay_domains = hash:/etc/mailman3/data/postfix_domains > > > > >> cat /etc/mailman3/data/postfix_domains > >> ... > >> > >> and also > >> > >> local_recipient_maps=$virtual_mailbox_maps, > >> hash:/etc/mailman3/data/postfix_lmtp > >> > >> cat /etc/mailman3/data/postfix_lmtp > >> ... > > > > How about > > > > transport_maps = hash:/etc/mailman3/data/postfix_lmtp > I can't remove the $virtual_mailbox_maps entry, since Power-mailinbox > (PMiaB) uses that. It may make Mailman3 work, but break PMiaB). > > > > > >> > >> Then there's: > >> virtual_mailbox_domains=sqlite:/etc/postfix/virtual-mailbox-domains.cf > >> > >> cat /etc/postfix/virtual-mailbox-domains.cf > >> dbpath=/home/user-data/mail/users.sqlite > >> query = SELECT 1 FROM users WHERE email LIKE '%%@%s' UNION SELECT 1 > >> FROM aliases WHERE source LIKE '%%@%s' UNION SELECT 1 FROM > >> auto_aliases WHERE source LIKE '%%@%s' > >> > >> When I run that query in sqlite3, it returns no records, so I'm not > >> sure how this is supposed to work. %s to me means that first > >> argument, so is this used in python and then %s is the argument sent > >> to this query? > > > > > > See https://www.postfix.org/sqlite_table.5.html > > > > `%%` is replaced with `%` which is a SQL wildcard matching anything > > and `%s` is replaced by the key postfix is looking for, i.e. the > > domain that it is asking about. > > > > So, that query becomes > > > > SELECT 1 FROM users WHERE email LIKE '%(a)fast.za.net' UNION SELECT 1 > > FROM aliases WHERE source LIKE '%(a)fast.za.net' UNION SELECT 1 FROM > > auto_aliases WHERE source LIKE '%(a)fast.za.net' > > > > I.e, it returns true if any user or alias or auto_alias has an address > > ending in '@fast.za.net' and if that's true the mail to any > > '@fast.za.net' address including list mail will be stored locally. > > Ah, thank you! I created a ticket at MiaB about this, so I'll post your > response there. The %s had be stumped at first, but now it's clear. > > > > > > If you really have local users on box2.gtahardware.co.za with > > addresses '@fast.za.net' and you want to relay list mail to lists > > '@fast.za.net', you need to see > > > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h… > . > > Thank you for that! From that it seems it may still be possible to use > PMiaB as my MTA after, but I'll work through that reference and test it > and report back. > I think that ALL MTAs have the concept of local domains (for which mails are delivered to 'local mailboxes') and remote domains (aka relay domains) for which mail is relayed to another host which has the mailboxes. So in your case box2.gtahardware.co.za (this is FQDN) could be handling local emails, e.g roland(a)gtahardware.co.za, johndoe(a)gtahardware.co.za, etc. Those are local, and so gtahardware.co.za is a local domain. However, fast.za.net is a relay domain and all mail to XXX(a)fast.za.net should be relayed to the MM3 server. If your MTA does not have this concept, then it's either not ready for prime time or it wasn't intended to have such ability. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

2 years, 2 months

[MM3-users] Re: Subscription Request asking for Confirmation instead of Moderation

by Henry Hartley

> -----Original Message----- > From: Mark Sapiro <mark(a)msapiro.net> > Sent: Wednesday, August 27, 2025 21:10 > > On 8/27/25 09:22, Henry Hartley via Mailman-users wrote: > > > > 1. Are there particular headers that are causing the email to go to the > Confirmation page instead of the Approval page? Or are there particular > headers we can add that will help with this? > > 2. Is there any way for us to move an address from the Confirmation > Pending page to confirmed on the backend (preferably through the web > interface, but on the server itself, if necessary)? > > > > Here are the headers sent with the subscriber's email address changed to > FirstLast(a)SCHOOL.edu and our BCC mailbox domain changed to COMPANY.com. > > > > MIME-Version: 1.0 > > Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes > > Content-Transfer-Encoding: 8Bit > > X-Mailer: Drupal > > Return-Path: FirstLast(a)SCHOOL.edu > > Sender: FirstLast(a)SCHOOL.edu > > From: FirstLast(a)SCHOOL.edu > > Bcc: mailman-noreply(a)COMPANY.com > > Are these all the headers? If so, you need a To: header. sending the envelope to > the list-join address is not sufficient. The message must either have a To: to the > list-join address or a To: to the list-request address with a Subject: or body of > `join` That's what I was given and I didn't look at it carefully enough. My apologies. There was indeed a To: header, so it wasn't that. I got a copy of the actual email and was able to see all the headers, which I've pasted below (with the exception of two X-Microsoft-Antispam-xxx headers, which are fairly long). I've anonymized it similarly to the above as well as changing the IP address to 192.169.0.0, which is not what's really there. Note also that the mailto: links above (and below, if applicable) are not in the text I'm pasting but have been added somewhere along the line. Received: from CO1PR05MB8586.namprd05.prod.outlook.com (2603:10b6:303:ed::5) by LV8PR05MB10549.namprd05.prod.outlook.com with HTTPS; Fri, 8 Aug 2025 16:57:54 +0000 Received: from DM6PR02CA0123.namprd02.prod.outlook.com (2603:10b6:5:1b4::25) by CO1PR05MB8586.namprd05.prod.outlook.com (2603:10b6:303:ed::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9009.18; Fri, 8 Aug 2025 16:57:52 +0000 Received: from DS3PEPF0000C37A.namprd04.prod.outlook.com (2603:10b6:5:1b4:cafe::9e) by DM6PR02CA0123.outlook.office365.com (2603:10b6:5:1b4::25) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9009.15 via Frontend Transport; Fri, 8 Aug 2025 16:57:52 +0000 Authentication-Results: spf=fail (sender IP is 192.168.0.0) smtp.mailfrom=SCHOOL.edu; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=SCHOOL.edu;compauth=fail reason=000 Received-SPF: Fail (protection.outlook.com: domain of SCHOOL.edu does not designate 192.168.0.0 as permitted sender) receiver=protection.outlook.com; client-ip=192.168.0.0; helo=esa2.COMPANY.iphmx.com; Received: from esa2.COMPANY.iphmx.com (192.168.0.0) by DS3PEPF0000C37A.mail.protection.outlook.com (10.167.23.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9009.8 via Frontend Transport; Fri, 8 Aug 2025 16:57:52 +0000 X-CSE-ConnectionGUID: 6gzl16giR+OI2R+uEItzYA== X-CSE-MsgGUID: N0dF+IkxQxqpO1VcWOCK3A== X-IronPort-AV: E=Sophos;i="6.17,274,1747713600"; d="scan'208";a="40347776" Received: from ex2019-3.COMPANY.com ([74.119.60.23]) by esa2.COMPANY.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 08 Aug 2025 12:57:50 -0400 Received: from EX2019-1.COMPANY.com (10.1.146.19) by EX2019-3.COMPANY.com (10.1.146.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26; Fri, 8 Aug 2025 12:57:50 -0400 Received: from COmailout.COMPANY.com (10.1.146.69) by EX2019-1.COMPANY.com (10.1.146.19) with Microsoft SMTP Server id 15.2.1748.26 via Frontend Transport; Fri, 8 Aug 2025 12:57:50 -0400 Received: from WEBSERVER.COMPANY.com ([10.115.9.208]) by COmailout.COMPANY.com over TLS secured channel with Microsoft SMTPSVC(10.0.17763.1697); Fri, 8 Aug 2025 12:57:50 -0400 Received: by WEBSERVER.COMPANY.com (Postfix, from userid 33) id 998892A0BDB; Fri, 8 Aug 2025 12:57:48 -0400 (EDT) To: <MAILINGLIST-join(a)DOMAIN.org> Subject: Subscribe MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable X-Mailer: Drupal Sender: <FIRSTLAST(a)SCHOOL.edu> From: <FIRSTLAST(a)SCHOOL.edu> Message-ID: <20250808165748.998892A0BDB(a)WEBSERVER.COMPANY.com> Date: Fri, 8 Aug 2025 12:57:48 -0400 Return-Path: FIRSTLAST(a)SCHOOL.edu X-OriginalArrivalTime: 08 Aug 2025 16:57:50.0067 (UTC) FILETIME=[92CA3430:01DC0885] X-MS-Exchange-Organization-ExpirationStartTime: 08 Aug 2025 16:57:52.4416 (UTC) X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit X-MS-Exchange-Organization-ExpirationInterval: 1:00:00:00.0000000 X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit X-MS-Exchange-Organization-Network-Message-Id: ba671e8c-86f5-429d-8c2d-08ddd69cb6ab X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: a066de23-9711-4de4-8725-431a39ebcafb:0 X-MS-Exchange-Organization-MessageDirectionality: Incoming X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS3PEPF0000C37A:EE_|CO1PR05MB8586:EE_|LV8PR05MB10549:EE_ X-MS-Exchange-Organization-AuthSource: DS3PEPF0000C37A.namprd04.prod.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Office365-Filtering-Correlation-Id: ba671e8c-86f5-429d-8c2d-08ddd69cb6ab X-MS-Exchange-Organization-ExpirationInterval: 0:12:30:00.0000000 X-MS-Exchange-Organization-ExpirationIntervalReason: TenantCustomized X-MS-Exchange-AtpMessageProperties: SA|SL X-MS-Exchange-Organization-SCL: -1 X-Microsoft-Antispam: BCL:0;ARA:13230040; X-Forefront-Antispam-Report: CIP:192.168.0.0;CTRY:US;LANG:en;SCL:-1;SRV:;IPV:CAL;SFV:SKN;H:esa2.COMPANY.iphmx.com;PTR:esa2.COMPANY.iphmx.com;CAT:NONE;SFS:(13230040);DIR:INB; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Aug 2025 16:57:52.2718 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ba671e8c-86f5-429d-8c2d-08ddd69cb6ab X-MS-Exchange-CrossTenant-Id: a066de23-9711-4de4-8725-431a39ebcafb X-MS-Exchange-CrossTenant-AuthSource: DS3PEPF0000C37A.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB8586 X-MS-Exchange-Transport-EndToEndLatency: 00:00:02.2435910 X-MS-Exchange-Processed-By-BccFoldering: 15.20.8989.011 -- Henry Hartley Westat RB 2151

1 year, 2 months

[MM3-users] Re: Custom templates (was: Re: Re: nginx configuration on a multitasking server)

by David Newman

On 1/14/22 4:54 PM, Mark Sapiro wrote: > On 1/14/22 11:56 AM, David Newman wrote: >> >> I created a pending subscription request on a test list. Here is the >> text I'm using in a file called 'list:admin:action:subscribe.txt' >> (minus the rows of hypens): >> >> ---------- >> >> >> As list administrator, your authorization is required for a mailing >> list subscription request approval: >> >> For: $member >> List: $listname >> >> At your convenience, visit: >> >> https://${domain}/mailman/admindb/lists/${short_listname}.${domain}/ > > This looks like a Mailman 2.1 URL. Are you sure you don't want something > like > > https://${domain}/mailman3/lists/${short_listname}.${domain}/ Yes. The server redirects MM3-style requests to MM2.1 URLs. I need to determine why, but that may be a different issue than the templates one. There's nothing obvious in this vhost's nginx config that would generate the redirect. Will check, if I can't resolve this I'll open a different thread. > >> >> to approve or deny the request. >> >> ---------- >> >> Instead the message that goes out at midnight daily reads like this: > > > That's a different message. It is sent from the `mailman notify` command > run by cron. It's built from the list:admin:notice:pending template. OK, wrong template then. > >> >> On successive nights I have placed copies of the >> 'list:admin:action:subscribe.txt' file above in these locations: >> >> mm/var/templates/lists/test.lists.domain.tld/en > > I hope you mean > > /opt/mailman/mm/var/templates/lists/test.lists.domain.tld/en Yes > >> /opt/mailman/mm/var/templates/site/en > > > Either of those should work. The lists one will take priority over the > site one for that list. > > >> and then in Postorius, with the same contents as above. > > If you set a template in Postorius, it takes priority. If you later > decide you want to use one in /opt/mailman/mm/var/templates/ you have to > delete the postorius one. > > >> The file versions are owned by the mailman user, and have 0644 >> permissions. Not sure this is necessary but I've restarted the >> mailman3 and mailmanweb services each time after a change. >> >> There is no sign of trouble in the MM3 or web logs. The only thing I >> see is in the Postfix log, where the shorter and less helpful message >> goes out each night. I don't see anything in the template docs about >> this. >> >> Questions: >> >> 1. What to do to get the custom message working? > > > It should work. I suspect you need to go to the list's Settings -> > Automatic Responses and set `Admin immed notify` to Yes. It's enabled. I think this triggers notifications only for new subscription requests, not pending ones. > > >> 2. Is there a way to trigger a subscribe reminder for one list only? > > > If by subscribe reminder you mean the `list:admin:action:subscribe.txt` > message, yes that's the above list setting. If you mean the one sent > from the `mailman notify` command, see `mailman notify --help` for the > options. You can specify one or more lists (default is all lists) via > options and put them in your cron. > > >> Asking because there are other lists on this server with other >> requests pending, and I don't want to bother other moderators with >> multiple reminders per day. Not a big deal, but it would be nice to >> test this with one list rather than waiting up to 24 hours after each >> change. > > > You can test `mailman notify` at any time by running it by hand. Thanks. This still isn't working as intended. I took these steps: 1. Created the file '/opt/mailman/mm/var/templates/lists/test.lists.domain.tld/en/list:admin:action:pending.txt' with these contents (minus the hyphens top and bottom): ---------- The $listname list has $count moderation requests waiting. $data At your convenience, visit: https://${domain}/mailman3/lists/${short_listname}.${domain}/ to approve or deny the request. ---------- 2. Restarted the mailman3 and mailmanweb services 3. As the mailman user, ran the command 'mailman notify -l test.lists.domain.tld -v' This generated an email message but its contents were the same as in my previous post: ---------- The test(a)lists.domain.tld list has 1 moderation requests waiting. Held Subscriptions: User: letmein(a)domain.tld Please attend to this at your earliest convenience. ---------- What I'm trying to do here is replicate a feature from MM2.1, where pending notifications had URLs embedded in the message. That's not available out of the box in MM3, and if there's a place for feature requests I'd be glad to ask that this be made the default. For now, though, I'm looking to get this customization working. Thanks. dn

4 years, 9 months

[MM3-users] Re: messages stuck in the bad queue

by Ken Alker

--On Sunday, June 25, 2023 9:18 AM -0700 Mark Sapiro <mark(a)msapiro.net> wrote: > On 6/24/23 9:54 PM, Ken Alker wrote: >> I am working on a mail server that was migrated from mailman V2 to >> mailman V3 in February. I just noticed that there are over 1000 >> messages in the bad queue. All of the messages in the bad queue are >> dated 2/2/23 and all have a timestamp within a one-hour window of each >> other. >> >> I used mailman qfile to inspect five random emails in the bad queue and >> so far they are all "successfully subscribed" emails, > > This is a bit strange. See below. > >> but I presume >> there are no guarantees there aren't others mixed in there that might be >> legitimate emails (ie. I just unshunted 140 emails in the shunt queue >> and they were all good emails and all got processed). > > > Presumably these were shunted due to some issue that was subsequently fixed. That is my assumption. I didn't unshunt them until I had V3.3.8 completed, figuring the previous version/install had some bug/mistake. Fortunately, they all got processed (with one problem, which I brought up in another thread). >> I figure that the easiest way to inspect these 1000 emails is just to >> have them re-delivered. I tried moving one from the bad queue to the >> shunt queue and I ran "mailman unshunt" but nothing happened. > > What does nothing happened mean? "mailman unshunt" should move the > message to the original queue which was stored in the 'whichq' attribute > in the msgdata when the message was shunted. Since this wasn't a shunted > message, there's no 'whichq' attribute so it goes to the 'in' queue. > I.e., "mailman unshunt" would have moved the message from the 'shunt' > queue to the 'in' queue. If the message wound up back in the shunt queue, > there should be messages in mailman.log indicating why. I moved the .psv file from the bad queue into the shunt queue. I then ran "mailman unshunt" (as user 'mailman' while in the virtual environment). I tailed mailman.log during this process and no logs were spit out. The date stamp on the .psv file never changed (maybe it does not when being moved between queues?) and, AFAICT, the file never moved from the shunt queue. I waited maybe five minutes, tops. >> Is there a way to reprocess the bad queue? > > You could just move the messages to the 'in' queue. I just now tried moving the same message into the 'in' queue but, again, nothing happened. I left it in there for five minutes. Do I have to run a program to get it to act on the 'in' queue (I presume that there is a "runner" that is always looking and taking care of this already as I presume this is the queue where all 'normal' traffic is handled). Here are the (obfusacted) results of "mailman qfile /opt/mailman/mm/var/queue/shunt/1675389793.6945386+2aeaf0015558c9d8380c96142c3fa9d03a8142bc.psv" (the message I was experimenting with): [----- start pickle -----] <----- start object 1 -----> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: THE-list subscription notification From: email(a)obfuscated.com To: the-list-owner(a)lists.obfuscated.com Message-ID: <167538979369.2390432.521344217673230839(a)obfuscated.net> Date: Thu, 02 Feb 2023 18:03:13 -0800 Precedence: bulk user(a)domain.tld has been successfully subscribed to THE-list. <----- start object 2 -----> { '_parsemsg': False, 'envsender': 'email(a)obfuscated.com', 'listid': 'the-list.obfusacted.com', 'nodecorate': True, 'recipients': {'person(a)domain.tld'}, 'reduced_list_headers': True, 'version': 3} [----- end pickle -----] >> Also, what exactly is the bad queue? > > If Mailman's content filtering is enabled and Filter Action is Preserve, > messages which have no remaining content after content filtering are put > in the 'bad' queue. These are the only messages put there. When this > happens there should a log message like > > <message-id> preserved in file base <queue_file> > > It is unclear to me how these 1000+ messages wound up in the 'bad' queue. > If you have logs from Feb 2, they might help. My guess is there was some > MTA misrouting that caused these list welcome messages (from some mass > subscribe?) to be rerouted to the list posting address combined with some > bad content filtering settings that removed all the content, but that > seems pretty far fetched. Unfortunately, I don't have logs going that far back. I don't think your concept is far fetched. I'm 99% sure this was the day that the migration from V2 to V3 took place so this was certainly the result of some type of mass-subscription-import into V3. The V3 that was installed or the install itself definitely had problems, which is why I just did an upgrade/overhaul to V3.3.8 this past week. Many/most of the strange issues that were occurring seem to be cleared up.

3 years, 4 months

[MM3-users] Time Stand Still

by Barry Warsaw

Somewhen in the dark recesses of intarweb history, I found myself as the project leader for both Jython (née JPython) and GNU Mailman. I'd been involved with Jython since it was invented by Jim Hugunin around the time he came to work with us at Pythonlabs. I'd been contributing to Mailman since we inherited John Viega's Python-based Dave Matthews Band list server, and put it to use replacing python.org's Majordomo installation. I'd enjoyed both projects, but knew I could not lead both, so I had to make a choice. I chose to turn over Jython to a team that's done a much better job over the years than I ever could have. Something about email, and especially the communication and collaboration patterns that it facilitates, really fascinated me. I know, I know, but we all have our lapses of sanity. Mine has lasted almost 20 years, a bit more than "momentary" perhaps. I've rarely gotten paid to work on Mailman, but it did provide me some great opportunities. Most notably it led to my 10 year stint at Canonical. I was originally hired on there to integrate mailing lists with Launchpad, and Mailman was the obvious choice. I learned a ton doing that project, and working within the constraints of integrating the two Python-based systems, especially since Launchpad was originally not free software and Mailman was GPL'd. Later, the Zope-based Launchpad source code was released under the AGPL, making much of the monkeypatching unnecessary, but by then the system was solid and reliable, and you don't fix what's not broken. Except, I guess I did. I took a lot of the lessons from that work, along with a good hard look at all the problems with Mailman 2, and began to break another cardinal rule of software development: second system syndrome. The result is Mailman 3. It took forever, and we're still not at complete feature parity with Mailman 2, but at least it's Real Enough to be used at many Real Sites, including python.org and lists.fedoraprojects.org. It would be ridiculous for me to take significant credit for this. I have to acknowledge the amazing user community -- you! -- for all the support, patches, suggestions, feedback, patience, criticism, donations, and contributions that you've given to the project, and to me personally over the years. And my deepest gratitude goes to all the core developers that have stayed or come and gone, but most especially the current Cabal: Abhilash Raj, Aurelien Bompard, Florian Fuchs, Mark Sapiro, Stephen J. Turnbull, Terri Oda. You should know that each and every one of them is truly awesome, both in what they contribute technically, and in their amazing friendships. Mailman is infinitely better because of their involvement, and I've loved spending time with them over the years at the Pycon sprints, making releases and sharing teas and meals. My blog is called We Fear Change, and that's humorously taken from a 90's bit in Mike Myer's excellent Wayne's World movie (a phrase actually uttered by the brilliant Dana Carvey as Garth). The irony of course is that while we all may fear change, it's the one constant thing we can count on. And in fact, we *require* change to thrive, because if you aren't changing, you aren't alive. Time, and being engaged with life's vagaries, means there's no alternative to change; it must be embraced. And so, with a vague reference to the many (good!) changes in my personal and professional life, I'm announcing that I'm stepping down from the project leadership role of GNU Mailman, effective... nowish! And it's with unanimous agreement among the GNU Mailman Steering Committee (a.k.a. the Mailman Cabal), that we are announcing Abhilash Raj as the new project leader. If you don't recognize Abhilash's name, you probably aren't paying attention, at least to Mailman 3. Abhilash came to us in 2013 as a Google Summer of Code student, and he's become one of the project's most valuable contributors. His list of accomplishments is long, and it includes everything from redesigning the website, to integrating CI with our GitLab build system, porting our code to the SQLAlchemy ORM, adding MySQL support, revving up adoption through his Docker images, along with his great coding work on Core, Postorius, HyperKitty, and mailmanclient. This transition is good for the project too. Email, its defining protocols and standards, and its role in our daily lives, has changed profoundly since the early days of Mailman. A fresh perspective and enthusiasm will help keep Mailman relevant to the changing ways we -- especially the FLOSS and tech communities -- communicate. Please join me in supporting Abhilash in every way possible as he takes over in this new role as project leader. I'll be here when and if needed, even as I create space in my "spare" time for... Something Else. I look forward to the vision that Abhilash will bring to the project, and I know that he will do a great job. To me, Mailman has always been about collaboration, and the best way for it to succeed is for you to continue to contribute your insights, experiences, opinions, and skills with positive intention. -Barry https://www.wefearchange.org/

8 years, 11 months

[MM3-users] Re: E-mail every minute: "Cron <www-data@sharky5> ..."

by Robert Heller

At Mon, 8 Jul 2024 00:16:48 +0300 Odhiambo Washington <odhiambo(a)gmail.com> wrote: > > On Sun, Jul 7, 2024 at 8:43â¯PM Robert Heller <heller(a)deepsoft.com> wrote: > > > At Sun, 7 Jul 2024 19:48:02 +0300 Odhiambo Washington <odhiambo(a)gmail.com> > > wrote: > > > > > > > > On Sun, Jul 7, 2024 at 7:16ÃÂ¢Ãâ¬ÃÂ¯PM Robert Heller <heller(a)deepsoft.com> > > wrote: > > > > > > > At Sun, 7 Jul 2024 18:52:05 +0300 Odhiambo Washington < > > odhiambo(a)gmail.com> > > > > wrote: > > > > > > > > > > > > > > On Sun, Jul 7, 2024 at 4:12ÃÆÃÆÃâÃÂ¢ÃÆÃâÃÂ¢ÃâÃÂ¬ÃÆÃâÃâÃÂ¯PM Robert > > Heller <heller(a)deepsoft.com> > > > > wrote: > > > > > > > > > > > What am I missing? I *think* I have mailman3 *mostly* setup, but > > there > > > > > > are > > > > > > still some configuration things that are missing, but I am not sure > > > > how to > > > > > > fix > > > > > > them (the docs are NOT clear). > > > > > > > > > > > > > > > > Which docs are you relying on? > > > > > > > > https://docs.mailman3.org/en/latest/config-web.html > > > > > > > > I presume these are the official docs for mailman3 -- maybe they > > aren't? > > > > > > > > > > > > > > How about this - > > > > https://docs.mailman3.org/en/latest/install/virtualenv.html > > > > > ?? > > > > > > > > I'm not using a virtual environment. I'm using all native Debian 12 > > > > packages, > > > > installed via apt. The virtual environment docs are actually even worse > > > > (even > > > > more confusing). > > > > > > > > > Worse? :-) > > > > Even more confusing. Both sets of docs make various assumptions and don't > > really explain things properly. Like everywhere where "settings.py" is > > mentioned, it really means "/etc/mailman3/mailman-web.py" > > > > No! It means /etc/mailman3/settings.py - literally! > > > > In any case, the virtual environment docs are hard to relate to a "native" > > install and are generally hard to follow, since they seem to jump all over > > the > > place. > > > When one day you'll be able to internalize what a Python virtual > environment is, you'll realize that it's VERY convenient. > You will actually embrace it from that point onwards. > > (Spaghetti docs?) And it is hard to replace the various (and not > > always consistent) virtual environment paths and settings files to the > > "native" > > paths. > > > Actually, if you're this inclined to run everything natively, MM3 is > perhaps not for you. Why? Because you'll not easily find help here. > We focus on the virtual environment only as the standard.. Why? Because no > one is willing to deal with ALL the OS-centric packaging > out there. Python virtual environment is universal across all the OSes, I > can say. > > > > The "official" docs are just not useful to me, since I am not using a > > virtual > > environment. If a virtual environment is recomended, what is the point of > > the > > Debian 12 packages? > > > We cannot answer that here. I guess they are meant for people like you who > strive under pain :-) > With the Python virtual environment, I can install and manage MM3 in almost > any *nix OS. > > > > Are they just not meant to be used? Really? Do you mean that I should use > > a separate package management system for Mailman3? That > > really sucks. > > > > Yes, they are meant to be used. Noone denies that. However, they are not > packaged by the Mailman Developers. > Did you read one response from Mark Sapiro where he said, and I quote: > ``` > If you prefer to use the Debian packages, that's fine, but if using the > Debian packages, your primary resource for support, documentation, bug > reports, etc. should be Debian. See https://wiki.list.org/x/12812344 > ``` > So yes, go ahead and use the Debian packages. No one is stopping you. I uninstalled them and have given up on mm3. It means the main mailling list I have been hosting for the past while (more than a decade), will have to migrate to something else... :-( > > -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

2 years, 3 months

[MM3-users] Re: How to delete non-users

by Allan Hansen

Hi Mark, Thank you for looking into it. We are very strict about memberships, which we are because of spam, bots and malicious contributors and because we don't want anyone to think that our lists are used for spam: When a user applies, the server sends a message to the moderator. The moderator communicates with the potential member and accepts or does not accept the application. At this point, if the user has not been accepted, but tried to send a message to the list, a non-member membership is created. When he/she logs in to list his/her account, the list to which he/she holds non-memberships will be listed and the user will think that he/she has been properly subscribed (why else are the lists listed). Noone notices the column that shows the role as 'nonmember.' So he/she thinks that the subscription request has been accepted, but nothing is working. That's why the 'non-member' record is an issue. I also don't see why non-members are automatically added, filling up the database with junk (at least from our point of view, with all respect). But our lists don't accept messages from non-members. Such messages are quietly discarded, as most are spam, as mentioned above. So now the user is neither getting emails from the lists nor is unable to send messages to the list. The next step for the user is to complain to me. ☹ I have looked for a template that could be used to warn someone when he/she is added as a non-member, but did not find one. It's also not clear that I'd want one, as most of these non-subscriptions are by spammers and I prefer not to reply to spammers. __ I tried your suggestion below, Mark. Here's my transcript: ********** Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. >>> lm = getUtility(IListManager) >>> for l in lm: ... for nm in l.nonmembers.members: ... nm.unsubscribe() ... >>> ********** I did this twice, once with commit() and once typing ctrl/d (ctrl/D) just gave me a beep. Calling commit() did not return to the ... as in your example, but showed the >>> prompt, so I tried ctrl/D (beep) and then ctrl/d (exit). I then went to the Postorius page for one of the lists and found that all the non-members were still present. Yours, Allan On 9/16/22, 15:01 , "Mark Sapiro" <mark(a)msapiro.net> wrote: On 9/16/22 11:19, Allan Hansen wrote: > 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 don't understand. the fact that an address is a non-member of a list should not impact subscribing that address as a member. > 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. What is actually happening when the non-member attempts to subscribe as a member? What do they do and what it the result? > 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 If you have access to `mailman shell` you could do: ``` $ mailman shell Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. >>> lm = getUtility(IListManager) >>> for l in lm: ... for nm in l.nonmembers.members: ... nm.unsubscribe() ... >>> commit() ``` > b. prevent MM3 from creating new non-members in the future (so I don't have to keep removing them) nonmembers are an integral part of Mailman 3's architecture. The basic idea is a nonmember has a moderation action and setting a nonmembers moderation replaces MM 2.1's adding that address to one of *_these_nonmembers (The legacy *_these_nonmembers attributes still exist, but only to support regexps). It would require extensive modification to not create nonmembers. However, I still don't understand why the presence of a nonmember record is an issue. -- 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, 1 month

[MM3-users] Re: Held messages not delivered after approval

by Krinetzki, Stephan

Hi Mark, Hi Stephen, so I updated now my configuration a bit. The logging is now default: [logging.archiver] datefmt: %b %d %H:%M:%S %Y [logging.archiver] format: %(asctime)s (%(process)d) %(message)s [logging.archiver] level: info [logging.archiver] path: mailman.log [logging.archiver] propagate: no [logging.bounce] datefmt: %b %d %H:%M:%S %Y [logging.bounce] format: %(asctime)s (%(process)d) %(message)s [logging.bounce] level: info [logging.bounce] path: bounce.log [logging.bounce] propagate: no [logging.config] datefmt: %b %d %H:%M:%S %Y [logging.config] format: %(asctime)s (%(process)d) %(message)s [logging.config] level: info [logging.config] path: mailman.log [logging.config] propagate: no [logging.database] datefmt: %b %d %H:%M:%S %Y [logging.database] format: %(asctime)s (%(process)d) %(message)s [logging.database] level: warn [logging.database] path: mailman.log [logging.database] propagate: no [logging.debug] datefmt: %b %d %H:%M:%S %Y [logging.debug] format: %(asctime)s (%(process)d) %(message)s [logging.debug] level: info [logging.debug] path: debug.log [logging.debug] propagate: no [logging.error] datefmt: %b %d %H:%M:%S %Y [logging.error] format: %(asctime)s (%(process)d) %(message)s [logging.error] level: info [logging.error] path: mailman.log [logging.error] propagate: no [logging.fromusenet] datefmt: %b %d %H:%M:%S %Y [logging.fromusenet] format: %(asctime)s (%(process)d) %(message)s [logging.fromusenet] level: info [logging.fromusenet] path: mailman.log [logging.fromusenet] propagate: no [logging.gunicorn] datefmt: %b %d %H:%M:%S %Y [logging.gunicorn] format: %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s" [logging.gunicorn] level: info [logging.gunicorn] path: mailman.log [logging.gunicorn] propagate: no [logging.http] datefmt: %b %d %H:%M:%S %Y [logging.http] format: %(asctime)s (%(process)d) %(message)s [logging.http] level: info [logging.http] path: mailman.log [logging.http] propagate: no [logging.locks] datefmt: %b %d %H:%M:%S %Y [logging.locks] format: %(asctime)s (%(process)d) %(message)s [logging.locks] level: info [logging.locks] path: mailman.log [logging.locks] propagate: no [logging.mischief] datefmt: %b %d %H:%M:%S %Y [logging.mischief] format: %(asctime)s (%(process)d) %(message)s [logging.mischief] level: info [logging.mischief] path: mailman.log [logging.mischief] propagate: no [logging.plugins] datefmt: %b %d %H:%M:%S %Y [logging.plugins] format: %(asctime)s (%(process)d) %(message)s [logging.plugins] level: info [logging.plugins] path: plugins.log [logging.plugins] propagate: no [logging.root] datefmt: %b %d %H:%M:%S %Y [logging.root] format: %(asctime)s (%(process)d) %(message)s [logging.root] level: info [logging.root] path: mailman.log [logging.root] propagate: no [logging.runner] datefmt: %b %d %H:%M:%S %Y [logging.runner] format: %(asctime)s (%(process)d) %(message)s [logging.runner] level: info [logging.runner] path: mailman.log [logging.runner] propagate: no [logging.smtp] datefmt: %b %d %H:%M:%S %Y [logging.smtp] every: $msgid smtp to $listname for $recip recips, completed in $time seconds [logging.smtp] failure: $msgid delivery to $recip failed with code $smtpcode, $smtpmsg [logging.smtp] format: %(asctime)s (%(process)d) %(message)s [logging.smtp] level: info [logging.smtp] path: smtp.log [logging.smtp] propagate: no [logging.smtp] refused: $msgid post to $listname from $sender, $size bytes, $refused failures [logging.smtp] success: $msgid post to $listname from $sender, $size bytes [logging.subscribe] datefmt: %b %d %H:%M:%S %Y [logging.subscribe] format: %(asctime)s (%(process)d) %(message)s [logging.subscribe] level: info [logging.subscribe] path: mailman.log [logging.subscribe] propagate: no [logging.task] datefmt: %b %d %H:%M:%S %Y [logging.task] format: %(asctime)s (%(process)d) %(message)s [logging.task] level: info [logging.task] path: mailman.log [logging.task] propagate: no [logging.vette] datefmt: %b %d %H:%M:%S %Y [logging.vette] format: %(asctime)s (%(process)d) %(message)s [logging.vette] level: info [logging.vette] path: mailman.log [logging.vette] propagate: no Further, I edited the logrotate: /var/log/mailman/mailman-logs/*.log { missingok daily compress delaycompress nomail notifempty rotate 14 dateext su mailman mailman olddir /var/log/mailman/mailman-logs/oldlogs postrotate /bin/kill -HUP `cat /opt/mailman/var/master.pid 2>/dev/null` 2>/dev/null || true # Don't run "mailman3 reopen" with SELinux on here in the logrotate # context, it will be blocked /opt/mailman/mailman-venv/bin/mailman reopen >/dev/null 2>&1 || true endscript } It is now more like the Fedora one and seems to be better. Now in the mailman.log I see the HOLD messages and the approved messages. The smtp.log logs just the incoming Mail, which seems to be fine. So, here a complete Trace: smtp.log: Aug 05 10:18:40 2025 (217984) Available AUTH mechanisms: LOGIN(builtin) PLAIN(builtin) Aug 05 10:18:40 2025 (217984) Peer: ('127.0.0.1', 57074) Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) handling connection Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) >> b'LHLO lists.rwth-aachen.de' Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) >> b'MAIL FROM:<SENDER> SIZE=15187' Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) sender: SENDER Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) >> b'RCPT TO:<stephansmodliste(a)lists.example.com>' Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) recip: stephansmodliste(a)lists.example.com Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) >> b'DATA' Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) >> b'QUIT' Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) connection lost Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) Connection lost during _handle_client() The mailman.log: Aug 05 10:18:40 2025 (217983) HOLD: stephansmodliste(a)lists.example.com post from SENDER held, message-id=<b93e46d8342f42039c99e1d2d036c711@SENDERDOMAIN>: The message is not from a list member Aug 05 10:21:04 2025 (218015) held message approved, message-id: <b93e46d8342f42039c99e1d2d036c711@SENDERDOMAIN> [05/Aug/2025:10:21:04 +0200] "POST /3.1/lists/stephansmodliste(a)lists.example.com/held/211056 HTTP/1.1" 204 0 "-" "GNU Mailman REST client v3.3.5" [05/Aug/2025:10:21:04 +0200] "GET /3.1/lists/stephansmodliste(a)lists.example.com/held?count=0&page=1 HTTP/1.1" 200 90 "-" "GNU Mailman REST client v3.3.5" [05/Aug/2025:10:21:04 +0200] "GET /3.1/lists/stephansmodliste(a)lists.example.com/held?count=10&page=1 HTTP/1.1" 200 90 "-" "GNU Mailman REST client v3.3.5" [05/Aug/2025:10:21:04 +0200] "GET /3.1/lists/stephansmodliste(a)lists.example.com/requests/count?token_owner=moderator HTTP/1.1" 200 73 "-" "GNU Mailman REST client v3.3.5" [05/Aug/2025:10:21:04 +0200] "GET /3.1/lists/stephansmodliste(a)lists.example.com/held/count HTTP/1.1" 200 73 "-" "GNU Mailman REST client v3.3.5" Aug 05 10:21:05 2025 (217986) Cannot connect to SMTP server localhost on port 25 The last error is a very often in the mailman.log: Aug 05 09:46:12 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 09:46:13 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 09:46:13 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 09:46:14 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 09:46:24 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 09:50:22 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 09:50:24 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 09:53:30 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 09:55:01 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 09:55:01 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 09:55:09 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 09:57:44 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 09:57:46 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 09:58:50 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 09:58:52 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 09:58:52 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 09:58:53 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 09:58:53 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 09:58:53 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 10:01:18 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 10:02:02 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 10:07:11 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 10:10:36 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 10:11:35 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:16:04 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:16:05 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 10:16:07 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:16:58 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 10:17:42 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 10:18:30 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:20:13 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 10:21:05 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:28:08 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:28:08 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 10:28:31 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 10:28:37 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:28:44 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 10:28:47 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 10:28:50 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:28:57 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 10:29:22 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 10:29:40 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 10:29:41 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:30:37 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:30:37 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 10:30:50 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:31:15 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 10:33:42 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:33:53 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:34:27 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 10:34:28 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:38:25 2025 (230250) Cannot connect to SMTP server lists.example.com on port 25 Aug 05 10:38:25 2025 (230247) Cannot connect to SMTP server lists.example.com on port 25 Even after changing the smtp_host in mailman.cfg this error appears randomly. Sadly the mail does not get delivered. -- Stephan Krinetzki IT Center Gruppe: Anwendungsbetrieb und Cloud Abteilung: Systeme und Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel: +49 241 80-24866 Fax: +49 241 80-22134 krinetzki(a)itc.rwth-aachen.de www.itc.rwth-aachen.de Social Media Kanäle des IT Centers: https://blog.rwth-aachen.de/itc/ https://www.facebook.com/itcenterrwth https://www.linkedin.com/company/itcenterrwth https://twitter.com/ITCenterRWTH https://www.youtube.com/channel/UCKKDJJukeRwO0LP-ac8x8rQ -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Tuesday, August 5, 2025 12:51 AM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: Held messages not delivered after approval On 8/4/25 00:21, Krinetzki, Stephan wrote: >> >> And for every one of those shunted messages there should be an exception with traceback logged in mailman.log. Those tracebacks should be helpful. > > If there were any. Maybe the "debug" level should be "info". But for which logs? The standard logging levels from lowest to highest are debug info warning error critical Whatever level is set for a log results in all messages of that level or higher being logged. I.e. if the log's level is debug, all messages for that log of any level should be logged. For every shunted message, a message like `SHUNTING: <file name without the .pck extention>` preceded by the exception and traceback is logged to error.log with level error. See https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/core/runner.py… > Maybe the restart at night after the lograte maybe the issue. As I said before, blindly restarting Mailman is a bad idea. On servers that I maintain, I always verify that all queues are empty before stopping or restarting Mailman. If necessary, I'll kill the incoming runner and wait for the out queue to empty and then stop mailman. If you want to do this daily, you could automate that., e.g. ``` if queues empty: restart Mailman else: when in queue is empty, sigterm incoming runner when out queue is empty, stop Mailman when Mailman stopped, start Mailman ``` The stop/start is needed because a simple restart at that point won't start the sigtermed incoming runner. -- 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/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… This message sent to krinetzki(a)itc.rwth-aachen.de

1 year, 2 months

[MM3-users] Re: messages stuck in the bad queue

by Ken Alker

--On Sunday, June 25, 2023 2:47 PM -0700 Mark Sapiro <mark(a)msapiro.net> wrote: > On 6/25/23 1:31 PM, Ken Alker wrote: >> >> I moved the .psv file from the bad queue into the shunt queue. I then >> ran "mailman unshunt" (as user 'mailman' while in the virtual >> environment). I tailed mailman.log during this process and no logs >> were spit out. The date stamp on the .psv file never changed (maybe >> it does not when being moved between queues?) and, AFAICT, the file >> never moved from the shunt queue. I waited maybe five minutes, tops. > > > I forgot that the extension in the `bad` queue is `.psv` (for preserve). > You have to rename it to `.pck`. Ah! I noticed the file extension difference but only for a fleeting moment, and I convinced myself during that moment that I must have looked at the original one (.pck) incorrectly (even though I knew it stood for "pickle"... and so the vaguely-noted discrepancy never made it to the stop of the stack... but it eventually may have, but I still wouldn't have know how that would affect the queued file. That solves that issue. >>>> Is there a way to reprocess the bad queue? >>> >>> You could just move the messages to the 'in' queue. > > > Changing .psv to .pck in the process. this can be done, e.g., by > ``` > for file in `ls var/queue/bad/*.psv;do mv /var/queue/bad/$file > /var/queue/in/${file/psv/pck};done > ``` I moved one message by hand, and, wow.. the runner just gobbles it up... fast! >> I just now tried moving the same message into the 'in' queue but, again, >> nothing happened. I left it in there for five minutes. Do I have to >> run a program to get it to act on the 'in' queue (I presume that there >> is a "runner" that is always looking and taking care of this already as >> I presume this is the queue where all 'normal' traffic is handled). > > > Again, you need to change the extension to .pck. > > >> Here are the (obfusacted) results of "mailman qfile >> /opt/mailman/mm/var/queue/shunt/1675389793.6945386+2aeaf0015558c9d8380c9 >> 6142c3fa9d03a8142bc.psv" (the message I was experimenting with): >> >> [----- start pickle -----] >> <----- start object 1 -----> >> MIME-Version: 1.0 >> Content-Type: text/plain; charset="us-ascii" >> Content-Transfer-Encoding: 7bit >> Subject: THE-list subscription notification >> From: email(a)obfuscated.com >> To: the-list-owner(a)lists.obfuscated.com >> Message-ID: <167538979369.2390432.521344217673230839(a)obfuscated.net> >> Date: Thu, 02 Feb 2023 18:03:13 -0800 >> Precedence: bulk >> >> user(a)domain.tld has been successfully subscribed to THE-list. >> >> <----- start object 2 -----> >> { '_parsemsg': False, >> 'envsender': 'email(a)obfuscated.com', >> 'listid': 'the-list.obfusacted.com', >> 'nodecorate': True, >> 'recipients': {'person(a)domain.tld'}, >> 'reduced_list_headers': True, >> 'version': 3} >> [----- end pickle -----] > > > I was assuming these were list welcome messages which they aren't. They > are owner notifications, so they were sent to the -owner address and > processed through the owner-pipeline, but unless the Debian package > changed the default-owner-pipeline, it doesn't contain mime-delete so how > they ended up in the `bad` queue is still a mystery. > > However, what would be the point of resending these at this time? Because I didn't know if they were ALL subscribe notices or if there were other people's emails mixed in. I felt, at the time, that it would be easier to requeue them and then be able to manipulate the results in my email client (ie. sort by subject) than to try to do it at the Unix level. That said, since there is more than one queue I'd have to move them into, the sorting process would require manipulating/viewing the messages at the Unix level first anyway and if I have to do that I might as well just inspect them all at the Unix level and skip the re-injection, as you noted. Also, after countless hours of learning over the past two days, I'm more qualified to do that now. So, I modified your suggested script thusly: for file in `ls var/queue/bad/*.psv` do mailman qfile $file >>results done and then compared the number of times "subscription notification" appeared in the results file (grep subscription\ notification results | wc) to the total numbers of "bad" messages (ls var/queue/bad | wc) and they matched (1142 of each). And just for fun and as a second check, I did a "grep subscription results | sort | uniq" and ended up with three lines of output; one for each mailing list import, and nothing more. It's things like that that really make me appreciate and enjoy the Unix shell. Thanks for the wisdom and for a slice of your time; I'm learning a lot and I appreciate the help. Ken Alker KA6KEN

3 years, 4 months

[MM3-users] Re: Please help - Held message is crashing mailman.

by Alex King

Thanks for your help Mark, it's ideal having the pointer to the issue in gitlab. I'll raise a bug with Ubuntu because this makes mailman3 in their LTS version unusable for me. Perhaps they can backport a fix for their version in LTS, otherwise they may have a backport or PPA source where I can get a 3.2 version, or just pin some packages from cosmic or disco. I think documenting this will be useful to people who hit the issue in future (Bionic/18.04 is supported until 2023, and likely the most used until 20.04 is released). Thanks, Alex On 7/04/19 4:29 AM, Mark Sapiro wrote: > On 4/5/19 10:27 PM, Alex King via Mailman-users wrote: >> Hi, >> >> I've used mailman a lot in the past, and decided to install mailman3 in >> a recent install. I'm unimpressed so far, it seems buggy. >> >> Running on Ubuntu 18.04.2 LTS from packages, mailman3 3.1.1-9, >> mailman3-web 0+20170523-14, python-django-postorius 1.1.2-3. >> >> After a few messages, I now can't go to the "Held Messages" in >> postorius, I get a 500 error. >> >> I tried to interact on the command line, but could not work out how. >> Reading >> https://mailman.readthedocs.io/en/latest/src/mailman/docs/install.html >> and >> https://mailman.readthedocs.io/en/latest/src/mailman/commands/docs/shell.ht…, >> I tried: >> >> # mailman shell >> Welcome to the GNU Mailman shell >> >>>>> command = cli('mailman.commands.cli_withlist.shell') >> Traceback (most recent call last): >> File "/usr/lib/python3.6/code.py", line 91, in runcode >> exec(code, self.locals) >> File "<console>", line 1, in <module> >> NameError: name 'cli' is not defined >> >> I did a lot of reading of the manual and googled, but I have no idea >> where the cli object is supposed to come from.....? The documentation >> is confusing. > > The line > > command = cli('mailman.commands.cli_withlist.shell') > > in > <https://mailman.readthedocs.io/en/latest/src/mailman/commands/docs/shell.ht…> > is dependent upon some behind the scenes setup to make the doctests > work. Granted this is confusing, but basically all that does is set > things up for the doctests to run the 'mailman shell' command. It is not > intended to be run from within 'mailman shell'. > > >> Anyway, after some trial and error, i found: >> >> # mailman shell >> Welcome to the GNU Mailman shell >>>>> list_manager = getUtility(IListManager) >>>>> m=list_manager.get("committee(a)[redacted].org") >>>>> from mailman.interfaces.requests import IListRequests >>>>> requests = IListRequests(m) >>>>> [x for x in requests.held_requests][0].id >> 8 >>>>> requests.get_request(8) >> Traceback (most recent call last): >> File "/usr/lib/python3.6/code.py", line 91, in runcode >> exec(code, self.locals) >> File "<console>", line 1, in <module> >> File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", >> line 85, in wrapper >> return function(args[0], config.db.store, *args[1:], **kws) >> File "/usr/lib/python3/dist-packages/mailman/model/requests.py", line >> 120, in get_request >> result.data_hash, expunge=False) >> File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", >> line 85, in wrapper >> return function(args[0], config.db.store, *args[1:], **kws) >> File "/usr/lib/python3/dist-packages/mailman/model/pending.py", line >> 138, in confirm >> value = json.loads(keyvalue.value) >> File "/usr/lib/python3.6/json/__init__.py", line 354, in loads >> return _default_decoder.decode(s) >> File "/usr/lib/python3.6/json/decoder.py", line 339, in decode >> obj, end = self.raw_decode(s, idx=_w(s, 0).end()) >> File "/usr/lib/python3.6/json/decoder.py", line 355, in raw_decode >> obj, end = self.scan_once(s, idx) >> json.decoder.JSONDecodeError: Unterminated string starting at: line 1 >> column 1 (char 0) >> >> It seems something was written out to disk that can't be read in for >> some reason (assuming a json object on disk?) > > This is <https://gitlab.com/mailman/mailman/issues/385> which should be > fixed by <https://gitlab.com/mailman/mailman/merge_requests/333>. The > fix in in Mailman core version 3.2.0 > > >> How do I debug this further? How do I find the json being decoded? Any >> help would be appreciated. (I found mailman2 just worked, I was happy >> with that.) > > The issue is in storing a pickled representation of the json encoding of > 'rule_misses'. This gets very long if you have lots of header filters, > and with at least the mysql backend gets truncated in the database which > causes the Unterminated string error. > > I'm not sure what your options are for upgrading. The current Debian > packages are all >= 3.2.0 [1], but Ubuntu doesn't get 3.2.0 until cosmic > (18.10) [2]. > > [1] https://packages.debian.org/search?keywords=mailman3 > [2] https://packages.ubuntu.com/search?keywords=mailman3 > >> (My colleague posted a bug about this I believe but I don't have the >> link to that.) > > I haven't seen it. > >

7 years, 6 months

Search results for query "sapiro"