Greylisting is used to prevent spam from reaching mailboxes and it can have a dramatic effect on reducing spam. If you are running a mail server on ClearOS, then we recommend having greylisting enabled.
When the Greylisting app is running, an inbound mail message that is not recognized will be gently rejected. If the mail message is legitimate, the sending mail server will re-attempt subsequent deliveries and the ClearOS server will then accept it. For the most part, spammers do not bother with the second delivery attempt and this results in less spam.
If your system does not have this app available, you can install it via the Marketplace.
You can find this feature in the menu system at the following location:
You can start and stop the Greylisting service at any time.
The delay is amount of time that must pass before a subsequent delivery attempt is allowed. The 5 minute default will work for the vast majority of installations. If you would like to be more aggressive, please feel free to increase the delay time.
Data Retention Time
The Greylisting engine keeps track of both mail servers and sender e-mail addresses for a specified amount of time (default is 35 days). If messages from validated sender or server arrives, the greylisting engine will accept delivery. For example, if email@example.com sends an e-mail to one of your users on a weekly basis, only the very first mail message is delayed as long as it comes from the same sending client (see the whitlisting tip below for known problem clients/domains). All subsequent messages are delivered automatically since firstname.lastname@example.org has been validated.
How it works
The app checks incoming e-mails to see if it has already passed an e-mail from the same client_address/sender_e-mail/recipient_e-mail triplet, or if the recipient_e-mail or sender is in a whitelist and will allow the e-mail through. If it fails the check, it will send back a message to the sender saying the server is temporarily busy and please try again later. It will keep saying it is busy until the “Delay” time has passed. If the server tries again after the “Delay” time has passed, the message will be passed and the client_address/sender_e-mail/recipient_e-mail triplet will be added to the list of good combinations for the next “Data Retention Time” days so new massages from that triplet will pass immediately next time.
The theory is that spammers generally try once or twice in quick succession then don't come back. This is how the spam is blocked.
There are issues with this approach. Some senders try once and don't come back. Other senders may try from different IP addresses from a cluster of servers. There is a whitelist which contains a list of known problem servers and there is also an local whitelist which you can add to.
There is currently no way of whitelisting e-mail through the webconfig in the Greylisting app, but you can manually edit /etc/postfix/postgrey_whitelist_clients.local. Then restart the Greylisting app. You can whitelist by sending domain, IP or subnet or a regex describing them (see /etc/postfix/postgrey_whitelist_clients for examples). You can whitelist recipients in /etc/postfix/postgrey_whitelist_recipients by their username part of the email address e.g abuse@, postmaster@, but this is generally less helpful.
There is no way of whitelisting sender's e-mail addresses in the Greylisting app.
You may want to periodically update /etc/postfix/postgrey_whitelist_clients from http://postgrey.schweikert.ch/pub/postgrey_whitelist_clients
. It contains a number of sites whitelisted after the software release and is regularly maintained. After updating your whitelist file, restart the greylisting app. The following mini-script in /etc/cron.monthly or /etc/cron.weekly would do the job:
wget -q -N http://postgrey.schweikert.ch/pub/postgrey_whitelist_clients -O /etc/postfix/postgrey_whitelist_clients
service postgrey condrestart # ClearOS 6.x
systemctl condrestart postgrey.service # ClearOS 7.x
Choose just one of the condrestart lines and remember to make the script executable.
This is a strong recommendation
You can have a look at what the greylisting is doing with a:
grep postgrey /var/log/maillog
and you'll get a good view it. Especially in the early days of implementation it is worth going through the log to see if you are missing good e-mails, perhaps from a sender not retrying or the sender continually using different sending IP's. These senders will need to be whitelisted.