mta.adoc

Zimbra Mail Transfer Agent

The Zimbra MTA (Mail Transfer Agent) receives mail via SMTP and routes each message using Local Mail Transfer Protocol (LMTP) to the appropriate Zimbra mailbox server.

Note	You can set MTA parameters with the Admin Console and the CLI. However, it is highly recommended that you use the CLI for MTA configuration to ensure the best results.

The Zimbra MTA server includes the following programs:

MTA Server Programs	Purpose/Description
Postfix MTA	Mail routing, mail relay, and attachment blocking
Clam Anti-Virus	Scanning email messages and attachments in email messages for viruses
Spam Assassin	Identify unsolicited commercial email (spam)
Amavisd-New	Interface between Postfix and ClamAV / SpamAssassin
Zimbra Milter Server	Enforce restrictions on which addresses can send to distribution lists and adds Reply-To and X-Zimbra-DL headers to messages sent from distribution lists
Zimbra policy server	Aid in protecting Alias Domains from Backscatter Spam
Cluebringer	Policy daemon/cbpolicyd used to enforce actions, such as rate limiting. For more information, see https://wiki.zimbra.com/wiki/Postfix_Policyd
Opendkim	Sign outgoing email if it has been configured to do so. For more information, see https://wiki.zimbra.com/wiki/Configuring_for_DKIM_Signing

In the {product-name} configuration, mail transfer and delivery are distinct functions: Postfix acts as a MTA, and the Zimbra mail server acts as a Mail Delivery Agent (MDA).

The MTA configuration is stored in LDAP. The zmconfigd process polls the LDAP directory every two minutes for modifications and updates the Postfix configuration files with the changes.

Incoming Mail Routing Overview

The Zimbra mailbox server receives the messages from the Zimbra MTA server and passes them through any filters that have been created.

The MTA server receives mail via SMTP and routes each mail message to the appropriate mailbox server using LMTP. As each mail message arrives, its contents are indexed so that all elements can be searched.

Zimbra MTA Deployment

{product-abbrev} includes a precompiled version of Postfix to route and relay mail and manage attachments. Postfix receives inbound messages via SMTP, performs anti-virus and anti-spam filtering and hands off the mail messages to the {product-name} server via LMTP.

Postfix also plays a role in transferring outbound messages. Messages composed from the {product-short} {web-client} are sent by the Zimbra server through Postfix, including messages sent to other users on the same server.

Tip	The Edge MTA can be any edge security solution for mail. You might already deploy such solutions for functions such as filtering. Some filtering might be duplicated between an edge MTA and the Zimbra MTA.

Postfix Configuration Files

Zimbra modified Postfix files — main.cf and master.cf — specifically to work with {product-abbrev}:

• main.cf — Modified to include the LDAP tables. The zmconfigd in the Zimbra MTA pulls data from the Zimbra LDAP and modifies the Postfix configuration files.

• master.cf — Modified to use Amavisd-New.

Important

Changes made to postfix configuration files will be overwritten with every upgrade and should be well documented. If possible, try to implement any necessary configuration changes using Zimbra defined parameters.

SMTP Authentication

SMTP authentication allows authorized mail clients from external networks to relay messages through the Zimbra MTA. The user ID and password is sent to the MTA when the SMTP client sends mail so that the MTA can verify if the user is allowed to relay mail.

The user ID and password is sent to the MTA when the SMTP client sends mail. This ensures that the MTA can verify if the user is allowed to relay mail, by checking the associated credentials with the LDAP account.

Note	User authentication is provided through the Zimbra LDAP directory server, or if implemented, through the Microsoft Active Directory Sever.

SMTP Restrictions

You can enable restrictions so that messages are not accepted by Postfix when non-standard or other disapproved behavior is exhibited by an incoming SMTP client. These restrictions provide some protection against spam senders. By default, clients that do not greet with a fully qualified domain name are restricted. DNS based restrictions are also available.

Important

