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