Support

Guides, Articles and Frequently Asked Questions






  Index | Inbound Filter

Which methods are used for filtering?


The filtering methods and the EuropeanMX system have been specially designed to avoid false positives messages. To avoid errors due to a single classification, a large amount of different checks are performed. Basically, the exam can be divided into 2 levels: the SMTP level and the DATA level. Thanks to the combination of many different filtering systems and compliance with RFC policies, which are described how to handle a single connection, we can ensure that a message never disappears. The sender is always informed by his mail server if a message has been rejected or blocked and moved to quarantine.

SMTP level

As often as possible we try not to block a message after the "rcpt to:"SMTP command. This ensures that all connections to the recipient domain are properly stored on the protocol server. This can help to keep track of the recipient account connections.

Before reaching the DATA level, various other things are checked (e. g. whether the connection standards according to RFC have been adhered to, the server is not entered on any internal and/or external blacklist, etc.). If the connection is established from an unknown server that does not yet have a good reputation in our system, it is possible that the message is temporarily rejected with a 4xx code. In this case, the sending server will queue the message and try to resend it. After 10 minutes, the connection to our network is accepted and the internal whitelist is adjusted to avoid delays in the future. This concept is commonly known as greylisting. However, in contrast to the traditional "greylisting", our concept is much more advanced. All server nodes are synchronized with each other and only connections unknown to the EuropeanMX network are blocked. For this reason, delays due to greylisting within a filter cluster are very unusual and usually cause no problems for recipients.


If the connection is established from a spam source, it could happen that the message is temporarily rejected with a 4xx code. In this way, even if the server has been mislisted as a spam source (e. g. on an external blacklist) or the spam problem has been solved on the sent server, the message is not lost and is forwarded to the final recipient. This does not apply to connections originating from a known source that is used exclusively for sending spam or where the behavior does not correspond to the RFC standard. In this case, the connection may be permanently rejected with a 5xx error. If this should ever happen to a legitimate sender, the sender will always receive a bounce notification from his mail server. This problem only occurs if there are serious problems with the sending server. This issue must then be investigated on the sender side.

DATA level

After reaching the DATA level, the content of the message is examined based on a combination of advanced statistical filtering technologies, spam fingerprint databases, virus, phishing and spyware databases. If a message is detected as spam, it will either be rejected temporarily (4xx error) or permanently (5xx error) depending on the achieved score. A message that is permanently rejected will be quarantined by the filter and can be released from there (except for viruses). If a legitimate message is permanently blocked, the sender will always be informed by the sending mail server that the message could not be delivered.

Graphic illustration


Was this article helpful?




We use cookies for the technical functionality of this website. With your consent, we also collect page views and other statistical data in anonymized form.

Accept all cookies Select individually
Cookie Settings
Read Privacy Statement