Understand the implications of these restrictions before you implement them. You might have to compromise on these checks to accommodate people outside of your system who have poorly implemented mail systems.

Sending Non Local Mail to a Different Server

You can configure Postfix to send nonlocal mail to a different SMTP server, commonly referred to as a relay or smart host.

A common use case for a relay host is when an ISP requires that all your email be relayed through a designated host, or if you have filtering SMTP proxy servers.

The relay host setting must not be confused with Web mail MTA setting. Relay host is the MTA to which Postfix relays non-local email. Webmail MTA is used by the Zimbra server for composed messages and must be the location of the Postfix server in the Zimbra MTA package.

To use the Administration Console to configure Relay MTA for external delivery:

Admin Console:

Home → Configure → Global Settings → MTA → Network

Important

To prevent mail loops, use caution when setting the relay host.

Anti-Virus and Anti-Spam Protection

The Amavisd-New utility is the interface between the Zimbra MTA and Clam Anti-Virus (ClamAV) and SpamAssassin scanners.

Anti-Virus Protection

ClamAV software is the virus protection engine enabled for each {product-abbrev} server.

The anti-virus software is configured to put messages that have been identified as having a virus to the virus quarantine mailbox. By default, the Zimbra MTA checks every two hours for any new anti-virus updates from ClamAV.

You can change anti-virus settings at the Administration Console.

Admin Console:

Home → Configure → Global Settings → AS/AV → Anti-virus Settings

Note	Updates are obtained via HTTP from the ClamAV website.

Scanning Attachments in Outgoing Mail

You can enable real-time scanning of attachments in outgoing emails sent using the {product-short} {web-client}. If enabled, when an attachment is added to an email, it is scanned using ClamAV prior to sending the message. If ClamAV detects a virus, it will block attaching the file to the message. By default, scanning is configured for a single node installation.

To enable scanning, using a single node:

zmprov mcf zimbraAttachmentsScanURL clam://localhost:3310/
zmprov mcf zimbraAttachmentsScanEnabled TRUE

To enable scanning in a multi-node environment:

1. Designate the MTA nodes to handle ClamAV scanning.

2. Enable, as follows:

   zmprov ms <mta_server> zimbraClamAVBindAddress <mta_server>
   zmprov mcf zimbraAttachmentsScanURL clam://<mta_server>:3310/
   zmprov mcf zimbraAttachmentsScanEnabled TRUE

Anti-Spam Protection

Zimbra uses SpamAssassin to identify unsolicited commercial email (spam) with learned data stored in either the Berkeley DB database or a MariaDB database. You can also use the Postscreen function to provide additional protection against mail server overload. Both strategies are described in the following topics:

• Spam Assassin Methods for Avoiding Spam

• Postscreen Methods for Avoiding Spam

Spam Assassin Methods for Avoiding Spam

Usage guidelines are provided in the following topics:

• Managing the Spam Assassin Score

• Training the Spam Filter

• Configuring Final Destination for Spam

• Setting Up Trusted Networks

• Enabling a Milter Server

Note	For information about how to customize SpamAssassin, see https:// wiki.zimbra.com/wiki/Anti-spam_strategies.

Managing the Spam Assassin Score: SpamAssassin uses predefined rules as well as a Bayes database to score messages with a numerical range. Zimbra uses a percentage value to determine “spaminess” based on a SpamAssassin score of 20 as 100%. Any message tagged between 33%-75% is considered spam and delivered to the user’s junk folder. Messages tagged above 75% are always considered spam and discarded.

You can change the spam percentage settings, and the subject prefix at the Administration Console.

Admin Console:

Home → Configure → Global Settings → AS/AV → Spam checking Settings

By default, Zimbra uses the Berkeley DB database for spam training. You can also use a MariaDB database.

To use the MariaDB method on the MTA servers:

zmlocalconfig -e antispam_mariadb_enabled=TRUE

When this is enabled, Berkeley DB database is not enabled.

