ZCS Administrator's Guide, Open Source Edition 5.0 (Rev 5.0.19 September 2009)
Table of Contents Previous Next Index


Zimbra MTA

Zimbra MTA
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.
The Zimbra MTA server includes the following programs:
In the Zimbra Collaboration Suite configuration, mail transfer and delivery are distinct functions. Postfix primarily acts as a Mail Transfer Agent (MTA) and the Zimbra mail server acts as a Mail Delivery Agent (MDA).
MTA configuration is stored in LDAP and a configuration script automatically polls the LDAP directory every two minutes for modifications, and updates the Postfix configuration files with the changes.
Zimbra MTA Deployment
The Zimbra Collaboration Suite includes a precompiled version of Postfix. This version does not have any changes to the source code, but it does include configuration file modifications, additional scripts, and tools.
Postfix performs the Zimbra mail transfer and relay. It receives inbound messages via SMTP, and hands off the mail messages to the Zimbra server via LMTP, as shown in Figure 6. The Zimbra MTA can also perform anti-virus and anti-spam filtering.
Postfix also plays a role in transfer of outbound messages. Messages composed from the Zimbra web client are sent by the Zimbra server through Postfix, including messages sent to other users on the same Zimbra server.
Figure 6: Postfix in a Zimbra Environment
*Edge MTA
The term edge MTA is a generic term referring to any sort of edge security solution for mail. You may already deploy such solutions for functions such as filtering. The edge MTA is optional. Some filtering may be duplicated between an edge MTA and the Zimbra MTA.
Postfix Configuration Files
Zimbra modified the following Postfix files specifically to work with the Zimbra Collaboration Suite:
main.cf Modified to include the LDAP tables. The configuration script in the Zimbra MTA pulls data from the Zimbra LDAP and modifies the Postfix configuration files.
master.cf Modified to use Amavisd-New.
Important: Do not modify the Postfix configuration files directly! Some of the Postfix files are rewritten when changes are made in the administration console. Any changes you make will be overwritten.
MTA Functionality
Zimbra MTA Postfix functionality includes:
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 the MTA can verify if the user is allowed to relay mail.
Note: User authentication is provided through the Zimbra LDAP directory server, or if implemented, through the Microsoft Active Directory Sever.
SMTP Restrictions
In the administration console, 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 ill-behaved spam senders. By default, SMTP protocol violators (that is, 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 may want to receive mail from people outside of your mail system, but those mail systems may be poorly implemented. You may have to compromise on these checks to accommodate them.
Relay Host Settings
Postfix can be configured to send all non-local mail to a different SMTP server. Such a destination SMTP server is commonly referred to as a relay or smart host. You can set this relay host from the administration console.
A common use case for a relay host is when an ISP requires that all your email be relayed through designated host, or if you have some filtering SMTP proxy server.
In the administration console, 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.
Important: Use caution when setting the relay host to prevent mail loops.
MTA-LDAP Integration
The Zimbra LDAP directory service is used to look up email delivery addresses. The version of Postfix included with Zimbra is configured during the installation of the Zimbra Collaboration Suite to use the Zimbra LDAP directory.
Account Quota and the MTA
Account quota is the storage limit allowed for an account. Email messages, address books, calendars, tasks, Documents notebook pages and Briefcase files contribute to the quota. Account quotas can be set by COS or per account.
The MTA attempts to deliver a message, and if a Zimbra user’s mailbox exceeds the set quota, the Zimbra mailbox server temporarily sends the message to the deferred queue to be delivered when the mailbox has space. The MTA server’s bounce queue lifetime is set for five days. the deferred queue tries to deliver a message back to the sender. You can change the default through the CLI zmlocalconfig, bounce_queue_lifetime parameter.
Note: To permanently have messages bounced back to the sender, instead of being sent to the deferred queue first, set the server global config attribute zimbraLmtpPermanentFailureWhenOverQuota to TRUE.
You can view individual account quotas from the Administration Console Monitoring Server Statistics section.
MTA and Amavisd-New Integration
The Amavisd-New utility is the interface between the Zimbra MTA and Clam AV and SpamAssassin scanners.
Anti-Virus Protection
Clam AntiVirus software is bundled with the Zimbra Collaboration Suite as the virus protection engine. The Clam anti-virus software is configured to block encrypted archives, to send notification to administrators when a virus has been found, and to send notification to recipients alerting that a mail message with a virus was not delivered.
The anti-virus protection is enabled for each server during installation. By default, the Zimbra MTA checks every two hours for any new anti-virus updates from ClamAV.
Note: Updates are obtained via HTTP from the ClamAV website.
Anti-Spam Protection
Zimbra utilizes SpamAssassin to control spam. 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.
Note: The DSPAM spam filter is also included with ZCS but the default is to not enable DSPAM. You can enable DSPAM by setting the localconfig attribute amavis_dspam_enabled to TRUE on the MTA servers.
 
Anti-Spam Training Filters
When ZCS is installed, the automated spam training filter is enabled and two feedback system mailboxes are created to receive mail notification.
Spam Training User to receive mail notification about mail that was not marked as junk, but should be.
Non-spam (referred to as ham) training user to receive mail notification about mail that was marked as junk, but should not have been.
For these training accounts, the mailbox quota is disabled (i.e. set to 0) and attachment indexing is disabled. Disabling quotas prevents bouncing messages when the mailbox is full.
How well the anti-spam filter works depends on recognizing what is considered spam or not considered spam (ham). The SpamAssassin filter can learn what is spam and what is not spam from messages that users specifically mark as Junk or Not Junk by sending them to their Junk (Spam) folder in the web client or via Outlook for ZCO and IMAP. A copy of these marked messages is sent to the appropriate spam training mailbox. The ZCS spam training tool, zmtrainsa, is configured to automatically retrieve these messages and train the spam filter.
The zmtrainsa script is enabled through a cron job to feed mail that has been classified as spam or as non-spam to the SpamAssassin application, allowing SpamAssassin to ‘learn’ what signs are likely to mean spam or ham. The zmtrainsa script empties these mailboxes each day.
The ZCS default is that all users can give feedback in this way. If you do not want users to train the spam filter, you can modify the global configuration attributes, ZimbraSpamIsSpamAccount and ZimbraSpamIsNotSpamAccount, and remove the account addresses from the attributes. To remove, type as:
zmprov mcf <attribute> ‘’
When these attributes are modified, messages marked as junk or not junk are not copied to the spam training mailboxes.
Initially, you may 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 these mailboxes. In order to get accurate scores to determine whether to mark messages as spam at least 200 known spams and 200 known hams must be identified.
The zmtrainsa command can be run manually to forward any folder from any mailbox to the spam training mailboxes. If you do not enter a folder name when you manually run zmtrainsa for an account, for spam, the default folder is Junk. For ham, the default folder is Inbox.
Protecting Alias Domains From Backscatter Spam
A milter that runs a Postfix SMTP Access Policy Daemon that validates RCPT To: content specifically for alias domains can be enabled to reduce the risk of backscatter spam.
Note: See the Zimbra wiki article about creating Domain Alias, Managing Domains at http://wiki.zimbra.com/index.php?title=ManagingDomains. To learn about the Postfix Policy Daemon, go to http://www.postfix.org/SMTPD_POLICY_README.html.
This functionality is enabled using the CLI, zmlocalconfig.
1.
zmlocalconfig -e postfix_enable_smtpd_policyd=yes
2.
3.
zmprov mcf +zimbraMtaRestriction "check_policy_service unix:private/policy"
4.
Restart, type postfix start
The policy daemon runs after you set the bits in steps 1 and 3 above and then restart Postfix. The postfix_policy_time_limit key is because the Postfix spawn (8) daemon by defaults kills its child process after 1000 seconds. This is too short for a policy daemon that may run as long as an SMTP client is connected to an SMTP process.
Disable Postfix Policy Daemon
To disable the Postfix Policy Daemon, type the following:
1.
2.
3.
4.
Restart, type postfix start
Turning On or Off RBLs
RBL (Real-time black-hole lists) can be turned on or off in the Zimbra MTA from the Zimbra CLI.
The three RBLs that are enabled during installation are the following:
You can set the following, in addition to the three above:
To turn RBL on:
1.
2.
Enter zmprov gacf | grep zimbraMtaRestriction, to see what RBLs are set.
3.
zmprov mcf zimbraMtaRestriction [RBL type]
To add all the possible restrictions, the command would be
zmprov mcf zimbraMtaRestriction reject_invalid_hostname zimbraMtaRestriction reject_non-fqdn_hostname zimbraMtaRestriction reject_non_fqdn_sender zimbraMtaRestriction “reject_rbl_client dnsbl.njabl.org” zimbraMtaRestriction “reject_rbl_client cbl.abuseat.org” zimbraMtaRestriction “reject_rbl_client bl.spamcop.net” zimbraMtaRestriction “reject_rbl_client dnsbl.sorbs.net” zimbraMtaRestriction “reject_rbl_client sbl.spamhaus.org” zimbraMtaRestriction “reject_rbl_client relays.mail-abuse.org”
Note: Quotes must be added to RBL types that are two words.
 
Receiving and Sending Mail through Zimbra MTA
The Zimbra MTA delivers both 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.
In order to send and receive email, the Zimbra MTA must be configured in DNS with both an A record and a MX Record. For sending mail, the MTA use 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. Even if a relay host is configured, an MX record is still required if the server is going to receive email from the internet.
Zimbra MTA Message Queues
When the Zimbra MTA receives mail, it routes the mail through a series of queues to manage delivery. The Zimbra MTA maintains four queues where mail is temporarily placed while being processed: incoming, active, deferred and hold.
Incoming.
The incoming message queue holds the new mail that has been received. Each message is identified with a unique file name. Messages in the incoming queue are moved to the active queue when there is room in the active queue. If there are no problems, message move through this queue very quickly.
Active.
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 or moved to another queue.
Deferred.
Message that cannot be delivered for some reason are placed in the deferred queue. The reasons for the delivery failures is 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. The message is bounced back to the original sender. The default for the bounce queue lifetime is 5 days. You can change the default MTA value for bounce_queue_lifetime from the zmlocalconfig CLI.
Hold.
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.
Corrupt.
The corrupt queue stores damaged unreadable messages.
You can monitor the mail queues for delivery problems from the administration console. See “Monitoring Mail Queues” .

Zimbra MTA

Table of Contents Previous Next Index
ZCS Administrator's Guide, Open Source Edition 5.0 (Rev 5.0.19 September 2009)
Copyright © 2009 Zimbra Inc.