Greylisting is a spam-fighting technique that works by informing the sending mail server that a temporary error has occurred and that it must try delivery again at a future time. The theory is that, by and large, spam tools don't retry delivery, but legitimate mail servers do. Using this technique, when a message arrives from a non-allowlisted or otherwise previously unknown sender, its sender, recipient, and sending server's IP address will be logged and then the message will be refused with a temporary error during the SMTP session. Furthermore, for a designated number of minutes any future delivery attempts will also be temporarily refused. Because spammers do not typically make further delivery attempts when a message is refused, greylisting can help to reduce the amount of spam your users receive. But, even if the spammers should attempt to retry delivery at a later time, it is possible that by that time the spammers will have been identified and other spam-fighting options (such as DNS Blocklisting) will successfully block them.
In spite of greylisting's ability to reduce spam, it is important to note that it can also delay legitimate and even important messages while doing so. But, the legitimate messages should still be delivered sometime later after the greylisting period has expired, and no further delays will be implemented against that same server/sender/recipient combination again, unless the sender fails to send another message to that recipient for a designated number of days. It is also important to note that when a message is delayed you have no way of knowing how long the sending servers will wait before making further delivery attempts. It is possible that purposely refusing a message with a temporary error code could cause it to be delayed by as little as just a few minutes or by as much as an entire day. Because of this and other potential problems associated with greylisting, the feature is disabled by default in SecurityGateway. There are, however, a number of options designed to deal with the potential problems.
First, some sending domains use a pool of mail servers to send outbound mail. Since a different mail server could be used for each delivery attempt, each attempt would be treated as a new connection to the greylisting engine. This could multiply the length of time it would take to get past Greylisting because each of those attempts would be greylisted as if they were separate messages instead of retries of a previous message. By utilizing a Sender Policy Framework (SPF) lookup option, this problem can be solved for sending domains who publish their SPF data. Furthermore, there is an option to ignore the IP of the sending mail server completely. Using this option lowers the efficiency of greylisting but does solve the server pool problem.
Next, greylisting traditionally entails a large database since each incoming connection must be tracked. SecurityGateway minimizes the need to track connections by placing Greylisting later in the SMTP processing sequence. This allows many of SecurityGateway's other options to refuse a message prior to reaching the greylisting stage. As a result, the size of the greylisting database is greatly reduced and causes little practical performance impact.
Finally, several options are available to minimize the impact of greylisting on legitimate messages, such as options to exclude messages from greylisting when they are from allowlisted senders or are arriving over authenticated sessions, and messages coming from one of your domain mail servers are always exempt.
For more information on greylisting, visit:
http://en.wikipedia.org/wiki/Greylisting
Configuration
Enable greylisting
Click this option to enable the Greylisting feature. Greylisting is disabled by default.
Defer initial delivery attempt with temporary error for [xx] minutes
Use this option to designate the number of minutes that each server/sender/recipient combination (i.e. "triplet") will be greylisted after the initial delivery attempt. During that time any subsequent delivery attempts by the same triplet will be refused with a temporary error code. After the designated number of minutes has elapsed, no further greylisting delays will be implemented on that triplet unless its greylisting database record expires. The default value for this option is 15 minutes.
Expire unused greylisting database records after [xx] days
Once a greylisted triplet has passed the initial greylisting period, no further delivery delays will be implemented against it unless no further messages matching that triple record are sent for this number of days. For example, if this value is set to 10 days, then as long as at least one message matching that same server/sender/recipient combination is received every 10 days then there will be no delays. If, however, no message is sent in that time then the record will expire and that triplet will have to go through another greylisting period before it can again be exempt from further delays. The default time that a record must be unused before it expires is 10 days.
Ignore IP address when greylisting (use only MAIL & RCPT values)
Click this check box if do not wish to use the sending server's IP address as one of the greylisting parameters. This will solve the potential problem that can be caused by server pools, but it will reduce Greylisting's efficiency. This option is disabled by default.
Ignore IP address for connections that pass SPF processing
When using this option, only the sender and recipient will be used for greylisting when the sending server passes SPF processing; the IP address will be ignored. This option is enabled by default.
Exclusions
Exclude messages from allowlisted senders
Messages from allowlisted senders are excluded from greylisting by default—delivery of these messages will not be delayed. Clear this checkbox if you do not wish to exclude allowlisted senders from greylisting.
Exclude messages from authenticated sessions
By default messages arriving over authenticated sessions are exempt from greylisting. Clear this checkbox if you do not wish to exclude messages from greylisting when the session is authenticated.
Exclude messages from domain mail servers
Messages coming from your domain mail servers are always excluded from greylisting.
Exceptions - Domains
If you select a specific domain in the "For Domain:" drop-down list box at the top of the page when configuring these settings, that domain will be listed here after saving the settings. Click the View/Edit link for the corresponding domain to review or edit its Greylisting settings, or click Reset to reset the domain's settings to the default Global values.
