We use an advanced form of "greylisting"to prevent significant amounts of spam with minimal resource consumption. Although "greylisting" is a controversial technology, it is still very effective when used correctly.
First of all, it is important to say that all nodes in the server cluster have knowledge of each other's connections and are synchronized. Therefore, for the "greylisting"technology, it does not matter to which node the connection is established. Furthermore, we remember legitimate hosts to avoid a delay due to "greylisting" of allowed servers.
"Greylisting" is based on the triplet information consisting of "Sending Server IP/24 subnet", "Sender Email Address" and "Recipient Email Address". Whenever we receive a message from an unknown "triplet", the connection is temporarily rejected for 10 minutes after the first attempted delivery (SMTP 4xx error). A temporarily rejected email means that the sending mail server is prompted to queue the message and try delivery again at a later time. Every proper mail server is obliged to support this method according to RFC. This is a fully automated process in which the sender does not receive a notification. It does not matter how many times the message is sent again within this 10-minute interval or sent to another node, since the new delivery is only accepted by our server after 10 minutes. This results in a small delay, which is why we use an extended system to avoid any delays. After the message from the initially unknown triplet has been accepted, the triplet becomes "white" so that future triplets are no longer rejected temporarily. Furthermore, whenever we see at least 5 different successful "white" triplets coming from the same IP / 24 subnet, or at least 2 successful "white" triplets coming from the same IP / 24 subnet and from the same sender address, the subnet or subnet+address will be added to an internal "whitelist" to avoid any delays from the same IP. All active mail servers delivering a message to our servers nodes are therefore not affected by the "Greylisting"technology, as these mail servers are entered on an internal "Greylisting Whitelist". The greylisting procedure only applies to unknown servers. A server that has temporarily landed on a blacklist loses the whitelist entry again, which is why it is greylisted on new connections.
Please note: Most support questions are related to temporarily rejected connections, as many customers only see the log entry that the message has been rejected temporarily and are unaware that this does not mean that the message has been blocked or identified as spam. The message was delayed only briefly to verify that the sending server is behaving correctly (in accordance with the SMTP server requirements).
Please note: The sending server IP / 24 Subnet is basically the first part of the IP address of the sending server. For example, if a server has IP 126.96.36.199, the string used in the triplet is 222.153.243, which includes up to 256 (. 0 -. 255) servers, usually within the same organization.This means that if an organization uses multiple sending mail servers (typically on the same subnet), it doesn't matter from which server the second delivery attempt is made.
More information about RFC and greylisting can be found in section 188.8.131.52 in RFC1123 (http://www.ietf.org/rfc/rfc1123.txt).