Training the Spam Filter — The effectiveness of the anti-spam filter is dependent on user input to differentiate spam or ham. The SpamAssassin filter learns from messages that users specifically mark as spam by sending them to their junk folder or not spam by removing them from their junk folder. A copy of these marked messages is sent to the appropriate spam training mailbox.

At installation, a spam/ham cleanup filter is configured on only the first MTA. The {product-abbrev} spam training tool, zmtrainsa, is configured to automatically retrieve these messages and train the spam filter. The zmtrainsa script empties these mailboxes each day.

Note

New installations of {product-abbrev} limit spam/ham training to the first MTA installed. If you uninstall or move this MTA, you will need to enable spam/ham training on another MTA, as one host should have this enabled to run zmtrainsa --cleanup. To set this on a new MTA server: zmlocalconfig -e zmtrainsa_cleanup_host=TRUE

Initially, you might want to train the spam filter manually to quickly build a database of spam and non-spam tokens, words, or short character sequences that are commonly found in spam or ham. To do this, you can manually forward messages as message/rfc822 attachments to the spam and non-spam mailboxes. When zmtrainsa runs, these messages are used to teach the spam filter. Make sure you add a large enough sampling of messages to get accurate scores. To determine whether to mark messages as spam at least 200 known spams and 200 known hams must be identified.

SpamAssassin’s sa-update tool is included with SpamAssassin. This tool updates SpamAssassin rules from the SA organization. The tool is installed into /opt/zimbra/common/bin.

Configuring Final Destination for Spam — You can configure Amavis behavior to handle a spam item’s final destination by using the following attribute:

zimbraAmavisFinalSpamDestiny

The default is D_DISCARD (which will not deliver the email to the addressee).

Setting final spam destiny attributes:

zmprov mcf "zimbraAmavisFinalSpamDestiny" D_PASS
zmprov ms serverhostname.com D_PASS

Table 1. Configurable attribute values

Value	Description
D_PASS	Deliver the email to the recipient. The email is likely to be placed in the recipient’s junk folder (although some sites disable junk).
D_BOUNCE	The email is bounced back to the sender. Because this setting can create backscatter — as the "sender" is not the person who actually sent the email — it is not advised.
D_REJECT	Reject the email. This setting reduces the chance of backscatter: If the sender is valid, the MTA will notify this person about the rejection. If the sender is not valid, the associated MTA will discard the email (i.e. email that was sent by a spammer spoofing someone else).
D_DISCARD	The email is silently discarded (not delivered).

Setting Up Trusted Networks: The {product-abbrev} configuration allows relaying only for the local network, but you can configure trusted networks that are allowed to relay mail. You set the MTA trusted networks as a global setting, but you can configure trusted networks as a server setting. The server setting overrides the global setting.

To use the Administration Console to set up MTA trusted networks as a global setting:

Admin Console:

Home → Configure → Global Settings → MTA → Network

When using the Administration Console to set up MTA trusted networks on a per server basis, first ensure that MTA trusted networks have been set up as global settings.

Admin Console:

Home → Configure → Servers → server → MTA → Network

Enter the network addresses separated by commas and/or a space. Continue long lines by starting the next line with space, similar to the following examples:

127.0.0.0/8, 168.100.189.0/24
127.0.0.0/8 168.100.189.0/24 10.0.0.0/8 [::1]/128 [fe80::%eth0]/64

Enabling a Milter Server: Milter server can be enabled to enforce restrictions on which addresses can send to distribution lists and add Reply-To and X-Zimbra-DL headers to messages sent from distribution lists. This can be enabled globally or for specific servers from the Administration Console.

Note	Only enable a Milter Server on a server where an MTA is running.

For global configuration, enable the milter server from the Administration Console:

Admin Console:

Home → Configure → Global Settings → MTA → Milter Server

Use the Administration Console to enable a specific milter server, and to set bind addressing for individual servers.

Admin Console:

Home → Configure → Servers → server → MTA → Milter Server

