Clamdmail

Version 0.19

October 5, 2006

Clamd-Greylist is a PostgreSQL implementation of a greylist interface for clamd-queue. Clamd-greylist does not enforce any greylist policy, but rather expects your database or other programs to enforce such policies as described below.

Logging Environmental Variables

LOGLEVEL

This variable determines the amount of data that both clamd-queue and clamd-greylist spit out on stderr during processing. The default value is 1, which logs only errors. Values of 2 and 3 produce other useful information, including the results of greylisting and scanning operations. Values above 4 print runtime configuration information and a value of 8 prints all debugging messages.

Configuration Files

/var/qmail/control/greylist-db

This file is read to obtain the connection string required to connect to the greylist database. This string is passed unaltered to PQconnectdb(). lease see the PostgreSQL API documentation for a list of parameters, or try this example:
host=sql.domain.com dbname=greylist_db user=username password=password sslmode=require

Requried Database Schema

The databased used by clamd-greylist must contain two tables:

	whitelist_table {
		ts	timestamp
		host	varchar(39)
	}
	greylist_table {
		ts	timestamp
		host	varchar(39)
		addr	bytea
	}

And two views:

	whitelist_view {
		host	(from whitelist_table host)
	}
	greylist_view {
		host	(from greylist_table host)
		addr	(from greylist_table addr)
	}

In the simplest case, the views can be defined as:
SELECT host FROM whitelist_table;
and:
SELECT host, addr FROM greylist_table;
Though your greylist policy likely dictates a more complex select statement.

Greylist Policies

There are three basic greylist policy decisions:

1. How much time must pass before I accept delivery of messages that have been greylisted and whitelist the sending host?
2. How much time can pass before I stop waiting for a message to be resent?
3. How long should I remember whitelisted hosts?

While you're welcome to make whatever policy decisions you like, I recommend:

1. That you require hosts to delay at least 5 minutes between a greylisted delivery attempt and whitelisting.
2. That you require hosts to retry delivery withing 12 hours of being greylisted.
3. That you remember whitelisted hosts for no more than a year.

Given the 1st policy above, I would write my view select statements as:
SELECT host FROM whitelist_table;
and:
SELECT host, addr FROM greylist_table WHERE ts < now()-'5 minutes'::interval;
So that messages that have been greylisted in the past 5 minutes are not shown in greylist_view.

To enforce the 2nd and 3rd policies I would create daily cron jobs that run the following SQL statements:
DELETE FROM whitelist_table WHERE ts < now()-'1 year'::interval;
DELETE FROM greylist_table WHERE ts < now()-'12 hours'::interval;
These policies could also be enforced directly with the view, but deleting old entires will keep the database from growing too large, and will help keep the view select statements speedy.