Hello,

  One additional problem with this heretical idea ;) is it
doesn't scale nearly as well.  We have one db server, tuned for
storage/retrieval of data, and we have 4 seperate dbmail servers
all using it as a message store.  As we add new spam filtering
techniques, etc., which require more processing power, it's easy
to just throw a couple more machines in the group of dbmail
servers.  If we moved all that processing to the db server,
I don't think we could afford a machine with enough horsepower
to do the job.  That's definitely a huge advantage of a filesystem
message store replacement with a rdbms one (though there are certainly
others, too).

  The idea as a whole is not without merit, as some of the points
you've brought up indicate, but I think as a whole is probably
not the right approach for dbmail.  Possibly if you wanted to
write it (of course postgres-only for now) and post your db
schema/triggers/etc., you may get a small following of people
using it.  As mentioned, there has been filtering support already
patched into dbmail (both a basic filter mechanism and sieve support),
which you may find useful (search the mailing list for the patches).

My $.02....
Jesse


---- Original Message ----
From: Bill Hacker <dbmail-dev@dbmail.org>
To: dbmail-dev@dbmail.org
Subject: Re: [Dbmail-dev] adding option to support anti-spam filters
Sent: Fri, 21 Nov 2003 13:19:56 +0800

> Christian G. Warden wrote:
> 
> > On Fri, Nov 21, 2003 at 02:34:39AM +0000, Feargal Reilly wrote:
> > 
> >>Hi, I'm looking for thoughts on ways that dbmail could interact with
> >>anti-spam software?
> >>
> >>I'm scanning users' mail with SpamAssassin which adds an 'X-Spam-Flag:
> >>Yes' header to spam prior to delivering to dbmail. I want our pop3
> >>users not to have to download the mail which has been marked as spam,
> >>but to retain it so they can review it in the web interface I'm
> >>writing. (Anybody else out there use neowebscript? Didn't think so...)
> >>
> >>My plan is to adjust dbmail-smtp to scan the header for the
> >>X-Spam-Flag, and if found, store the message in a 'Spam' mailbox. Then
> >>I'll alter dbmail-pop3d not to include mail from the Spam mailbox.
> >>
> >>I'll also adjust dbmail-maintenance so that it sends a summary of the
> >>spam mailbox.
> > 
> > 
> > I think you're going about this the wrong way.  If you want to
> > quarantine spam (as opposed to rejecting it at SMTP, which I'd
> > recommend), have your MTA deliver deliver it to a different dbmail
mail
> > box, e.g.
> > if spam
> >     deliver to dbmail-smtp -m spam -u $user
> > else 
> >     deliver to dbmail-smtp -u $user
> > 
> > No modification to dbmail needed, just a minor configuration change to
> > your MTA.  
> > 
> > xn
> 
> That is a whole lot easier to implement that the approach I just posted.
> But may have to be re-implemented as the external MTA or toolsets
change..
> 
>   - It also tends to leave us with a system where all we have really 
> done is replace Maildirs or Mboxes with an RDBMS for message and 
> configuration storage.
> 
>   i.e raw or structured file sytem storage vs RDBMS for storage doesn't 
> really maximize the available RDBMS tools...
> 
> ..and we are still utilizing conventional queues, pipelines, *whatever* 
> of the legacy MTA world, with attendent delays in the I/O.
> 
> Why not simply get the messages straight into the DB, then apply the 
> filtering as a separate process before flagging the message as 
> 'available' to the POP or IMAP client?
> 
> 
> Bill Hacker..
> 
> 
> 
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> 
-- End Original Message --


--
Jesse Norell
jesse (at) kci.net


Reply via email to