How to Reduce Incoming SPAM and MTA Overload using Postscreen

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[]

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

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 []:20438 
Mar  1 02:03:26 edge01 postfix/postscreen[23154]: CONNECT from []:58010 to []:25 
Mar  1 02:03:26 edge01 postfix/postscreen[23154]: WHITELISTED []:58010 
Mar  1 02:03:27 edge01 postfix/postscreen[23154]: NOQUEUE: reject: RCPT from []:20438: 550 5.7.1 Service unavailable; client [] blocked using; from=<>, to=<>, proto=ESMTP, helo=
Mar  1 02:03:27 edge01 postfix/postscreen[23154]: DISCONNECT []:20438


Additonal Content

, , ,

5 Responses to How to Reduce Incoming SPAM and MTA Overload using Postscreen

  1. Mike Hammett September 14, 2017 at 1:57 PM #

    Is this purely about reducing server load or are there any anti-SPAM improvements?

    • Jorge de la Cruz September 14, 2017 at 3:21 PM #

      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.

  2. Afsher September 15, 2017 at 7:17 PM #

    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.

Copyright © 2022 Zimbra, Inc. All rights reserved.

All information contained in this blog is intended for informational purposes only. Synacor, Inc. is not responsible or liable in any manner for the use or misuse of any technical content provided herein. No specific or implied warranty is provided in association with the information or application of the information provided herein, including, but not limited to, use, misuse or distribution of such information by any user. The user assumes any and all risk pertaining to the use or distribution in any form of any subject matter contained in this blog.

Legal Information | Privacy Policy | Do Not Sell My Personal Information | CCPA Disclosures