Postscreen Methods for Avoiding Spam

Zimbra Postscreen is the 8.7 enhancement to the {product-name} anti-spam strategy, to provide additional protection against mail server overload. By design, Postscreen is not an SMTP proxy. Its purpose is to keep spambots away from Postfix SMTP server processes, while minimizing overhead for legitimate traffic. A single Postscreen process handles multiple inbound SMTP connections and decides which clients may communicate to a Post-fix SMTP server process. By keeping spambots away, Postscreen frees up SMTP server processes for legitimate clients, and delays the onset of server overload conditions.

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 without MX service.

Important

Postscreen should not be used on SMTP ports that receive mail from end-user clients (MUAs).

{product-name} Postscreen maintains a temporary white-list for clients that have passed a number of tests. When an SMTP client IP address is whitelisted, Postscreen immediately passes the connection to a Postfix SMTP server process. This minimizes the overhead for legitimate mail.

In a typical scenario that uses Postscreen service, it is reasonable to expect potentially malicious email entities — such as bots and zombies — to be mixed in with friendly candidates in email loads. This concept is illustrated in the following diagram, in which undesirable entities are depicted in red; good email candidates are green.

Postscreen performs basic checks and denies connection(s) that are clearly from a bot or zombie. If the connection is not in the temporary whitelist, Postscreen passes the email to the local Anti-SPAM and Anti-Virus engines, which can either accept it or deny it. Good connections are accepted via Postscreen security, then allowed to talk directly with the SMTP daemon, which scans the Email (as usual) with the AS/AV. By default, all bots or zombies are rejected.

Use Zimbra CLI attributes to set parameters for Postscreen operations. For any Postscreen Attributes that provide the ignore, enforce, or drop instruction, use guidelines as follows:

• ignore — Ignore this result. Allow other tests to complete. Repeat this test with subsequent client connections. This is the default setting, which is useful for testing and collecting statistics without blocking mail.

• enforce — Allow other tests to complete. Reject attempts to deliver mail with a 550 SMTP reply, and log the hello/sender/recipient information. Repeat this test with subsequent client connections.

• drop — Drop the connection immediately with a 521 SMTP reply. Repeat this test with subsequent client connections.

Postscreen Attributes:

Go to the zmprov mcf prompt (release 8.7+) to use Postscreen commands. You can see example usages of these attributes in Enabling Postscreen.

• zimbraMtaPostscreenAccessList — Default = permit_mynetworks

  Postconf postscreen_access_list setting, which is the permanent white/ blacklist for remote SMTP client IP addresses. Postscreen(8) searches this list immediately after a remote SMTP client connects. Specify a comma- or whitespace -separated list of commands (in upper or lower case) or lookup tables. The search stops upon the first command that fires for the client IP address.

• zimbraMtaPostscreenBareNewlineAction — Default = ignore

  The action that postscreen(8) is to take when a remote SMTP client sends a bare newline character, that is, a newline not preceded by carriage return — as either ignore, enforce, or drop.

• zimbraMtaPostscreenBareNewlineEnable — Default = no

  Enable (yes) or disable (no) “bare newline” SMTP protocol tests in the postscreen(8) server. These tests are expensive: a remote SMTP client must disconnect after it passes the test, before it can talk to a real Postfix SMTP server.

• zimbraMtaPostscreenBareNewlineTTL — Default = 30d

  The amount of time allowable for postscreen(8) to use the result of a successful “bare newline” SMTP protocol test. During this time, the client IP address is excluded from this test. The default setting is lengthy because a remote SMTP client must disconnect after it passes the test, before it can talk to a real Postfix SMTP server.

  Specify a non-zero time value (an integral value plus an optional one-letter suffix that specifies the time unit). Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks).

• zimbraMtaPostscreenBlacklistAction — Default = ignore

  The action that postscreen(8) is to take when a remote SMTP client is permanently blacklisted with the postscreen_access_list parameter, as either ignore, enforce, or drop.

