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:
•
|
Postfix MTA, for mail routing, mail relay, and attachment blocking
|
•
|
Clam AntiVirus, an antivirus engine used for scanning email messages and attachments in email messages for viruses
|
•
|
SpamAssassin and DSPAM, mail filters that attempt to identify unsolicited commercial email (spam), using a variety of mechanisms
|
•
|
Amavisd-New, a Postfix content filter used as an interface between Postfix and ClamAV / SpamAssassin
|
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 the following figure. 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
*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
|
•
|
Attachment blocking
|
•
|
Relay host configuration
|
•
|
Postfix-LDAP integration
|
•
|
Integration with Amavisd-New, ClamAV, and Spam Assassin
|
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. 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 rejects the message as mailbox is full and the sender gets a bounce message. You can view 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 during installation. You can also enable or disable virus checking from Global Settings on the administration console. 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
SpamAssassin and DSPAM are spam filters bundled with ZCS. When ZCS is installed, spam training is automatically enabled to let users train spam filters when they move messages in and out of their junk folders.
The SpamAssassin default configuration for ZCS is as follows:
•
|
zimbraSpamKillPercent: Spaminess percentage beyond which a message is dropped. Default kill percent at 75%. Mail that is scored at 75% is considered spam and is not delivered. SpamAssassin score of 20 is considered 100%. 75% equates to a spam score of 15.
|
•
|
zimbraSpamTagPercent: Spaminess percentage beyond which a message is marked as spam. Default tag percent at 33%. Mail that is scored at 33% is considered spam and is delivered to the Junk folder. Since a SpamAssassin score of 20 equates to 100%, the zimbraSpamTagPercent would equate to a spam score of 6.6.
|
A Subject Prefix can be configured so messages considered as spam are identified in the subject line as tagged as spam. When a message is tagged as spam, the message is delivered to the recipient’s Junk folder.
You can change these settings from the administration console, Global Settings Anti-Spam tab.
Note: ZCS configures the spam filter to add 0.5 to the Spamassassin score if DSPAM marks the message as spam and deduct 0.1 if DSPAM does not label it as spam.
Anti-Spam Training Filters
When ZCS is installed, the automated spam training filter is enabled and two feedback 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 (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. The SpamAssassin filter can learn what is spam and what is not spam from messages that users specifically mark as Junk from their web client toolbar or Not Junk from the web client Junk folder. A copy of these marked messages is sent to the appropriate spam training mailbox.The Zimbra 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.
By default 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 spam/ham account addresses from the attributes. To remove, type as:
Restart the Zimbra services, type zmcontrol stop and then zmcontrol start.
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. To send a folder to the spam training mailbox, type the command as:
To send the to the non-spam training mailbox, type:
Password is not needed in 4.5.6+ see CLI_zmtrainsa
Turning On or Off RBLs
See Customizing the MTA for current information
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 [B_app-glossary.16.1.html#1037278 A record] and a [B_app-glossary.16.1.html#1021370 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.