From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from elastic.org (elastic.org [96.126.110.187]) by sourceware.org (Postfix) with ESMTPS id B43E53858D39 for ; Wed, 17 Aug 2022 21:33:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B43E53858D39 Received: from vpn-home.elastic.org ([10.0.0.2] helo=elastic.org) by elastic.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oOQfV-0001aK-8W; Wed, 17 Aug 2022 21:33:41 +0000 Received: from very.elastic.org ([192.168.1.1]) by elastic.org with esmtp (Exim 4.94.2) (envelope-from ) id 1oOQfU-0003yc-Pa; Wed, 17 Aug 2022 17:33:40 -0400 Received: from fche by very.elastic.org with local (Exim 4.95) (envelope-from ) id 1oOQfU-000YMQ-P6; Wed, 17 Aug 2022 17:33:40 -0400 Date: Wed, 17 Aug 2022 17:33:40 -0400 From: "Frank Ch. Eigler" To: Mark Wielaard 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-Sender-Verification: "" X-Spam-Status: No, score=-101.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, USER_IN_WELCOMELIST, USER_IN_WHITELIST autolearn=ham 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: Wed, 17 Aug 2022 21:33:43 -0000 Hi - > [...] > > 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? > 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. > [...] > 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. > 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. > 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. > 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. - FChE