> We have been using greylistd for six months now and it works fairly well
> except for two issues. You must keep the triplets and states file
> cleared out when it hits a few MB or greylistd consumes large amounts
> of cpu and stops working. Second we have several inbound MX servers and
> greylistd doesn't have a common DB so each server may or may not
> greylist mail. This adds delays.
These are the two reasons why we use "postgrey" as greylist daemon. Much
more robust for large installations than greylistd and it is easy to run
a central instance of postgrey which could be asked via TCP.
Although postgrey is designed for postfix we use it with exim. There exists
a README.exim file in the postgrey source which gives the idea how to do
this. The ACL entry for ${readsocket{inet:greylistserver:port} ... is a bit
longish because the postfix communication protocol is verbose but it is
flexible and works very well on highly loaded mail servers with one
centralized greylist server. Together with a 3 seconds timeout in the
readsocket invocation things running smoothly even if postgrey daemon is
not running or answering which might be the case during internal database
cleanup. Until now the daemon did not crached or stoped working.
postgrey uses Berkeley DB as database which I really prefer over an
additional daemon for the database. As a little drawback postgrey has to
do cleanups which are integrated into the daemon and the daemon does not
answer in this (more or less) short period. Our postgrey daemon has
a database of 3,500,000 entries to handle and 350,000 auto-whitelisted
clients. Auto-whitelisting and handling of the subnet masks are also
advantages of postgrey.
Although I do have some wishes and ideas how it could be improved, I really
recommend to have a look at postgrey. It works with Exim too, of course.
Heiko
Heiko Schlichting | Freie Universität Berlin
heiko@??? | Zentraleinrichtung für Datenverarbeitung (ZEDAT)
Telefon +49 30 838-54327 | Fabeckstraße 32
Telefax +49 30 838454327 | 14195 Berlin
