For example in big systems you only need to store that message itself only once. It save space and resources.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Mark Rogers > Sent: Tuesday, January 29, 2008 5:22 PM > To: dspam-dev@lists.nuclearelephant.com > Subject: Re: [dspam-dev] PHP UI alternative to dspamCC > > Jani Partanen wrote: > > Database quarantine is something I really would like to see. > > For what purpose? > > I thought about this from a speed perspective (in particular > when sorting by criteria such as confidence levels). However, > simple text indexes achieves this pretty well without the > database dependency. > > Is there another benefit of moving to a database I hadn't > thought about? > As mentioned elsewhere, moving the logs to a database would > suit me a lot, so I'm looking for good excuses! > > On the basis of "picking the best tool for the job" and "not > reinventing the wheel" either a database or an IMAP server > would fit; suitability for handling email specifically might > suggest IMAP over database though, not least the fact that > (if necessary) a mail client could be configured to talk to > IMAP pretty easily, eg for sending back missed spam. > > Alex Tomlins wrote: > > I'd second that... > > > > I'm not sure about the IMAP idea. Something I like about > dspam at the > > moment is that it is a self-contained solution (that's most > of why I > > moved to it from spamassassin). If you start feeding stuff out to > > IMAP servers etc, you end up with more external dependencies. > > This seems to be a good argument against IMAP servers *AND* > database servers. > > If anything, it's more likely that a typical mail server will > have an IMAP server already present than a database. > > -- > Mark Rogers // More Solutions Ltd (Peterborough Office) // > 0845 45 89 555 Registered in England (0456 0902) at 13 Clarke > Rd, Milton Keynes, MK1 1LG > > >