Despite the emergence of numerous instant messengers, it is email that is by far the most inexpensive way to send information, and given that emails support attachments in the form of files and embedding HTML scripts, it is email that is extremely often used to send spam. In addition to the obvious risks to the information security of the enterprise, spam also creates a significant load on the mail server. If it enters the user’s mailbox, it begins to take up space in the mail server’s data storage, and a business email can simply be lost in useless spam.
Postscreen works by monitoring and checking incoming connections using various SMTP checks, as well as using dynamic and static white and black lists to filter them.
The first checks that incoming connections go through are checks for the presence of an IP address in static and dynamic whitelists and blacklists, as well as a check using fake MX.
If the connecting client is neither on the whitelist nor on the blacklist, Postscreen performs a series of checks before greeting 220 SMTP. These checks include a test for waiting for a hello, as well as a check for blacklists located on the Internet. These checks allow you to effectively defend against DoS attacks.
When these checks pass or were not applied to an incoming connection, checks are made after the 220 SMTP hello. They include in-depth email analysis. These include a test for executing one command at a time, a test for sending non-SMTP commands, and a test for characters at the end of a line. These checks are the most “expensive” in terms of system resources, but the most effective in terms of spam detection.
We will go into more detail about all of these checks later on.
Static Blacklists and Whitelists
The Carbonio mail server administrator can create lists of trusted and untrusted networks. When creating a list of trusted networks, all messages that come from IP addresses included in it will be guaranteed to successfully pass the Postscreen check, and emails coming from IP addresses from untrusted networks will be automatically filtered out.
Black and white lists are configured with the zimbraMtaPostscreenAccessList command. By default, it has the value "permit_mynetworks", that is, it guarantees the successful completion of local mail delivery. In order to be able to add addresses to the white and black lists, you need to create an access table and add the zimbraMtaPostscreenAccessList parameter to it.
For example, let’s create a table /opt/zextras/postscreen_access.cidr. Make sure the user zextras has read and write access to this file. After that, you can start filling in this table. It consists of two columns: the left one contains the IP address or the entire subnet, and the right one contains the action that is applied to them. For example:
192.168.0.1 permit
10.0.1.1/16 rejectIn this case, we allow access to emails from the address 192.168.0.1 and prohibit receiving emails from the 10.0.1.1/16 subnet. A very important point is that the rules from the CIDR table are applied in order. That is if you first add an IP address to the black list with one rule, and then add it to the white list with another rule, then Postscreen will apply only the first rule to the message and will not reach the second.
In order to add the table we created to Postscreen, use the command
carbonio prov modifyConfig zimbraMtaPostscreenAccessList permit_mynetworks,cidr:/opt/zextras/postscreen_access.cidrAs in any other check, the administrator can configure the actions that are taken to the host if it is on the blacklist. This is configured using the zimbraMtaPostscreenBlacklistAction parameter. Actions are available: ignore the results of this check and go to others (ignore), take into account the results of the check, go to the next one (enforce), and refuse the connection (drop).
Dynamic Whitelists
In addition to statically defined lists, an effective measure is the automatic creation of dynamic whitelists. They are formed based on the results of passing checks from Postscreen. For example, if an email from a host successfully passes the check, Postscreen temporarily includes it in the trusted list so that incoming emails from it are accepted without any additional checks.
The results of the check are stored in the cache, and the time the host stays in the temporary white list depends on the checks that the email went through and can be configured by the administrator separately for each of the checks.
The administrator can set the cache purge time with a temporary whitelist. This is done using the command
carbonio prov modifyConfig zimbraMtaPostscreenCacheCleanupIntervalThe default value for this parameter is 12h, that is, 12 hours. The administrator can increase or decrease this time. If a null value is specified, the cache will no longer be cleared at all. Doing so is not recommended because it is not safe. On the other hand, clearing the cache creates a load on the mail server, so you should not run it too often either.
In addition to the standard cache, Postscreen also uses an extended cache that stores data from clients that have undergone deeper checks, including those related to the need to reconnect. Postscreen compensates for the inconvenience associated with this with a longer storage period for the results of the verification of such clients. The duration of their storage is regulated by the command
carbonio prov modifyConfig zimbraMtaPostscreenCacheRetentionTimeThe default value for this parameter is 7d, which is one week, and setting it to zero means that deep client scan results are stored forever.
Checking for a Connection to a Backup MX
One of the most common tricks used by spammers is to connect to the mail server through a backup MX server, which under normal circumstances is only used if the primary fails. As a rule, protection on such backup MXs is much weaker than on the main ones, however, if the corresponding check-in Postscreen is enabled, then the connection of the host to the backup MX will be fixed and if it subsequently passes all other checks on the main MXs, it will not be whitelisted because of this. This check is enabled automatically if Carbonio has a Primary and Backup MX and does not require any additional configuration.
Checking for Hello Waiting
As part of this check, Postscreen sends an SMTP hello to the connecting client and waits for a greeting back from it. The essence of the check is that automated mailing is implemented in such a way that it tries to send an email with spam until the victorious one and is not designed for more complex behavior patterns. Thus, instead of a return greeting, Postscreen receives another attempt to send an email and thus checks the incoming connection for legitimacy.
As with other checks, the administrator can configure the actions that are taken when this check fails. Actions are available: ignore the results of this check and go to others (ignore), take into account the results of the check, go to the next one (enforce), and refuse the connection (drop). By default, zimbraMtaPostscreenGreetAction is set to ignore.
Using the zimbraMtaPostscreenGreetTTL parameter, you can set the period of time during which a host that has successfully passed this check will be in the temporary white list. By default, this parameter is 1d, which is one day. You can configure it with a command like
carbonio prov modifyConfig zimbraMtaPostscreenGreetTTL 7dIf the value is set to zero, the host that passed the test is permanently included in the temporary whitelist.
Checking for DNS Blacklists
The essence of this check is to access public servers where blacklists are published in DNS format. If a host is found in such lists, the test is considered failed and the administrator-configured action is applied to the connecting host.
You can configure the list of blacklisted sites using the zimbraMtaPostscreenDnsblSites command. In the case of using several sources with DNS blacklists, a situation may arise when the host is present in some of them, and not in some of them. To prevent a legitimate message from being rejected by the mail server simply because the host is on one of the blacklists you use, you can set a certain threshold, which is formed based on the aggregate data from the sources you use.
This threshold is configured using the command
carbonio prov modifyConfig zimbraMtaPostscreenDnsblThreshold 2By default, the response from each of the sites listed in the zimbraMtaPostscreenDnsblSites list is 1 point, but the administrator can increase this value. For example, when executing
carbonio prov modifyConfig +zimbraMtaPostscreenDnsblSites blacklist.tld*2blacklist.tld will be added to the list of sites with DNS blacklists, and finding a host in this list will add 2 points to it. In our case, when the threshold is only two points, this means the failure of the corresponding check. Only use the score multiplier with DNS blacklists that are completely trusted ones.
Also, this test can be used as an ultimate test, upon passing which all other tests are either not applied, or are considered passed, and the host is added to the temporary white list. This is configured with the command
carbonio modifyConfig zimbraMtaPostscreenDnsblWhitelistThreshold 0Thus, a host that does not score a single point when checking DNS blacklists is exempt from further checks and is added to a temporary whitelist.
The duration of being whitelisted when passing the DNS blacklist test is controlled by the zimbraMtaPostscreenDnsblTTL setting. By default, it is 1 hour and can be configured similarly to other checks. Given that public blacklists are regularly updated, it may turn out that a host that has passed this check may be on them in a minute. That is why it is possible to configure exceptions for this check – hosts added to the white lists will still have to periodically pass this check to track changes. This exception is configured using the commands zimbraMtaPostscreenDnsblMinTTL and zimbraMtaPostscreenDnsblMaxTTL. With their help, the minimum period of time after which the host will need to pass this check, as well as the maximum period for storing data on the successful passing of this check, is configured. The default value of zimbraMtaPostscreenDnsblMinTTL is 60s, which is one minute, and the default value of zimbraMtaPostscreenDnsblMaxTTL is not set.
Also, using the zimbraMtaPostscreenDnsblAction parameter, you can configure the action that will be taken if this check fails. As with other checks, the ignore, drop, and enforce actions are available.
Checking for non-SMTP Commands
This check is disabled by default, as it requires the most resources and is also associated with certain risks. Its essence lies in the fact that the incoming SMTP connection is transferred to a fake SMTP server, where its behavior is carefully analyzed and if it starts sending SMTP commands that are forbidden to be executed, the check is considered failed. If the verification is successful, the client still disconnects from the server in order to connect to the real SMTP server.
To enable this check, set the zimbraMtaPostscreenNonSmtpCommandEnable parameter to yes. Also, using the zimbraMtaPostscreenNonSmtpCommandAction and zimbraMtaPostscreenNonSmtpCommandTTL parameters, you can configure the action that will be applied if the check fails (enforce, drop, ignore) and the time spent in the white list if it passes successfully (30d by default).
Checking Compliance with the Line Terminator Standard
Since SMTP is a line-oriented protocol, and the length of lines and their endings are strictly regulated, Postscreen can screen out incoming messages on the basis of compliance with standards. For example, if this check is enabled, then when a request is received, the line which ends with <LF> instead of the <CR><LF> provided by the standard, or the line length is exceeded, Postscreen can automatically filter out such an email.
This check is disabled by default, but an administrator can enable it using the command
carbonio prov modifyConfig zimbraMtaPostscreenBareNewlineEnable yesYou also need to configure the action that is taken when the client fails this check. Actions are available: ignore the results of this check and go to others (ignore), take into account the results of the check, go to the next one (enforce), and refuse the connection (drop). By default, zimbraMtaPostscreenBareNewlineAction is set to ignore.
The time when authenticated emails are added to the temporary white list is controlled by the zimbraMtaPostscreenBareNewlineTTL parameter. By default, it is 30d, which is 30 days. If you specify a value of zero, clients that pass this check are permanently whitelisted.
Check for One Command at a Time
This check allows you to detect zombie bots that uncontrollably send many SMTP commands to the server instead of sending one command, waiting for a response to it, and then sending the next one. This check is also disabled by default and can be enabled with the command
carbonio prov modifyConfig zimbraMtaPostscreenPipeliningEnable yesThe time when authenticated emails are added to the temporary whitelist is controlled by the zimbraMtaPostscreenPipeliningTTL parameter. The default value is 30d. If set to zero, authenticated clients are permanently whitelisted. You can configure the action when the client fails this check using the zimbraMtaPostscreenPipeliningAction parameter.
In addition to the checks themselves, Postscreen contains other settings that ensure its reliable and safe operation. These are zimbraMtaPostscreenCommandCountLimit – a parameter that defines the maximum number of SMTP commands that a client can send when connecting to Postscreen, and zimbraMtaPostscreenWatchdogTimeout – a parameter that defines the maximum time that Postscreen is given to respond to a client request. It serves to protect Postscreen from hanging or crashing within Postfix itself. By default, this parameter is 10 seconds and cannot be lower.
The most optimal Postscreen settings in Carbonio are:
- zimbraMtaPostscreenDnsblAction=enforce
- zimbraMtaPostscreenGreetAction=enforce
- zimbraMtaPostscreenPipeliningAction=enforce
- zimbraMtaPostscreenNonSmtpCommandAction=drop
- zimbraMtaPostscreenDnsblTTL=5m
Thus, Postscreen is the mail server’s first line of defense against spam, filtering it outwardly. Amavis, SpamAssassin, and ClamAV built into Carbonio are engaged in deeper mail filtering.