• zimbraMtaPostscreenCacheCleanupInterval — Default = 12h

  The amount of time allowable between postscreen(8) cache cleanup runs. Cache cleanup increases the load on the cache database and should therefore not be run frequently. This feature requires that the cache database supports the “delete” and “sequence” operators. Specify a zero interval to disable cache cleanup.

  After each cache cleanup run, the postscreen(8) daemon logs the number of entries that were retained and dropped. A cleanup run is logged as “partial” when the daemon terminates early after postfix reload, postfix stop, or no requests for $max_idle seconds.

  Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks).

• zimbraMtaPostscreenCacheRetentionTime — Default = 7d

  The amount of time that postscreen(8) is allowed to cache an expired temporary whitelist entry before it is removed. This prevents clients from being logged as “NEW” just because their cache entry expired an hour ago. It also prevents the cache from filling up with clients that passed some deep protocol test once and never came back.

  Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks).

• zimbraMtaPostscreenCommandCountLimit — Default = 20

  Value to set the limit on the total number of commands per SMTP session for postscreen(8)'s built-in SMTP protocol engine. This SMTP engine defers or rejects all attempts to deliver mail, therefore there is no need to enforce separate limits on the number of junk commands and error commands.

• zimbraMtaPostscreenDnsblAction — Default = ignore

  The action that postscreen(8) is to take when a remote SMTP client’s combined DNSBL score is equal to or greater than a threshold (as defined with the postscreen_dnsbl_sites and postscreen_dnsbl_threshold parameters), as either ignore, enforce, or drop.

• zimbraMtaPostscreenDnsblSites

  Optional list of DNS white/blacklist domains, filters and weight factors. When the list is non-empty, the dnsblog(8) daemon will query these domains with the IP addresses of remote SMTP clients, and postscreen(8) will update an SMTP client’s DNSBL score with each non-error reply.

  Warning

  When postscreen rejects mail, it replies with the DNSBL domain name. Use the postscreen_dnsbl_reply_map feature to hide “password” information in DNSBL domain names.

  When a client’s score is equal to or greater than the threshold specified with postscreen_dnsbl_threshold, postscreen(8) can drop the connection with the remote SMTP client.

  Specify a list of domain=filter*weight entries, separated by comma or whitespace.

  • When no =filter is specified, postscreen(8) will use any non-error DNSBL reply. Otherwise, postscreen(8) uses only DNSBL replies that match the filter. The filter has the form d.d.d.d, where each d is a number, or a pattern inside [] that contains one or more “;”-separated numbers or number..number ranges.

  • When no *weight is specified, postscreen(8) increments the remote SMTP client’s DNSBL score by 1. Otherwise, the weight must be an integral number, and postscreen(8) adds the specified weight to the remote SMTP client’s DNSBL score. Specify a negative number for whitelisting.

  • When one postscreen_dnsbl_sites entry produces multiple DNSBL responses, postscreen(8) applies the weight at most once.

  Examples:

  To use example.com as a high-confidence blocklist, and to block mail with example.net and example.org only when both agree:

  postscreen_dnsbl_threshold = 2
  postscreen_dnsbl_sites = example.com*2, example.net, example.org

  To filter only DNSBL replies containing 127.0.0.4:

  postscreen_dnsbl_sites = example.com=127.0.0.4

• zimbraMtaPostscreenDnsblThreshold — Default = 1

  Value to define the inclusive lower bound for blocking a remote SMTP client, based on its combined DNSBL score as defined with the postscreen_dnsbl_sites parameter.

• zimbraMtaPostscreenDnsblTTL — Default = 1h

  The amount of time allowable for postscreen(8) to use the result from a successful DNS-based reputation test before a client IP address is required to pass that test again.

  Specify a non-zero time value (an integral value plus an optional one-letter suffix that specifies the time unit). Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks).

