Flat File Database
==================

GL_DATABASE contains the full path to the database file. The file consists of
LF-separated lines. The first line contains a version string. Subsequent lines
either start with a "#" character, indicating that the rest of the line is
available for reuse by add_entry, or they contain five fields:

1. An 8-digit hex string representing the UNIX-timestamp of the last update
   of that entry.
2. A single "+" or "-" character representing the "confirmed" flag.
3. The IP address of the sending MTA, followed by a comma (",")
4. The envelope sender email address, followed by a comma (",")
5. The envelope recipient email address

Since the entries are not ordered in any way, databases of this type become
very inefficient when they grow large. This database type can therefore not
be recommended for medium- or high-volume servers.

Also, a certain amount of fragmentation can be expected as confirmed entries
become mixed with others. The following command *can* be used as a "cleanup"
measure when qmail-smtpd is not running:

cp greylisting-db greylisting-db.old
( head -1 greylisting-db.old; \
  tail +2 greylisting-db.old | grep -v '^#' | sed 's=\([-+]\)= \1 =' | \
    sort -k 1 | sort -s -k 2,2 | sed 's= \([-+]\) =\1=' ) > greylisting-db

The "tail..." can also be used for a quick manual inspection of the database.


Status
------

This DB implementation has been used on a production mailserver of a small
company receiving less than 1000 emails per day (excluding SPAM). So far,
no significant problems have been observed. It can be considered stable.

Version 1.1 fixes a bug for systems where time_t has more than 32 bits.
The bug was detected by the test suite even in previous versions.

