Plugin to implement the 'greylisting' algorithm proposed by Evan Harris in Greylisting is a form of denysoft filter, where unrecognised new connections are temporarily denied for some initial period, to foil spammers using fire-and-forget spamware, http_proxies, etc.

Greylisting adds two main features: it tracks incoming connections using a triplet of remote IP address, sender, and recipient, rather than just using the remote IP; and it uses a set of timeout periods (black/grey/white) to control whether connections are allowed, instead of using connection counts or rates.

This plugin allows connection tracking on any or all of IP address, sender, and recipient (but uses IP address only, by default), with configurable greylist timeout periods. A simple dbm database is used for tracking connections, and relayclients are always allowed through. The plugin supports whitelisting using the whitelist_soft plugin (optional).


The following parameters can be passed to denysoft_greylist:

remote_ip <bool>
Whether to include the remote ip address in tracking connections. Default: 1.
sender <bool>
Whether to include the sender in tracking connections. Default: 0.
recipient <bool>
Whether to include the recipient in tracking connections. Default: 0.
deny_late <bool>
Whether to defer denials during the 'mail' hook until 'data_post' e.g. to allow per-recipient logging. Default: 0.
black_timeout <timeout_seconds>
The initial period, in seconds, for which we issue DENYSOFTs for connections from an unknown (or timed out) IP address and/or sender and/or recipient (a 'connection triplet'). Default: 50 minutes.
grey_timeout <timeout_seconds>
The subsequent 'grey' period, after the initial black blocking period, when we will accept a delivery from a formerly-unknown connection triplet. If a new connection is received during this time, we will record a successful delivery against this IP address, which whitelists it for future deliveries (see following). Default: 3 hours 20 minutes.
white_timeout <timeout_seconds>
The period after which a known connection triplet will be considered stale, and we will issue DENYSOFTs again. New deliveries reset the timestamp on the address and renew this timeout. Default: 36 days.
testonly <bool>
Testing flag - if this is set we log and track connections as normal, but never actually issue DENYSOFTs. Useful for seeding the database and testing without actually impacting deliveries. Default: 0.
per_recipient <bool>
Per recipient flag - if this is set, the plugin is only run for recipients which have recipient_option 'denysoft_greylist' set. This can be set by the aliases plugin. Default: 0.


Database locking is implemented using flock, which may not work on network filesystems e.g. NFS. If this is a problem, you may want to use something like File::NFSLock instead.


Written by Gavin Carr <>. This version was modified by Peter J. Holzer <>. All bugs are probably Peter's fault, the good stuff is from Gavin :-).