Toni Mueller wrote:
Hi,
I was also thinking along these lines, but wondered if/why I should not
stick with the qmail-smtpd (from qmail-ldap, of course) + qmail-scanner
combo I've been using so far. I have to test it out (or read the code),
but I think that plugging into qmail-scanner would be just as easy,
and should yield much the same result (ie, reject the message during
the SMTP session). I'd rather not miss TLS and all the other goodies,
and don't yet know if qpsmtpd supports all of these.
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.
The qpsmtpd distribution is small, and not very hard to setup. The
toughest part is pulling from CPAN the dependency on Mail::Header. By
default the forking server runs on port 2525, and hands off to
qmail-queue, so you can install it alongside your installation and
experiment.
It is hard to explain how well written the plugin interface is, you just
have to give it a try. It offers a lot more flexibility than a milter
style (pipe thru subprograms) interface. Your plugin can hook any stage
of the smtp transaction, so a lot of plugins can reject before data.
(Greylisting can reject as early as connect, if you want)
Please look at the message header lines or your protocol. I'm very
interested in the performance figures for your SpamAssassin. On servers
I tend, I see regularly about 15 CPU seconds burned _per_message_,
which I find way to high. OTOH I'm unaware of alternatives that have
comparable filtering abilities.
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
seems excessively high. Running SA by hand I occasionally see 15
seconds to analyze a message, but most of that time is spent idling for
DNS responses from various BL queries.
I would look at a few things: Turn off Bayes filtering. Or at least
the auto-learning feature. It works great if you are willing to keep
training it, but it gets quickly poisoned if you don't. If you have
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.
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.
Mark Farver
|