Description^

A greylist implementation for decency.

Greylisting is a technique mail servers use to assure the other side is a real mail server and not a small bot script. In a live-environment a server might experience a huge load on occasion. In this case, it is allowed to reply to the overwhelming flood of incoming mails with a “temporary not available”  – the 4xx code. The sending mail server should now queue the message and try again later.

This behavior is absolutely common and should be implemented in any software calling them self a mail server. The greylisting server takes advantage of this and sends an “not right now” 4xx code to any first deliver attempt from a server he has not seen before. On the second, third and all future attempts he will accept the incoming mails.

Many spam bots won’t, cause they are simple SMTP scripts, rather then real mail servers with a mail queue. They simply try, fail, forget.

Critics^

Most people assume mails to be an instant communication. Normally this is observed to be correct. So, if you use greylisting (as a server admin) they might feel somewhat irritated. However, it is an absolutely valid measurement from the SMTP protocol point of view. Further more, the “bad effect” will pass over time, because when most of your contacts are on the grey list they will be delivered instantly (again).

Usage suggestion^

Should be used somewhere at the end of your policies.

Configuration^

min_interval^

Allowed values: integer seconds

Minimal interval the other mail server has to wait until he can re-send again. The standard retry interval for postfix would be 30 minutes, so 10 minutes (600 sec) sounds good.

pass_code^

Allowed values: DUNNO, OK

As long as the sender is not on the greylist (first contact), the mail is rejected with a temporary error. When the sender is on the greylist this module can either do nothing (and let the other modules do their work) or assume this being on the greylist is sufficient and pass the sender finally. Be careful setting this to OK!

scoring_aware^

If this is enabled, the host_policy and domain_policy databases will only allow mails which are not negatively scored. Enable this is you have scoring able modules before (eg SPF or blacklists) and want you policy databases to be clean. This will reduce the amount of false-positives in the policy databases a lot.

Example^

---

disable: 0

# interval in seconds until a sender is allowed to re-send
#   and pass
min_interval: 600

# per default, the greylist does not work as a whitelist, but
#   a blacklist. it will reject (temporary) any mail not on the
#   list, but does not explicit allow mails which are on the list
#   to be passed (DUNNO).. you can enable passing by setting this
#   to OK, thus any mail is on the list will pass.
#   check with your restriction-classes to determine the better
#   behavior for your mail server
pass_code: DUNNO

# scoring aware. will put mails only on the permanent whitelist
#   (host or domain) if it has been scored zero or above
#   this should keep suspicious mails from the whitelist
scoring_aware: 1

# policy for permanently whitelisting a whole sender server
hosts_policy:

    # threshold of different sender mails
    unique_sender: 5

    # threshold of mails received from ONE address finally
    #   putting the host on the whitelist
    one_address: 10

# policy for permanently whitelisting a whole sender domain
#   use this with care and SPF (beforehand!)
domains_policy:

    # threshold of different sender mails
    unique_sender: 5

    # threshold of mails received from ONE address finally
    #   putting the host on the whitelist
    one_address: 10

Database

SQL Example created from ‘–print-sql’

-- TABLE: greylist_sender_recipient (SQLITE):
CREATE TABLE GREYLIST_SENDER_RECIPIENT (sender_address varchar(255), max_unique integer, unique_sender blob, last_seen integer, counter integer, max_one integer, recipient_address varchar(255), id INTEGER PRIMARY KEY);

CREATE UNIQUE INDEX GREYLIST_SENDER_RECIPIENT_SENDER_ADDRESS_RECIPIENT_ADDRESS ON GREYLIST_SENDER_RECIPIENT (sender_address, recipient_address);

-- TABLE: greylist_sender_domain (SQLITE):
CREATE TABLE GREYLIST_SENDER_DOMAIN (max_unique integer, unique_sender blob, sender_domain varchar(255), last_seen integer, counter integer, max_one integer, id INTEGER PRIMARY KEY);

CREATE UNIQUE INDEX GREYLIST_SENDER_DOMAIN_SENDER_DOMAIN ON GREYLIST_SENDER_DOMAIN (sender_domain);

-- TABLE: greylist_client_address (SQLITE):
CREATE TABLE GREYLIST_CLIENT_ADDRESS (last_seen integer, counter integer, client_address varchar(39), id INTEGER PRIMARY KEY);

CREATE UNIQUE INDEX GREYLIST_CLIENT_ADDRESS_CLIENT_ADDRESS ON GREYLIST_CLIENT_ADDRESS (client_address);

Performance^

Runtime: average 0.02 secs