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.
And you can already do that in a way. If you set dspam to tag messages
rather than quarantine them, you can then just have a filter in your
mail server that then puts all tagged messages into a specific folder as
opposed to the inbox.
thanks,
Alex
Jani Partanen wrote:
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!
--
Alex Tomlins
Email/Jabber: [EMAIL PROTECTED]
There are two kinds of people in the world: those who finish what they started.
