Our filtering systems are specifically designed to avoid false positives. For example, many different checks are performed to avoid making mistakes based on only one classifier.

There are two levels of filtering:

• SMTP Level Filtering
• DATA Level Filtering

Thanks to the combination of the many advanced filters and compliance with IETF RFC standards on how connections should be handled, our systems ensure email messages never disappear. The sender is always informed by their sending server when a message is rejected and messages blocked at the DATA level are usually available in the Quarantine.

SMTP Level Filtering

Incoming email connections are not blocked until after the "rcpt to:" SMTP command, as much as is possible. In doing so the system ensures that the connection belonging to the recipient domain in the logging server is properly logged. As a result, logs showing all connections made to a certain recipient are easy to access.

If a connection appears to be coming from an unknown source or it has not yet been ranked with a good reputation, it may be temporarily rejected with a 4xx code. In this scenario, the sending server queues the email in the Outbound Delivery Queue and automatically retries delivery (at a time controlled by the sending server administrator).

After ten minutes, the connection is accepted by the cluster on any of the filtering nodes, and the internal IP whitelists are adjusted to avoid this delivery delay occurring the next time.

This concept is also known as greylisting, however our implementation is a lot more advanced than traditional greylisting systems since all nodes are fully synchronized, and only connections from servers that are unknown to the network are temporarily delayed. Therefore email delays due to greylisting on active filtering clusters are rare and generally do not cause any problems for the recipients. If the connection appears to originate from a spamming source, it may also be temporarily rejected with a 4xx series code.

This way, even if the server is wrongly listed (for example on an external blacklist) as a spamming source, or if the spamming problem has been resolved on the sending server's domain configuration, the email still does not get rejected and will be delivered to the final recipient after a delay.

Only if the connection is from a known, spam-only source, or if the behavior is in direct conflict with the IETF RFC standards, a connection may be permanently rejected with a 5xx error code. If that ever happens for a legitimate sender, the sender will always receive a bounce notification from their sending server. This issue only occurs when there are serious problems with the sending server that can only be resolved at the sender's side. 5xx series rejections will only occur at SMTP level, when the receiving users have rules to do this, or if the source has been verified as sending only spam messages.

DATA Level Filtering

After the "DATA level" is reached, the system scans the email content of the message based on a combination of advanced statistical filtering technologies, spam fingerprint databases, malware, phishing detection and spyware. An email that is detected as spam, can be configured to be:

• Quarantined
• Dropped silently
• Delivered anyway

Email which is permanently rejected (5xx series status reply to the sending server) at this level as spam is quarantined, and will be available for release (except for viruses). If a legitimate email has been permanently blocked, the sending server is responsible for informing the sender that the email did not reach the destination recipient.