Qmail-LDAP
[Top] [All Lists]

Re: Qmail-ldap greylist support

To: qmail-ldap@qmail-ldap.org
Subject: Re: Qmail-ldap greylist support
From: Toni Mueller <support@oeko.net>
Date: Sat, 23 Dec 2006 13:06:25 +0100
Delivered-to: sp-com-lists@consult.net
Delivered-to: qmail-ldap-list@securepoint.com
Delivered-to: mailing list qmail-ldap@qmail-ldap.org
In-reply-to: <458CA815.3090109@ticom.com>
Mailing-list: contact qmail-ldap-help@qmail-ldap.org; run by ezmlm
References: <7f05badc0612120332x43839fa1sec510257a21c26f5@mail.gmail.com> <457EBEAA.8080500@ticom.com> <20061222111838.12043.qmail@oak.oeko.net> <458CA815.3090109@ticom.com>
User-agent: Mutt/1.5.4i
Hi Mark,

On Fri, 22.12.2006 at 21:52:53 -0600, Mark Farver <mfarver@ticom.com> wrote:
> TLS is supported by qpsmtpd, as is virus scanning and a host of other 
> features.  Probably anything you might want is available or trivial to 
> write yourself. 

I've already started to look into it, and yes, TLS support was even
advertised on the front page (I only didn't look at it before posting -
my bad!).

> I don't have an accurate feedback on how much time SA is spending per 
> message, (anyone know an easy way to make SA print this in the logs, or 
> can you point me to where it is located)  but 15 seconds of CPU time 

Example (slightly obfuscated):

Received: from djbt@ozomatic.com by hostname by uid 201 with qmail-scanner-x.xx 
(spamassassin: x.xx.   Clear:RC:0(67.77.86.232):SA:0(2.4/5.0):.  Processed in 
2.478731 secs); 23 Dec 2006 05:26:40 -0000


This is not from the host I talked about earlier, but it says:

"Processed in 2.478731 secs" which I (mis-?) interpreted as being
roughly 2.5 CPU seconds.

> I would look at a few things:  Turn off Bayes filtering.  Or at least 
> the auto-learning feature.

Bayes is already off, mainly because of the poisoning problem and the
inherently nondeterministic results.

> It works great if you are willing to keep training it, but it gets
> quickly poisoned if you don't.

That would have to be done by the users. I fear that all Bayesian
filters have this problem, and I already know that I can't get the
users to train such a filter, nor hand me mail bodies that I could do
it for them with.

> many users but only one token db (which is the case when you are using 
> SA in a per server filtering roll, instead of say calling it from 
> procmail.) the db quickly gets huge and useless.

No, you can have per-user settings also in a per-server role. Look for
'-x -q' or some such. The "user" address will be determined by the
email recipient of the email. You can also look at
"--virtual-config-dir". This way I can use SA as a server and don't
need .procmail or so to have per-user settings (these mail servers are
only gateways anyway - mail gets filtered etc, but then forwared to the
"real" servers).

> The other one, and this is pretty obvious, make sure you are using 
> spamd/spamc, and make sure its working.  The processor overhead for 
> loading SA on each message can quickly overwhelm a machine. 

I'm also already doing that (who runs "spamassassin", anyway?). Btw,
the 15 seconds figure applies to a P4-2.4 GHz with sufficient disk and
memory, btw...


Thank you for your ideas, I'll probably make an experiment with
qpsmtpd as my next step.



Best,
--Toni++

<Prev in Thread] Current Thread [Next in Thread>