From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id B16161F4B4; Mon, 14 Sep 2020 20:55:46 +0000 (UTC) Date: Mon, 14 Sep 2020 20:55:46 +0000 From: Eric Wong To: meta@public-inbox.org Subject: Re: brain dump detached/external index so far... Message-ID: <20200914205546.GA28639@dcvr> References: <20200913065550.GA2337@dcvr> <20200914160114.kdwed3rkb52ibal4@chatter.i7.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200914160114.kdwed3rkb52ibal4@chatter.i7.local> List-Id: Konstantin Ryabitsev wrote: > I think several virtual inboxes makes more sense than always one global > search, as people may want to search something like "all Linux kernel > discussions" or "all gcc/compiler discussions". There could be different > frontends to indicate which search is running -- e.g. > "kernel.lore.kernel.org" vs. "gcc.lore.kernel.org". It might be better to have one big index, still. Groups can be Xapian terms which are defined/redefined as-needed for filtering. It would be helpful when compiler bugs are found in the course of kernel development. > As an off-side grumbling, we found out that AWS SES (their email > processing service) will force-rewrite all message IDs without any > option to prevent this. So, a single message with multiple recipients > will arrive with a unique Message-ID to each one of them. > > This is so broken, it blows my mind, but AWS doesn't care to fix it. Eeeep. I wonder if there's some benefit for Amazon in doing this... I can understand why centralized communications providers would Embrace, Extend, Extinguish email; but I didn't think they'd have anything to gain by making email worse. (I'm still anti-monopolist, anyways)