I've rewritten the greylisting plugin to use DBI info passed in the the config. My reasons for moving to a server was to make the state available to the peered systems universally, not so much for performance. Maybe I got lucky. I haven't re-documented the plugin to accommodate the change nor have I accommodated the ability to use something other than MySQL.
Also missing from the plugin documentation is the schema: -- -- Table structure for table `greylisting` -- DROP TABLE IF EXISTS `greylisting`; CREATE TABLE `greylisting` ( `remote_ip` varchar(16) NOT NULL, `sender` varchar(60) NOT NULL, `recipient` varchar(60) NOT NULL, `ts` int(11) NOT NULL, `new` int(11) NOT NULL, `black` int(11) NOT NULL, `white` int(11) NOT NULL, KEY `greylisting01` (`remote_ip`,`sender`,`recipient`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1; It's currently sitting at http://peter.boku.net/greylisting.sql YMMV, peter On 8/16/07 8:44 AM, "m. allan noah" <[EMAIL PROTECTED]> wrote: > three things spring to mind- > > 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. > > 2. the greylist db might be huge, i wrote a little script that prunes > the ancient entries from my version. > > 3. how slow is klez? > > try turning GL or klez off for a minute and see if things improve. > > allan > > On 8/16/07, Geoff Shang <[EMAIL PROTECTED]> wrote: >> Hello, >> >> I realise it's poor form to jump on a mailing list and immediately ask for >> help, so I hope you will be forgiving. >> >> I administer a system for a US non-profit organisation. The previous admin >> chose to use Qmail and then QPSMTPD to allow the system to do greylisting. >> >> We are experiencing two problems, one of which may or may not be related to >> QPSMTPD (one certainly is). >> >> We process quite a lot of mail, but as far as I can see we are only really >> doing greylisting and not much else. Yet we are seeing system load of >> between 5 and 7 constantly, with QPSMTPD processes using over 20% CPU. >> >> Note that it used to be a lot higher and we used to get long delays in >> message processing. I switched us to qpsmtpd-forkserver which got our >> processing times down to something acceptable and our system loads down to >> about 6, but we still think it's higher than it should be. >> >> Also, sometimes we have situations where mail seems to get stuck, as if some >> external entity on which the process is relying has become temporarily >> unavailable. The message queue (that output by "qmail-qstat"), which >> normally hovers at about 130, can go up as high as 2000 when this happens. >> But these situations have resolved themselves without any intervention from >> me. >> >> My questions are these: >> >> 1. Does anyone have any idea why our system load is running so high? >> >> and >> >> 2. Which version of qpsmtpd should I be running? There seems to be 4 >> different server programs now and I don't really appreciate the difference >> between the various programs. >> >> We are running QPSMTPD 0.40 under Debian 3.0 (Woody - yes it's old). Perl >> is version 5.6.1. >> >> I am executing the forkserver with the following command: >> >> exec ./qpsmtpd-forkserver --listen-address `head -1 config/IP` --port 25 \ >> --limit-connections 30 --user smtpd 2>&1 >> >> The following plugins are being loaded (in this order): >> >> hosts_allow >> dont_require_anglebrackets >> check_earlytalker >> count_unrecognized_commands 4 >> check_relay >> greylisting black_timeout 600 >> require_resolvable_fromhost >> rcpt_ok >> >> virus/klez_filter >> >> queue/qmail-queue >> >> I know relatively little about Email processing, and very little about >> QPSMTPD. Any assistance anyone could give would be very much appreciated. >> >> BTW: When upgrading from 0.31, I discovered that 0.40 seems to depend on >> net/ip.pm which the ReadMe does not mention as a dependency. Woody did not >> have this module packaged, but Sarge had it and it installed with no >> problems. >> >> Geoff. >> >> >
