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.