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,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 ED2E41F8B3; Mon, 20 Oct 2014 00:49:08 +0000 (UTC) Date: Mon, 20 Oct 2014 00:49:08 +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: <20141020004908.GA23299@dcvr.yhbt.net> References: <20141018210400.GA2448@dcvr.yhbt.net> <20141018215020.GK17200@odin.tremily.us> <20141018234323.GA5226@dcvr.yhbt.net> <20141019034815.GL17200@odin.tremily.us> <20141019053029.GA1205@dcvr.yhbt.net> <20141019173059.GM17200@odin.tremily.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20141019173059.GM17200@odin.tremily.us> List-Id: "W. Trevor King" wrote: > On Sun, Oct 19, 2014 at 05:30:29AM +0000, Eric Wong wrote: > > 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. > > And then if have_foo, we ‘use Foo’ to get the import? No need to import for the Email::* modules I don't think. "use" is evaluated at compile/parse time, so you can't use it lazily outside of a string eval. "require" is always lazy, I think. I think you can just call "IPC::Run::run" directly (instead of just "run") > > > > 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. > > Filtering spam is something that lots of folks want (folks who may not > be interested in Git archives), and it should happen at the MTA level > (e.g. [1]) or in a procmail chain (e.g. [2]). The spamc hook > shouldn't be tied to any Git-archive stuff. I'd shift the Git > metadata extraction to ssoma-mda, use the Postfix filtering to drop > spam for everyone, use procmail to deliver mail for everyone, and then > call ssoma-mda from ~meta/.procmailrc. I don't disagree with the metadata extraction for ssoma-mda; but everything above that layer (including public-inbox) should be open to interpretation. I don't use procmail myself, for example; and I know folks who would want to use extra/different spam filters. public-inbox is my opinionated policy layer; but ssoma was intended to be generic.