>In any case, this rule is blocking 50% of my connections now.
What DNSBLs are you using? I spotchecked a few of the hosts you
showed in your blog entry, and they're all in the CBL or PBL.
The CBL lists vast numbers of zombies, with essentially no false
positives. (It watches mail to large spam
>1. the greylisting plugin uses a lock on the dbm file to prevent the
>processes from clobbering each other. the GL plugin could be
>re-written to use an RDBMS instead, that might help.
I have a well-known greylist patch for qmail-smtpd that I recently
ported over to qpsmtpd.
It uses UDP queries
>> It uses UDP queries to a small server written in perl, which has
>> rather nice performance since the perl server keeps the greylist data
>> in an in-memory hash, UDP is pretty cheap, so the server just handles
>> the requests as they arrive, no locking needed. It also means that if
>> you have
>Isn't it mostly a matter of poor naming ?
Only partly, a lot is you need ...
>The plan is, eventually, to have proper APIs and plugin hooks for
>some of the things notes are used for now (whitelists, user
>information, ).
Yeah. For example, I have several plugins that check something e
>Been having some issues where a connection would be killed by DENY or
>DENYSOFT in the rcpto stage and yet qpsmtpd would allow the sender to
>continue issuing commands and still accept the email.
If you want to kill the connection, shouldn't you be using
DENY_DISCONNECT or DENYSOFT_DISCONNECT?
I
>> When I did a top command, it was all perl qpsmtpd processes running. Any
>> idea what the problem is?
>
>None without some profiling. But a couple of random things to check - any
>chance you have UTF-8 settings in your environment? What version of perl
>are you on?
Here's the version of per