"W. Trevor King" <wk...@tremily.us> 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.
--
unsubscribe: meta+unsubscr...@public-inbox.org
archive: http://public-inbox.org/meta/