• zimbraMtaPostscreenDnsblWhitelistThreshold — Default = 0

  Allow a remote SMTP client to skip “before” and “after 220 greeting” protocol tests, based on its combined DNSBL score as defined with the postscreen_dnsbl_sites parameter.

  Specify a negative value to enable this feature. When a client passes the postscreen_dnsbl_whitelist_threshold without having failed other tests, all pending or disabled tests are flagged as completed with a time-to-live value equal to postscreen_dnsbl_ttl. When a test was already completed, its time-to-live value is updated if it was less than postscreen_dnsbl_ttl.

• zimbraMtaPostscreenGreetAction — Default = ignore

  The action that postscreen(8) is to take when a remote SMTP client speaks before its turn within the time specified with the postscreen_greet_wait parameter, as either ignore, enforce, or drop.

• zimbraMtaPostscreenGreetTTL — Default = 1d

  The amount of time allowed for postscreen(8) to use the result from a successful PREGREET test. During this time, the client IP address is excluded from this test. The default is relatively short, because a good client can immediately talk to a real Postfix SMTP server.

  Specify a non-zero time value (an integral value plus an optional one-letter suffix that specifies the time unit). Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks).

• zimbraMtaPostscreenNonSmtpCommandAction — Default = drop

  The action that postscreen(8) takes when a remote SMTP client sends non-SMTP commands as specified with the postscreen_forbidden_ commands parameter, as either ignore, enforce, or drop.

• zimbraMtaPostscreenNonSmtpCommandEnable — Default = no

  Enable (yes) or disable (no) "non- SMTP command" tests in the postscreen(8) server. These tests are expensive: a client must disconnect after it passes the test, before it can talk to a real Postfix SMTP server.

• zimbraMtaPostscreenNonSmtpCommandTTL — Default = 30d

  The amount of time allowable for postscreen(8) to use the result from a successful “non_smtp_command” SMTP protocol test. During this time, the client IP address is excluded from this test. The default is long because a client must disconnect after it passes the test, before it can talk to a real Postfix SMTP server.

  Specify a non-zero time value (an integral value plus an optional one-letter suffix that specifies the time unit). Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks).

• zimbraMtaPostscreenPipeliningAction — Default = enforce

  The action that postscreen(8) is to take when a remote SMTP client sends multiple commands instead of sending one command and waiting for the server to respond, as either ignore, enforce, or drop.

• zimbraMtaPostscreenPipeliningEnable — Default = no

  Enable (yes) or disable (no) “pipelining” SMTP protocol tests in the postscreen(8) server. These tests are expensive: a good client must disconnect after it passes the test, before it can talk to a real Postfix SMTP server.

• zimbraMtaPostscreenPipeliningTTL — Default = 30d

  Time allowable for postscreen(8) to use the result from a successful “pipelining” SMTP protocol test. During this time, the client IP address is excluded from this test. The default is lengthy because a good client must disconnect after it passes the test, before it can talk to a real Postfix SMTP server.

  Specify a non-zero time value (an integral value plus an optional one-letter suffix that specifies the time unit). Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks).

• zimbraMtaPostscreenWatchdogTimeout — Default = 10s

  Time allowable for a postscreen(8) process to respond to a remote SMTP client command, or to perform a cache operation, before it is terminated by a built-in watchdog timer. This is a safety mechanism that prevents postscreen(8) from becoming non-responsive due to a bug in Postfix itself or in system software. To avoid false alarms and unnecessary cache corruption this limit cannot be set under 10s.

  Specify a non-zero time value (an integral value plus an optional one-letter suffix that specifies the time unit). Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks).

