Database quarantine is something I really would like to see.
 

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Kenneth Marshall
> Sent: Tuesday, January 29, 2008 4:36 PM
> To: Bolla P?ter
> Cc: dspam-dev@lists.nuclearelephant.com
> Subject: Re: [dspam-dev] PHP UI alternative to dspamCC
> 
> One of the advantages of the current DSPAM quarantine is that 
> the ham/spam messages are not delivered to the production 
> mail system unless released by the user. Our IMAP system 
> keeps any message for 8 days, before it is removed and if 
> quarantine messages were stored there, they would end up 
> consuming disk resources and backup resources far longer than 
> the current setup. I guess that one idea would be to have a 
> separate IMAP server for the DSPAM UI.
> 
> Regarding the performance of the UI. The activity plots are 
> nice, but they parse the entire logfile each time they are 
> built. It would be nice to cache just the information for the 
> display for historical data to avoid the need to re-read the 
> logfile over and over. This would allow us to keep the daily 
> activity for a longer period without impacting the display 
> update time.
> 
> Some ideas.
> Ken
> 
> On Tue, Jan 29, 2008 at 08:29:11AM -0600, Bolla P?ter wrote:
> > Well, in my idea DSPAM would have been converted to use IMAP too, 
> > instead of directly manipulating an mbox.
> >
> > Regarding imap server, I would not recommend anythig, as I 
> only know 
> > cyrus, what I use. But I think that in the majority of dspam setups 
> > there is an imap server already in the system somewhere, so 
> that would 
> > be not much of a performance/maintenance issue. Also I would oppose 
> > any server specific solution, IMAP is a quite well followed 
> standard, 
> > afaik. (So both read and write the mails throug IMAP, without any 
> > direct file access. Some IMAP servers don't even let you access the 
> > files directly.)
> >
> > Peter
> >
> > Mark Rogers wrote:
> >> Mark Rogers wrote:
> >>> Of-course mbox -> IMAP scripts probably exist, so I could 
> still look 
> >>> at this option now.
> >> Now that my brain has started...
> >> Of-course I don't need to parse the mbox file and pass the 
> mails to 
> >> an IMAP server, I just need to convert them to Maildir 
> format and let 
> >> a normal IMAP server pick them up from there. Which makes 
> things far 
> >> simpler!
> >> Doh!
> >
> 
> 

Reply via email to