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
> 
> 
> 

Reply via email to