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-ASN: 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 F235B1F9F4; Sun, 21 Nov 2021 10:13:42 +0000 (UTC) Date: Sun, 21 Nov 2021 10:13:42 +0000 From: Eric Wong To: Konstantin Ryabitsev Cc: meta@public-inbox.org Subject: Re: RFC: should lei inject its own "Received:" header? Message-ID: <20211121101342.M903763@dcvr> References: <20211119204916.grergcuzj5gcic6c@meerkat.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211119204916.grergcuzj5gcic6c@meerkat.local> List-Id: Konstantin Ryabitsev wrote: > Hello: > > I wonder if lei should inject its own "received"-like header on writing to a > maildir/imap target -- to indicate where the copy of the email came from. I > don't think it should use the actual Received: header, as this may cause some > weird SPF/DMARC issues, but perhaps something like: > > X-Lei-Received: from https://lore.kernel.org/all/; Fri, 19 Nov 2021 14:32:44 -0500 > > Just a random thought. Probably not in the blob itself. Addition of extra headers means slower and less-effective dedupe (not just for lei, but also for deduplicating FSes (which operate at block-layer) and potential FUSE implementation). Perhaps the mail_sync.sqlite3 stuff could be taught to track the origin of a blob, though...