Hexamail POP3 Downloader Administration Guide - IP - Greylisting
Greylisting
Greylisting is a process of temporarily failing connections, based on the premise that spam software and bots often do not retry to send. Legitimate clients and MTAs should retry according to the SMTP Protocol RFC and so email is received normally, with a slight delay.
Each time a new combination of IP address, sender address and recipient address is spotted it is failed with a temporary error code at the SMTP server level.
If the same IP address retries the same sender and recipient combination later it is then accepted and delivered normally.
Therafter, all matching IP, sender and recipient combinations are allowed without delay.
Spam software often wont retry so this technique effectively blocks spam software, and bots from sending email to your server.
NOTE: legitimate email from new sources may be delayed according to the sending server, client or MTA retry schedule.
In the worst case a badly behaved sending server may fail to retry and the email wont be delivered.
The sender should however get a non delivery report from the sending server in this case.
Greylisting does not affect connections from authenticated clients, IPs listed as allowed Relay IPs in your SMTP Server/Relay page, allowed senders (or domains), or 'always allowed IPs'.
Use these lists to list any IPs, senders or domains you wish to bypass greylisting and have email delivered unhindered.
If you have any secondary MX servers they should also implement greylisting to prevent spammers simply sending using those servers.
Otherwise spam can be sent to your secondary server, which will (correctly) retry to send to your primary server and therefore bypass greylisting.
Greylisting
Enable greylisting
Enable greylisting of new triplets (IP, sender, recipient sets)
On/Off
on
Temporarily fail for
The length of time to fail a new 'triplet' (IP sender and recipient combination) with a temporary failure error (a 4.x.x SMTP error).
This is the MINIMUM delay you will experience in receiving email from a new source triplet.
Delays may be longer if the sending server retry schedule is longer than the time specified here.
Well behaved clients and MTAs should retry multiple times for a period of time.
Spam software and bots often do not bother retrying and so will effectively be blocked.
Lowering this setting allows faster receipt of email from new triplets, but may expose you to spam tools that do retry.
2 - 360 Minutes
15 Minutes
60 Minutes
Check first
This setting can be used to control how strict the greylist checking is. IF it is set to 4 it will check the entire IP address (IP4) or 16 for IP6.
If it is reduced to 3 or 2 it only checks the first parts of the IP address. This is useful if email is coming from very large
email providers with very many servers. In some cases the retried email is sent from a new server each time, causing strict greylisting to fail the email temporarily
for a long time. Using the 3 or even 2 setting can ensure the email is delivered more rapidly.
2 - 16 Octets
3 Octets
Expire bad after
The length of time to keep records about triplets that have not retried after a temporary fail,
often these are the records of spammers and not generally worth keeping for too long.
You do need to keep these records for long enough for legitimate senders to retry though, otherwise you will repeatedly block legitimate triplets.
Busy servers should set this setting low (2-4 hours) to avoid wasting resources. Less busy servers can extend this period to ensure more reliable delivery.
If you receive 1,500,000 email per day and it is mainly spam, you will require 25MBytes of RAM and disk space to store 4 hours of records.
2 - 12 Hours
5 Hours
4 Hours
Expire good after
The length of time to keep records about triplets that have succesfully sent email and are therefore no longer temporarily blocked.
Its worth keeping these for some time to allow legitimate clients and servers to send to your domain unhindered.
Some expiry is necessary to prevent a build up of no longer used records which waste resources.
Hexamail updates these records on every email that is passed, so the most common senders will never be delayed again.
1 - 365 Days
36 Days
60 Days
Exclude Allowlisted Senders
Don't greylist allowlisted senders
On/Off
Exclude DontCheck Recipients
Don't greylist recipients excluded from spam checks
On/Off
Exclude Recipients
Don't greylist recipients listed here, you can use wildcards e.g. *@domain.com
IP Allowlist
You may not wish to delay the email from some servers using greylisting. This may be because they are known reputable servers, or
incapable of correct SMTP retry behaviour. If you find you can't receive email from a specific server, even after the block delay, you may wish to allowlist the IP here.
This IP list is in addition to your Always Allowed IPs and the list of Relay IP servers specified in SMTP Server. This list specifically allows IPs to bypass greylisting and nothing more.
The default list includes local network addresses, reputable servers and some servers known to have trouble sending thru greylisting servers.
If you set your SMTP Server log to DEBUG mode you will see allowlisted servers being skipped for greylisting, allowing you to identify servers you may wish to remove.
You can optionally schedule greylisting only for specific times of the week.
For example this can be used to prevent any unnecessary delay in email during working hours, but allow greylisting to take effect at weekends.
Remember that only email from a new sender, ip and recipient triplet is delayed.
