From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 2BB843858D39 for ; Thu, 18 Aug 2022 13:50:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2BB843858D39 Received: from reform (unknown [178.228.201.193]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id CC0D1300070C; Thu, 18 Aug 2022 15:50:55 +0200 (CEST) Received: by reform (Postfix, from userid 1000) id 4DD872E8157E; Thu, 18 Aug 2022 15:50:54 +0200 (CEST) Date: Thu, 18 Aug 2022 15:50:54 +0200 From: Mark Wielaard To: "Frank Ch. Eigler" Cc: Overseers mailing list , Simon Marchi Subject: Re: inbox.sourceware.org experiment Message-ID: References: <20220813141403.GL5520@gnu.wildebeest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: overseers@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Overseers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2022 13:51:01 -0000 Hi Frank, On Wed, Aug 17, 2022 at 05:33:40PM -0400, Frank Ch. Eigler wrote: > > [...] > > > Yes, understood that the extra indexing can do extra searches. My > > > question was about utility/need for this. > > > > The use seems obvious to me for anybody using the web based archives > > to generate tailored message/mbox results, specifically date ranged > > searches seem pretty mandatory since otherwise you essentially just > > need to keep clicking, next, next, next. > > I was under the impression that your main interest in p-i was the easy > addressability and availability of raw emails, for use such as with > git-am. Are there other users pining for this kind of thing? I am not sure that is my main interest in public-inbox, but yes, I do really like public-inbox because it allows tools like b4 (which I have already tested against our instance) and piem (not tested yet) to easily pick up and apply patch emails. https://git.kernel.org/pub/scm/utils/b4/b4.git/tree/README.rst https://docs.kyleam.com/piem/ I think others will also use those (or similar) tools. But I primarily expect users to use the public-inbox archives as a way to access the mailinglists without having to subscribe, but still be able to easily get the actual (raw) messages (either through git, atom, mbox, nntp or imap) to follow the conversations. Which I think is the main interesting thing public-inbox offers. > > But also to get specific messages based on author or subject. On > > specific use case for public-inbox is to not have to be subscribed > > to a list to read it [...] > > You are expecting people to use the xapian query language for this > stuff? Mailman offers that style of click-click browsing already. Not just users, but also tools, yes. And not for clicking through the archive, but to generate tailored sets of messages they are interested in. IMHO the public-inbox archives are a lot more usable than the mailman style archives. > > [...] > > So this is before mailman sees the message, so we do need to do a > > spam-check. > > No, postfix already spam checks everything upon receipt, before delivery. OK, but mailman still also blocks some messages which I have to approve/deny as list admin (this only happens once or twice a month, so maybe that is just spam we have to tolerate?) > > And I think postfix sets ORIGINAL_RECIPIENT already, we just need to > > make sure it is one of the addresses for a list in the config. > > This shouldn't be something that we need to write code to do, if it needs > to be done at all. OK. Assuming the process runs as the inbox user it will pick up the /home/inbox/.public-inbox/config file which should have all information. > > But what generates /etc/mailman/aliases itself? Can we hook into that > > to trigger generation of this aliases-inbox file? Otherwise if we add > > a new mailman list it won't work. > > It must be some mailman administrative script. Just crontab another > one. Under which account should this crontab run? mailman doesn't seem to have any crontabs at the moment. > > And do we need to update/regenerate > > /etc/aliases.db and/or /etc/mailman/aliases.db ? > > The proposal is to not touch /etc/aliases* NOR /etc/mailman/aliases*. > The proposal is to generate a new file like > /etc/postfix/mailman-inbox-aliases from /etc/mailman/aliases. That > new file would be the one postfix would read. It could be texthash: > rather than hash: so postmap would not even be necessary for updates. > That depends on whether the relevant alias-expansion postfix process > is short- or long-lived. OK, I see the following in /etc/postfix.main: # CGF 2020-03-08 12:49 alias_maps = hash:/etc/aliases, hash:/etc/mailman/aliases # CGF 2020-03-18 14:10 EST - newaliases wasn't affecting /etc/mailman/aliases alias_database = hash:/etc/aliases, hash:/etc/mailman/aliases So I assume calling newaliases regenerates the hash/.db files. I can write a script to generate mailman-inbox-aliases this weekend when I have stable internet access again. Will post to the list before installing to make sure I don't accidentially break something. Cheers, Mark