Yes - Mail Assure applies an advanced form of greylisting to help stop a significant amount of spam with minimal resource usage. Although greylisting is a controversial technology, it is still highly effective when applied properly.
First of all it's important to mention that all nodes within the cluster are synchronized, and aware of the connections made to each other. Therefore, for greylisting technology, it does not matter to what node a connection is made. Mail Assure also keeps track centrally of "reputable hosts" to avoid any greylisting delays from known legitimate servers.
Greylisting works based on the 'triplet' information consisting of:
- sending server IP /24 subnet
- sender email address
- recipient email address
When the system receives a connection from an unknown 'triplet', we will temporarily reject (SMTP code 4xx) the connection for 10 minutes after seeing the first attempt. A temporary reject in this case means that the sending server is requested to temporarily queue the email, and automatically retry later. Any legitimate SMTP server is required by the RFC to support this, and it is a fully automatic process of which the original sender will not receive any notification. It does not matter how often the server retries within the 10 minute interval or to which node. Mail Assure will only accept the email after the 10 minutes. This results in a short delivery delay, which is minimized by an advanced automatic system. After accepting the email from a previously unknown 'triplet', the 'triplet' becomes 'white' to avoid temporarily rejecting connections from such triplets in the future. Furthermore, whenever we have seen (at least) 5 different successful (white) triplets from the same IP /24 subnet or (at least) 2 different successful (white) triplets from the same subnet and sender email address, the subnet or subnet+address is added to an internal "greylisting Allow list" system to avoid greylisting connections from that IP. All active mail servers delivering email to the servers are therefore not influenced by the greylisting technology as they are on the internal "greylist Allow list". The greylisting technology is only applied to new unknown servers. Servers that have been Block listed for sending out spam, lose their Allow listed entry again so may shortly be greylisted for new connections.
Key points:
- Greylisted triplets become white after 10 minutes
- IP subnets are added to the "greylisting Allow list" after 5 white triplets
- IP subnet + sender address pairs are added to the "greylisting Allow list" after 2 white subnet+address pairs
- Greylist grey entries are expired after 8 hours
- Greylist Allow list entries are expired after 60 days (if they have not been seen again)
- Greylist triplets only apply to individual recipient domains, but the "greylisting Allow list" is shared across all domains for a cluster
The "sending server IP /24 subnet" is basically the first part of the sending server's IP address. For example, if the server's IP was 222.153.243.117, then the string used in the 'triplet' would be '222.153.243'. This includes up to 256 (.0 to .255) servers, almost always within the same organization. This means that if an organization has several sending servers (typically within the same subnet), it does not matter which sending server makes the second attempt.
Be Advised: Most support questions regarding temporarily rejected connections are because customers see the temporary reject log entries, and are not aware that the message was NOT blocked/identified as spam. The message was only shortly delayed to verify that the sending server is behaving correctly (in accordance with the requirement for SMTP servers).
It should also be noted that delays due to greylisting are on the sender's side: the 451 temporary fail message just means 'Try again later'. The system will accept the message after 10 minutes but we have NO control over how long the sending server takes to retry. Most sending servers retry after a few minutes but some may wait hours.
More information on the RFC and greylisting can be found in RFC1123 - Section 5.3.1.1