From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-2.9 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00, URIBL_BLOCKED shortcircuit=no autolearn=unavailable version=3.3.2 X-Original-To: meta@public-inbox.org Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 00BC41F8B3; Sun, 19 Oct 2014 05:30:29 +0000 (UTC) Date: Sun, 19 Oct 2014 05:30:29 +0000 From: Eric Wong To: "W. Trevor King" Cc: meta@public-inbox.org Subject: Re: [RFC] ssoma-mda: Use the email subject as the commit message Message-ID: <20141019053029.GA1205@dcvr.yhbt.net> References: <20141018210400.GA2448@dcvr.yhbt.net> <20141018215020.GK17200@odin.tremily.us> <20141018234323.GA5226@dcvr.yhbt.net> <20141019034815.GL17200@odin.tremily.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20141019034815.GL17200@odin.tremily.us> List-Id: "W. Trevor King" wrote: > On Sat, Oct 18, 2014 at 11:43:23PM +0000, Eric Wong wrote: > > Sounds like a good idea to make it fall back if require fails. Can > > you do it or would you like me to handle it in Perl? > > If you tell me the Perl idiom for that, I can write up a patch. In eval { require Foo; }; my $have_foo = $@ ? 0 : 1; That won't perform any imports, but I think most of those modules do not require imports. > > public-inbox also wraps spam filtering/learning (SpamAssassin) + > > sanitization, and that's arguably more important than the web UI. > > Then I'd shift those hooks over to ssoma-mda. Actually, I'd probably > leave it up to folks to hook those into their mail server / MDA before > messages get as far as ssoma-mda. Spam filtering is a generic issue; > there's no need to build all the checks you'd want (also greylisting, > DKIM, SPF, …) into ssoma-mda itself. Uh, you just contradicted yourself :) public-inbox is that mail server/MDA layer before ssoma for me. > That sounds good to me, but I don't see the need to have generation > numbers to do that. We just need to patch mlmmj to support: Heh, I haven't even thought of mlmmj integration much (even though I use it myself for some lists). Thanks for the heaps of info on notmuch. > > I have much mail in gzipped mboxes (new mail in Maildirs); so I've > > been sticking to mairix for my local search needs. Just having the > > mail archived in git+ssoma without mboxes is the goal one day... > > You use gzipped mboxes instead of Maildirs for everything just from a > disk space perspective? No, I only use gzipped mboxes for old mail (several months). One glaring weakness of mairix is the lack of incremental import mode, so it does at least readdir() scans which get expensive on maildirs. I'll have to look into how notmuch can integrate with my setup. What I like about mairix is it generates a new Maildir of results (which I can nuke at any time) and doesn't care what MUA I use. I'd like to get notmuch to do that for my local mail. > Patching notmuch to read email directly from > Git shouldn't be too bad, since there aren't many views where you > actually need the full email (usually the stuff in the Xapian index is > sufficient). Just having notmuch return a Message-ID should be sufficient to retrieve the full email from ssoma, actually.