• zimbraMtaPostscreenWhitelistInterfaces

  A list of local postscreen(8) server IP addresses where a non-whitelisted remote SMTP client can obtain postscreen(8)'s temporary whitelist status. This status is required before the client can talk to a Postfix SMTP server process. By default, a client can obtain postscreen(8)'s whitelist status on any local postscreen(8) server IP address.

  When postscreen(8) listens on both primary and backup MX addresses, the postscreen_whitelist_interfaces parameter can be configured to give the temporary whitelist status only when a client connects to a primary MX address. Once a client is whitelisted it can talk to a Postfix SMTP server on any address. Thus, clients that connect only to backup MX addresses will never become whitelisted, and will never be allowed to talk to a Postfix SMTP server process.

  Specify a list of network addresses or network/netmask patterns, separated by commas and/or whitespace. The netmask specifies the number of bits in the network part of a host address. Continue long lines by starting the next line with whitespace.

  You can also specify /file/name or type:table patterns. A /file/name pattern is replaced by its contents; a type:table lookup table is matched when a table entry matches a lookup string (the lookup result is ignored).

  The list is matched left to right, and the search stops on the first match. Specify !pattern to exclude an address or network block from the list.

  Note	IPv6 address information must be specified inside [] in the postscreen_whitelist_interfaces value, and in files specified with /file/name. IP version 6 addresses contain the “:” character, and would otherwise be confused with a type:table pattern.

  Example:

  /etc/postfix/main.cf:
  
  # Don't whitelist connections to the backup IP address.
  postscreen_whitelist_interfaces = !168.100.189.8, static:all

• zimbraMtaPostscreenDnsblMinTTL — Default = 60s

  The minimum amount of time that postscreen(8) is allowed — resulting from a successful DNS -based reputation test — before a client IP address is required to pass that test again. If the DNS reply specifies a larger TTL value, that value will be used unless it would be larger than postscreen_dnsbl_max_ttl.

  Specify a non-zero time value (an integral value plus an optional one-letter suffix that specifies the time unit). Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks).

• zimbraMtaPostscreenDnsblMaxTTL — Default = postscreen dnsbl ttl

  The maximum amount of time allowable for postscreen(8) to use the result from a successful DNS-based reputation test before a client IP address is required to pass that test again. If the DNS reply specifies a shorter TTL value, that value will be used unless it would be smaller than postscreen_dnsbl_min_ttl.

  Specify a non-zero time value (an integral value plus an optional one-letter suffix that specifies the time unit). Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks).

  Note that the default setting is backwards-compatible with Postscreen versions earlier than 3.1.

Enabling Postscreen:

The example in this section demonstrates settings appropriate for a global configuration with medium-to-high level Postscreen protection.

Example 1. Global Configuration for Postscreen

zmprov mcf zimbraMtaPostscreenAccessList permit_mynetworks
zmprov mcf zimbraMtaPostscreenBareNewlineAction ignore
zmprov mcf zimbraMtaPostscreenBareNewlineEnable no
zmprov mcf zimbraMtaPostscreenBareNewlineTTL 30d
zmprov mcf zimbraMtaPostscreenBlacklistAction ignore
zmprov mcf zimbraMtaPostscreenCacheCleanupInterval 12h
zmprov mcf zimbraMtaPostscreenCacheRetentionTime 7d
zmprov mcf zimbraMtaPostscreenCommandCountLimit 20
zmprov mcf zimbraMtaPostscreenDnsblAction enforce
zmprov mcf \
  zimbraMtaPostscreenDnsblSites 'b.barracudacentral.org=127.0.0.2_7' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.inps.de=127.0.0.2*7' \
  zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org=127.0.0.[10;11]*8' \
  zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org=127.0.0.[4..7]*6' \
  zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org=127.0.0.3*4' \
  zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org=127.0.0.2*3' \
  zimbraMtaPostscreenDnsblSites 'list.dnswl.org=127.0.[0..255].0*-2' \
  zimbraMtaPostscreenDnsblSites 'list.dnswl.org=127.0.[0..255].1*-3' \
  zimbraMtaPostscreenDnsblSites 'list.dnswl.org=127.0.[0..255].2*-4' \
  zimbraMtaPostscreenDnsblSites 'list.dnswl.org=127.0.[0..255].3*-5' \
  zimbraMtaPostscreenDnsblSites 'bl.mailspike.net=127.0.0.2*5' \
  zimbraMtaPostscreenDnsblSites 'bl.mailspike.net=127.0.0.[10;11;12]*4' \
  zimbraMtaPostscreenDnsblSites 'wl.mailspike.net=127.0.0.[18;19;20]*-2' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.10*8' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.5*6' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.7*3' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.8*2' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.6*2' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.9*2'
