You could use an archive in the style of simcontrol, creating options as:
[EMAIL PROTECTED]: rdns=yes, graylist=no, chk_mx=no…
: rdns=y, graylist=yes, chk_mx=yes…
I believe that this can decide the problem.
2007/9/19, Sam Clippinger <[EMAIL PROTECTED]>:
> If you put an IP address in the never-
I've considered something like that. Unfortunately, it's very
inefficient. On my system, where I have less than 100 users, I could
easily create one file for all my users and suffer no performance
issues. However, on a system with thousands or tens of thousands of
users, the file will become
The disk access is very slow in compared with memory (ram) access.
In the file of options per user, there is only users with specific
options, the default option is only 1 line where the admin can
manipulate default actions.
I'm not programmer, but believe to look for lines in file with 1
line
What about interfacing with sqlite, an embedded relational database.
That should give you the performance and flexibility you would require.
-John
Sam Clippinger wrote:
> I've considered something like that. Unfortunately, it's very
> inefficient. On my system, where I have less than 100 users,
I agree, memory access is much faster than disk access. However,
remember how spamdyke runs. There is no spamdyke daemon to load the
configuration file once, parse it once and use it multiple times.
Instead, a new instance of spamdyke is started for every incoming SMTP
connection. That means
You are correct.
tks.
2007/9/20, Sam Clippinger <[EMAIL PROTECTED]>:
> I agree, memory access is much faster than disk access. However,
> remember how spamdyke runs. There is no spamdyke daemon to load the
> configuration file once, parse it once and use it multiple times.
> Instead, a new inst
That's a good idea and it's one I've heard before. MySQL and CDB files
have also been suggested. I have several concerns about all of them:
1) Speed. Because spamdyke doesn't run as a daemon, a database
engine must be loaded and initialized for every incoming connection.
That takes time, s
On 9/20/2007 [EMAIL PROTECTED] wrote:
> The disk access is very slow in compared with memory (ram) access.
>
> In the file of options per user, there is only users with specific
> options, the default option is only 1 line where the admin can
> manipulate default actions.
> I'm not programmer
Unfortunately that's not really possible here because spamdyke is not a
daemon -- a new copy of spamdyke is started (by tcpserver or xinetd) for
each incoming connection. When each new copy is started, it must start
from scratch to read and parse its configuration.
I'd like to change that in a
I use Plesk and QMAIL. Plesk's qmail has an SMTP AUTH.
But i can't run spamdyke with auth.
/var/qmail/bin/passwordcheck -u mailaddress <[EMAIL PROTECTED]> -p password
/var/qmail/bin/smtp_auth /var/qmail/bin/true
Beginning unencrypted password test.
Sending data to child process:
mailaddress\0pas
With the latest version of spamdyke, the "smtp-auth-command" flag is
unnecessary. If qmail already provides SMTP AUTH, spamdyke will honor
the authentications automatically.
Try these starting arguments:
-Rt0 /usr/local/bin/spamdyke -x dnsbl-1.uceprotect.net -x
dnsbl-2.uceprotect.net -
I thought about using only one daemon that he would function as a
porter of configurations, keeping tcpserver. The processes of spamdyke
would have to consult this daemon and would receive the answers from
it.
2007/9/20, Sam Clippinger <[EMAIL PROTECTED]>:
> Unfortunately that's not really
12 matches
Mail list logo
