Reducing SPAM

20.4.1

Greylisting

Greylisting is a technique for reducing the amount of junk email accepted by an MTA. The technique relies on the fact that a large proportion of junk email is transferred directly into the target MTA using an SMTP-aware script, rather than a ‘real’ MTA. Such scripts generally do not have any retry logic – they simply traverse a list of email addresses, making a single attempt to transfer a junk mail to each one in turn. Thus if a temporary error (i.e. “Please try again later”) is returned in response to a message transfer attempt, a lot of junk email can be blocked.

Messages which originate from MTAs rather than scripts will be retried after a (usually) short interval, at which point they can be accepted.

Tracking of whether this is the first or a subsequent attempt to transfer a message to a particular recipient is achieved by using a database to store a tuple containing the originator address, recipient address and IP address of the sending system for each recipient of a message. To guard against scripts which do retry immediately, a short (e.g. 10 seconds) timer is associated with each tuple: any retries which occur before the timer expires will be ignored.

The main danger with the use of Greylisting is that there are some real MTA

implementations in use which do not retry properly in response to temporary errors. This can mean that non-junk messages may end up being non-delivered. To guard against this it is possible to exclude specific senders, recipients or sending systems from the greylisting process. Tools are provided which allow examination and cleanup of the greylisting database.

20.4.1.1

Support in inbound channel

Greylisting is enabled by adding configuration to the SMTP inbound channel’s ininfo

entry. The keys and their values used are:

Greylist delay (greylist)

If this key has a value associated with it, this is taken to be the delay in seconds which the SMTP channel should apply before a message with a new IP

address/originator/recipient tuple is accepted. If the key is present without a value, the default delay of 10 minutes is assumed. If the key is not present at all, no use of greylisting will be made by the channel.

Greylist Database (greylistdb)

If this key is present, the associated value gives the path for the greylisting database to be used by this channel, overriding the default value. An absolute file path is interpreted as such, while a relative path is interpreted as being relative to the parent directory of (QUEDIR).

Greylist Expiry (greylist_expiry)

If this key is present it must have a value associated, which is the interval in seconds after which an entry in the greylisting database is considered to have timed out. If this key is not present, a default value of 60 * 60 * 24 * 30 (i.e. 30 days) is used. Once an entry has timed out, a subsequent message with the same IP/originator/recipient tuple will be treated as if the tuple had been seen for the first time. Expired records are also considered suitable for deletion by the "tidygreylist" program.

Whitelist address (whitelist_addr)

If this key is present, the associated value must contain a comma separated list of recipient or originator email addresses for which greylisting should not be applied.

Whitelist IP (whitelist_ip)

If this key is present, the associated value must contain a comma separated list of IP addresses for which greylisting should not be applied. A network can be specified by replacing the host part of the IP address with zero.

20.4.1.2

Support in outbound SMTP channel

Support for greylisting can also be enabled in outbound SMTP channels. In this case, successful transfer of a message causes a greylist database record to be added such that if the message recipient replies to the message originator, sending the reply message from an MTA which shares the network part of its IP address with the IP address of the system which received the original message no greylist delay will be imposed. A single

configuration key is required in the SMTP channel’s outinfo entry:

greylist

In addition, the greylist_expiry and greylistdb keys described for the inbound channel above can also be specified.

20.4.1.3

Greylist database tools

20.4.1.3.1 dumpgreylist

The dumpgreylist utility allows the contents of the greylist database to be examined. The default mode of operation is to print out every record in the database. Switches allow information for specific originators or recipients to be selected. The complete set of command line switches supported is:

-s

just print a summary instead of all the records in the database.

-d

print detailed information for each record.

-D

print very detailed information for each record.

-r <email address>

print information for specified recipient only.

-o <email address>

print information for specified originator only.

-i <IP address>

print information for specified IP address only.

-m <nn>

only print records created within last nn minutes.

-h <nn>

only print records created within last nn hours.

-t <nn>

only print records created since nn, where nn is seconds since the start of the Unix epoch.

20.4.1.3.2 tidygreylist

The tidygreylist utility deletes ’expired’ records from the database. The following switches are supported:

-s

print summary of records deleted when complete.

-v