On Tue, Jan 29, 2008 at 03:49:10PM +, Mark Rogers wrote:
> Alex Tomlins wrote:
>> By database I was thinking whatever database backend dspam was using
>> (hash, mysql, postgres etc.), not specifically a RDBMS. While
>> implementing this it would make sense to put the user logs in there as
>
Forgot to copy the list See below.
Alex Tomlins wrote:
Mark Rogers wrote:
Alex Tomlins wrote:
By database I was thinking whatever database backend dspam was using
(hash, mysql, postgres etc.), not specifically a RDBMS. While
implementing this it would make sense to put the user logs i
Alex Tomlins wrote:
By database I was thinking whatever database backend dspam was using
(hash, mysql, postgres etc.), not specifically a RDBMS. While
implementing this it would make sense to put the user logs in there as
well. The advantage to doing this is that all the data for dspam
would
Mark Rogers wrote:
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 u
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 de
Bolla Péter wrote:
PS: *well, if you backup dspam spool. You should, imho.
One of the problems with spam is that it can create a massive system
overhead that causes other problems. I would be concerned about the
scalability of backing up the quarantine spool in the event that a
massive spam
Bolla Péter wrote:
Also I would oppose any server specific solution, IMAP is a quite well
followed standard, afaik.
Absolutely agreed on that one.
(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.)
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
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: [
Hey,
Kenneth Marshall wrote:
[...]
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 ide
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 consumi
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 som
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 IMA
Bolla Péter wrote:
Why to bother writing mail storage system, while it has been already
done by others, and maintained well in several real good IMAP servers,
and IMAP client libraries (libs both for perl and php)? I think
many-many hours of development AND maintenance time could be spared if
Hey,
Everything sounds pretty good but another thing to consider might be
modifying the existing dspam code to store messages in Maildir, instead
of mbox? Or to store the entire quarantine (and the other WebUI files)
inside of the database.
Why to bother writing mail storage system, while i
Kyle Johnson wrote:
Sweet! It's good to see someone finally doing this. Foxdie in the
#dspam channel has been working on a PHP conversion as well, but there
has not been any progress as of late. You might want to send him a line.
You got a name for him? Foxdie means nothing to me, sorry!
I
Mark Rogers wrote:
I've started writing a PHP alternative to the existing dspamCC web
interface. My primary objectives are to fix some things that annoy me
personally about the existing one (the very slow loading/processing of
large quarantine boxes, and the inability to sort/filter on history
pa
Mark Rogers wrote:
I've started writing a PHP alternative to the existing dspamCC web
interface. My primary objectives are to fix some things that annoy me
personally about the existing one (the very slow loading/processing of
large quarantine boxes, and the inability to sort/filter on history
pa
I've started writing a PHP alternative to the existing dspamCC web
interface. My primary objectives are to fix some things that annoy me
personally about the existing one (the very slow loading/processing of
large quarantine boxes, and the inability to sort/filter on history
page, being the main o
19 matches
Mail list logo