Email has firmly established itself as the standard for business communication. Due to the high cost-effectiveness of emails, as well as a number of features related to quoting text and attaching attachments, emails are the best fit for the role of a universal way to exchange documents and polite business communication. These same features are the reason why spammers love email so much. As a result, today's e-mail is a huge raging ocean of spam, in the waters of which only occasionally business letters are found. That is why one of the primary tasks of the administrator of any mail server is to protect against spam mailings. Let's take a look at what can be done with this in the Zimbra Collaboration Suite Open-Source Edition.
Although the solution is free, Zimbra OSE is able to provide the system administrator with a lot of extremely effective tools to solve the problem of receiving unwanted emails. We have already written about such utilities as Amavis, SpamAssassin, ClamAV and cbpolicyd, which allow you to reliably filter incoming mail, filtering out spam mailings, as well as infected and phishing emails. However, their key disadvantage is that they all work with already received mail messages and waste system resources on filtering useless messages, which can always be put to much better use. But what if your enterprise is targeted by a large botnet that constantly bombards your mail server with such large quantities of junk mail that filtering them alone would take the lion's share of the MTA's server capacity?
In theory, you can protect yourself from this by connecting a cloud service to filter incoming mail, but in practice, this method of protection is far from suitable for every enterprise, because in this case you will have to entrust third parties with processing not only spam, but also business correspondence, which is far from always safe, and often directly contrary to the company's security policy. In addition, there are risks associated with the reliability of the cloud spam filter. The way out of this situation can be the organization of server protection on its own. Especially for these purposes, the Postscreen utility was built into Zimbra, which is designed to protect the mail server from letters sent by botnets without loading the mail server.
The essence of Postscreen is that this utility views all requests for connection to the mail server and prevents clients it deems suspicious from connecting to the server. Since statistics show that approximately 90% of spam worldwide is sent by botnets, Postscreen is often used as a first line of defense for mail servers against unwanted emails. This allows the mail server to operate reliably without overload, even during intense spam attacks from large botnets.
The principle of operation of Postscreen is quite simple, the utility is able to carry out a number of simple checks of incoming messages before passing them to the mail server or other services that conduct a deeper and more detailed check of incoming letters. Each of the checks, respectively, can be passed, or may not be passed. Based on the results of each of the checks, Postscreen can take one of three actions at the choice of the Zimbra administrator: Drop, ignore or In strength. Action Drop forcibly terminates the connection with the client if the check fails, the action ignore allows you to ignore the results of the check when making the final decision, but at the same time collect information and statistics on the conduct of checks, and the action In strength allows you to take into account the results of the tests performed when making the final decision, but at the same time continue to perform all the tests that are scheduled by the system administrator.
A simple principle of operation does not mean ease of use and configuration. The fact is that an incorrectly configured Postscreen can be the reason why a number of letters important for the enterprise do not reach the addressee. That is why the configuration of such a powerful tool as Postscreen must be approached with great care and constantly tested for its behavior in certain situations.
Postscreen is included in Zimbra out of the box, but many may not be satisfied with the initial configuration. Now we will consider the best Postscreen configuration option in terms of security and lack of risks. Its essence lies in the fact that after the failure of any of the checks, Postscreen will not disconnect the connection with the client without talking, but will carry out all the checks to the end, and if these checks fail, it will display an error message. This will notify the live sender of the non-delivery of the letter in case Postscreen considers it to be spam. This is achieved by setting the enforce value in the check parameters. It is this value that allows you to complete the started checks to the end without breaking the connection with the client at the first failure, but at the same time, after they are completed, still block the spam message without delivering it to the server.
In order to enable the necessary checks, you need to enter the following commands:
zmprov mcf zimbraMtaPostscreenDnsblSites 'b.barracudacentral.org=127.0.0.2*7' zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org=127.0.0.[10;11]*8' ..127.0.0]*4' zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org=7*6' zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org=127.0.0.3*4'
This command allows you to add DNS checking of incoming connections against the two most popular public spam databases and rate messages depending on which database contains the sender's address. The more penalty stars a customer gets, the more likely they are to be a spammer
zmprov mcf zimbraMtaPostscreenDnsblAction enforce
This command defines the action to be taken after passing a DNS check. In this case, the result of the check is remembered, and the letter itself continues to pass further tests.
zmprov mcf zimbraMtaPostscreenGreetAction enforce
Since in the SMTP protocol, after a direct connection, the server is the first to start communicating with the client and, accordingly, Postscreen can send a greeting to the client. Due to the fact that many spam clients start sending commands without waiting for the end of the greeting, they can be easily recognized. This command allows you to consider the results of this test, but still continue to run further tests.
zmprov mcf zimbraMtaPostscreenNonSmtpCommandAction drop
As part of this check, Postscreen allows you to filter out those connections that do not come from email clients. Since they don't send any emails, you can safely disconnect them from the server.
zmprov mcf zimbraMtaPostscreenPipeliningAction enforce
This check is based on the fact that, by default, in the SMTP protocol, a client can only send one command at a time and then wait for the server to respond to that command. However, many spam bots behave differently, sending many commands without waiting for a response from the server. This allows almost unmistakable identification of a spam bot.
In principle, these checks for Postscreen will be more than enough to cut off the bulk of spam bots from the server and achieve a significant reduction in the load on your mail server. At the same time, living people will receive a message that their letter was not delivered, which significantly reduces the risk of losing important letters due to Postscreen settings. In the event that this happens, you can add the trusted sender to the Postscreen whitelist. In order to create Postscreen whitelists and blacklists, you first need to create a file /opt/zimbra/conf/postfix/postscreen_wblist.
We'll add a list of allowed and blocked IP addresses and subnets in CIDR table format. For example, we'll block the 121.144.169.* subnet, but allow only one connection. IP address from this subnet:
# Rules are evaluated in the order as specified.
# Blacklist 121.144.169.* except 121.144.169.196.
121.144.169.196/32
121.144.169.0/24 reject
We draw your attention to the importance of the order of entries. The fact is that Postscreen will scan a file with white and black lists until the first match, and if the blocked subnet is earlier than the allowed ip address, then the check will simply not reach the record that this ip address has been added to the white list and the connection will not happen to the server.
After the file with white and black lists has been edited and saved, you can enable the corresponding check using the following commands:
zmprov mcf zimbraMtaPostscreenAccessList "permit_mynetworks, cidr:/opt/zimbra/conf/postfix/postscreen_wblist"
zmprov mcf zimbraMtaPostscreenBlacklistAction enforce
Now Postscreen, in addition to the checks we have already set, will also access the file with white and black lists, which will allow the administrator to easily resolve issues with the inability to connect to the safe senders server.
Source: habr.com