zmprov mcf zimbraMtaPostscreenDnsblTTL 5m
zmprov mcf zimbraMtaPostscreenDnsblThreshold 8
zmprov mcf zimbraMtaPostscreenDnsblTimeout 10s
zmprov mcf zimbraMtaPostscreenDnsblWhitelistThreshold 0
zmprov mcf zimbraMtaPostscreenGreetAction enforce
zmprov mcf zimbraMtaPostscreenGreetTTL 1d
zmprov mcf zimbraMtaPostscreenNonSmtpCommandAction drop
zmprov mcf zimbraMtaPostscreenNonSmtpCommandEnable no
zmprov mcf zimbraMtaPostscreenNonSmtpCommandTTL 30d
zmprov mcf zimbraMtaPostscreenPipeliningAction enforce
zmprov mcf zimbraMtaPostscreenPipeliningEnable no
zmprov mcf zimbraMtaPostscreenPipeliningTTL 30d
zmprov mcf zimbraMtaPostscreenWatchdogTimeout 10s
zmprov mcf zimbraMtaPostscreenWhitelistInterfaces static:all

Testing Postscreen:

Testing uses Postscreen to view results without taking any action. In a testing scenario, you instruct Postscreen to log email connections without taking action on them. Once you are satisfied with the results, you can set Postscreen values to enforce or drop emails, as required.

1. Set up the DNS-based Blackhole List (DNSBL).

2. Set Postscreen to ignore.

The following real-world example demonstrates return of a 550 error from Postscreen during a test session:

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=<gmail.com>

Mar 1 02:03:27 edge01 postfix/postscreen[23154]: DISCONNECT [112.90.37.251]:20438

Receiving and Sending Mail

The Zimbra MTA delivers the incoming and the outgoing mail messages. For outgoing mail, the Zimbra MTA determines the destination of the recipient address. If the destination host is local, the message is passed to the Zimbra server for delivery. If the destination host is a remote mail server, the Zimbra MTA must establish a communication method to transfer the message to the remote host. For incoming messages, the MTA must be able to accept connection requests from remote mail servers and receive messages for the local users.

To send and receive email, the MTA must be configured in DNS with both an A record and an MX Record. For sending mail, the MTA uses DNS to resolve hostnames and email-routing information. To receive mail, the MX record must be configured correctly to route messages to the mail server.

You must configure a relay host if you do not enable DNS.

Message Queues

When the Zimbra MTA receives mail, it routes the mail through a series of queues to manage delivery; incoming, active, deferred, hold, and corrupt.

The incoming message queue holds the new mail that has been received. Each message is identified with a unique file name. Messages are moved to the active queue when there is room. If there are no problems, message move through this queue very quickly.

The active message queue holds messages that are ready to be sent. The MTA sets a limit to the number of messages that can be in the active queue at any one time. From here, messages are moved to and from the anti-virus and anti-spam filters before being delivered to another queue.

Messages that cannot be delivered are placed in the deferred queue. The reasons for the delivery failures are documented in a file in the deferred queue. This queue is scanned frequently to resend the message. If the message cannot be sent after the set number of delivery attempts, the message fails and is bounced back to the original sender. You can choose to send a notification to the sender that the message has been deferred.

The hold message queue keeps mail that could not be processed. Messages stay in this queue until the administrator moves them. No periodic delivery attempts are made for messages in the hold queue.

The corrupt queue stores damaged unreadable messages.

You can monitor the mail queues for delivery problems from the Administration Console. See Monitoring {product-abbrev} Servers.