Zmprov mcf zimbraMtaPostscreenCommandCountLimit 20 Zmprov mcf zimbraMtaPostscreenCacheRetentionTime 7d Zmprov mcf zimbraMtaPostscreenCacheCleanupInterval 12h Zmprov mcf zimbraMtaPostscreenBlacklistAction ignore Zmprov mcf zimbraMtaPostscreenBareNewlineTTL 30d Zmprov mcf zimbraMtaPostscreenBareNewlineEnable no Zmprov mcf zimbraMtaPostscreenBareNewlineAction ignore zmprov mcf zimbraMtaPostscreenAccessList permit_mynetworks This configuration is medium/high level, enforcing a few attributes: instead of ignoring, they are changed to drop for a higher level of security. In this case, all values are set at GlobalConfig level. Quick Postscreen C onfiguration ExampleĮach scenario can be different, so please tune the next values according to your own environment. Take a look to the previous table to find the defaults values for each postscreen attribute. Zimbra Collaboration Postscreen comes enabled by default in ZCS 8.7 or above. All the bots or zombies are rejected by default.

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. You can this mail flow in postscreen on the section below. 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. 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. 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: timeout after RCPT from How It Works Scenario without PostscreenĪ 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. The purpose is to keep spambots away from Postfix SMTP server processes, while minimizing overhead for legitimate traffic. Zimbra Collaboration Postscreen is not an SMTP proxy this is intentional. Zimbra Collaboration Postscreen logs rejected mail with the client address, helo, sender and recipient information. In a typical production setting, postscreen is configured to reject mail from clients that fail one or more tests. This minimizes the overhead for legitimate mail. When an SMTP client IP address is whitelisted, postscreen hands off the connection immediately to a Postfix SMTP server process. Zimbra Collaboration Postscreen maintains a temporary white-list for clients that have passed a number of tests. Alternatively, a site could set up a dedicated, non-postscreen “port 25” server that provides submission service and client authentication but no MX service. 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. Zimbra Collaboration Postscreen should not be used on SMTP ports that receive mail from end-user clients (MUAs). By keeping spambots away, postscreen leaves more SMTP server processes available for legitimate clients and delays the onset of server overload conditions. One postscreen process handles multiple inbound SMTP connections and decides which clients may talk to a Post-fix SMTP server process. Zimbra Postscreen, availabile starting with Zimbra Collaboration 8.7, provides additional protection against mail server overload. By Jorge de la Cruz on Septemin Open Source, PowerTips – Admins, Zimbra Server

Zimbra desktop send to mail recipient