On Thu, 2007-06-07 at 22:09 -0400, Tom Allison wrote: > On Jun 7, 2007, at 6:41 PM, Michael Monnerie wrote: > > > On Donnerstag, 7. Juni 2007 Tom Allison wrote: > >> If you want to make dbmail capable of doing spam filtering... > >> wouldn't it make more sense to simply pipe the spam filtering in > >> front of the dbmail interface like procmail does today? I'm stuck on > >> this one. I don't know where there is much advantage here. > > > > It should never *do* spam filtering, but *support* it. The idea is > > this: > > - there are distributed checksums like DCC, pyzor, razor > > This makes sense, but how do you want to support it? > > I think a lot of this falls under the responsibility of sieve if it's > to do anything prior to delivery. > After delivery, well you could troll through unread emails using IMAP > and move them to different folders accordingly. > > I would think you could do a nice job filtering spam if you had an > LMTP based application that would just pipe the email from the MTA > (postfix) through it to your MDA (dbmail) and let sieve do the final > disposition (delete/directory). But this isn't really a dbmail > extension. More of a sieve extension if anything.
All of this can be already with existing tools in exactly the configuration that you are suggesting, without any extensions to anything. Sieve header tests work with most X-Spam-Whatever headers. Aaron _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
