Zimbra Postscreen, availabile starting with Zimbra Collaboration 8.7, provides additional protection against mail server overload. One postscreen process handles multiple inbound SMTP connections and decides which clients may talk to a Post-fix SMTP server process. By keeping spambots away, postscreen leaves more SMTP server processes available for legitimate clients and delays the onset of server overload conditions.
Zimbra Collaboration Postscreen should not be used on SMTP ports that receive mail from end-user clients (MUAs). In a typical deployment, postscreen handles the MX service on TCP port 25, while MUA clients submit mail via the submission service on TCP port 587, which requires client authentication. Alternatively, a site could set up a dedicated, non-postscreen “port 25” server that provides submission service and client authentication but no MX service.
Zimbra Collaboration Postscreen maintains a temporary white-list for clients that have passed a number of tests. When an SMTP client IP address is whitelisted, postscreen hands off the connection immediately to a Postfix SMTP server process. This minimizes the overhead for legitimate mail.
In a typical production setting, postscreen is configured to reject mail from clients that fail one or more tests. Zimbra Collaboration Postscreen logs rejected mail with the client address, helo, sender and recipient information.
Zimbra Collaboration Postscreen is not an SMTP proxy; this is intentional. The purpose is to keep spambots away from Postfix SMTP server processes, while minimizing overhead for legitimate traffic.
How It Works
Scenario without Postscreen
A typical scenario without postscreen, and without other anti-spam security, will suffer from this common problem, where bots and zombies talk with all the Zimbra smtpd listeners.
In this scenario, the good connections, called other in this diagram, must wait until the bot or zombie finishes the communication, which sometimes can create a Timeout Error on Postfix for the good connections:
Mar 01 19:29:54 zimbrauk postfix/smtpd[24266]: timeout after RCPT from mail.example.com[60.60.60.70]
Scenario with Postscreen
In a typical postscreen scenario, where bots and zombies talk with postscreen, postscreen does all the basic checks and can deny the connection if the message is clearly from a bot or zombie. If the connection is not in the temporary whitelist, Postscreen will pass the email to the local anti-spam and anti-virus engines, who can accept it or deny it as usual. You can this mail flow in postscreen on the section below.
In this scenario, the good connections, called other in this diagram, pass postscreen security and talk directly with the smtp daemon, which scans the email as usual with AS/AV. All the bots or zombies are rejected by default.
How to Enable Postscreen
Zimbra Collaboration Postscreen comes enabled by default in ZCS 8.7 or above. Take a look to the previous table to find the defaults values for each postscreen attribute.
Quick Postscreen Configuration Example
Each scenario can be different, so please tune the next values according to your own environment. In this case, all values are set at GlobalConfig level. This configuration is medium/high level, enforcing a few attributes: instead of ignoring, they are changed to drop for a higher level of security. See https://wiki.zimbra.com/wiki/Zimbra_Collaboration_Postscreen
Testing Zimbra Collaboration Postscreen
Customers might want to set up the DNSBLs first, for example, but leave it on ignore. Postscreen will log what it would have done, but not do anything. Once you are satisfied that it is correct, you can set values to enforce or drop in certain cases.
A real-world log example where you can see the error 550 from postscreen:
Mar 1 02:03:26 edge01 postfix/postscreen[23154]: DNSBL rank 28 for [112.90.37.251]:20438 Mar 1 02:03:26 edge01 postfix/postscreen[23154]: CONNECT from [10.210.0.161]:58010 to [10.210.0.174]:25 Mar 1 02:03:26 edge01 postfix/postscreen[23154]: WHITELISTED [10.210.0.161]:58010 Mar 1 02:03:27 edge01 postfix/postscreen[23154]: NOQUEUE: reject: RCPT from [112.90.37.251]:20438: 550 5.7.1 Service unavailable; client [112.90.37.251] blocked using zen.spamhaus.org; from=<hfxdgdsggfvfg@gmail.com>, to=<support@zimbra.com>, proto=ESMTP, helo= Mar 1 02:03:27 edge01 postfix/postscreen[23154]: DISCONNECT [112.90.37.251]:20438
Additonal Content
- Read our Wiki to know much more about Zimbra Postscreen – https://wiki.zimbra.com/wiki/Zimbra_Collaboration_Postscreen
- See the Official Postfix Postscreen page
- Rob0’s Postscreen Configuration A non-official but real-world example
Is this purely about reducing server load or are there any anti-SPAM improvements?
Hi Mike,
Postscreen will reject bad SMTP connections, so those attacks will not even talk to your Zimbra Anti-SPAM, so at the end, yes you reduce the Incoming SPAM as well.
Hi Jorge,
Is it possible to make any exception here? I want to exclude a particular IP address from being blocked here.
Thanks in advance.
Hi Jorge,
I got my answer over here.
https://wiki.zimbra.com/wiki/Zimbra_Collaboration_Postscreen
Thanks.
Hi Afsher, I was about to tell you we have the whitelist and blacklist examples on the Wiki. thank you for trying it, and please do let us know your results. Thank you!