Mark Rogers wrote:
Jason Axley wrote:
One basic feature I'd like to see is the ability to map user logins
(e.g. from LDAP) to one or more identities that dspam knows about.
How would you like this to work? Personally I'd like access from one
login, but to still have the quarantines separate
Steve wrote:
Original-Nachricht
Datum: Fri, 08 Feb 2008 09:47:12 +
Von: Mark Rogers <[EMAIL PROTECTED]>
An: dspam-dev@lists.nuclearelephant.com
Betreff: Re: [dspam-dev] PHP UI alternative to dspamCC
Steve wrote:
It depends how you retrain. If yo
Original-Nachricht
> Datum: Fri, 08 Feb 2008 09:47:12 +
> Von: Mark Rogers <[EMAIL PROTECTED]>
> An: dspam-dev@lists.nuclearelephant.com
> Betreff: Re: [dspam-dev] PHP UI alternative to dspamCC
> Steve wrote:
> > It depends how you retrain. If
Steve wrote:
It depends how you retrain. If you have the tokens already inside the storage
engine and linked to a signature, then retraining with just the signature is
enough. If you don't store the tokens with a signature inside the storage
engine or you purged the signature including the tok
Original-Nachricht
> Datum: Thu, 07 Feb 2008 08:54:12 +
> Von: Mark Rogers <[EMAIL PROTECTED]>
> An: dspam-dev@lists.nuclearelephant.com
> CC: Jason Axley <[EMAIL PROTECTED]>
> Betreff: Re: [dspam-dev] PHP UI alternative to dspamCC
> Jason Axle
Jason Axley wrote:
One basic feature I'd like to see is the ability to map user logins
(e.g. from LDAP) to one or more identities that dspam knows about.
How would you like this to work? Personally I'd like access from one
login, but to still have the quarantines separate (eg separate IMAP
One basic feature I'd like to see is the ability to map user logins
(e.g. from LDAP) to one or more identities that dspam knows about. The
current CGI UI assumes that your login == your dspam user ID, which is
not the case. e.g. I have a single mail server serving multiple domains
and unless
Alex Tomlins wrote:
Ok, I had a look at doing Maildir delivery, and it can be done quite
easily without modifying the dspam code. We just need to specify a
QuarantineAgent in dspam.conf.
I've knocked together a quick perl script that will do the trick. See
attached.
you can use it by specifyin
> 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
Ok, I had a look at doing Maildir delivery, and it can be done quite
easily without modifying the dspam code. We just need to specify a
QuarantineAgent in dspam.conf.
I've knocked together a quick perl script that will do the trick. See
attached.
you can use it by specifying QuarantineAgent as b
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.)
e 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
ant.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
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
28 matches
Mail list logo