ZCS Administrator's Guide 7.2.3
ZCS Administrator's Guide 7.2.3
Open Source Edition


Zimbra MTA > MTA Functionality

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:
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 a 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 ZCS 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, and Briefcase files contribute to the quota. Account quotas can be set by COS or per account.
How message delivery is handled when a Zimbra user’s mailbox exceeds the set quota is set either by the COS or for individual accounts. The MTA can be configured to either send the message to the deferred queue or send the message to the mailbox, even if the quota has been exceeded.
*
The MTA server’s bounce queue lifetime is set for five days. The deferred queue tries to deliver a message until this bounce queue lifetime is reached before bouncing the message back to the sender. You can change the default through the CLI zmlocalconfig, bounce_queue_lifetime parameter.
Note:
*
When this attribute is set to TRUE, a mailbox that exceeds its quota is still allowed to receive new mail and calendar invites.
This quote bypass is only implemented for messages. All other mail items are still affected by the quota.
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 ZCS as the virus protection engine. The anti-virus protection is enabled for each server and a global virus quarantine mailbox is created during installation.
The Clam anti-virus software is configured to quarantine messages that have been identified as having a virus to the virus quarantine mailbox. An email notification is sent to recipients letting them know that a message has been quarantined. The message lifetime for this mailbox is 30 days.
By default, the Zimbra MTA checks every two hours for any new anti-virus updates from ClamAV.
Note:
Anti-Spam Protection
SpamAssassin, a mail filter that attempts to identify unsolicited commercial email (spam) with learned data stored in either the Berkeley DB database or a MySQL database.
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. The ZCS default is to use data in the Berkeley DB database.
SpamAssassin can alternatively be configured to use a MySQL-backed database for spam training. To use this method, set zmlocalconfig antispam_mysql_enabled to TRUE on the MTA servers. When this is enabled, Berkeley DB database is not enabled. See the Scalable Anti-Spam Using Spamassassin and MySQL wiki article at wiki.zimbra.com.
Note:
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 spam, but should be.
*
Non-spam (referred to as ham) training user to receive mail notification about mail that was marked as spam, 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 spam or not spam by sending them to their junk 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.
In order to correctly train the spam/ham filters, when ZCS is installed, spam/ham cleanup is configured on only the first MTA. The zmtrainsa script is enabled through a crontab 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.
Note:
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 spam or not spam 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 Spam. 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:
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
Email Recipient Restrictions
RBL (Real-time black-hole lists) can be turned on or off in the Zimbra MTA from the administration console or using the Zimbra CLI. From the administration account go to the Global Settings>MTA tab.
For protocol checks, the following three RBLs can be enabled:
*
*
*
You can set the following, in addition to the three above:
*
*
*
*
*
*
As part of recipient restrictions, you can also use the reject_rbl_client <rbl hostname> option. In the Global Settings>MTA>DNS checks section on the administration console specify the list of RBLs. For a list of current RBL’s, see the Comparison of DNS blacklists article at http://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists.
Adding RBLs using the CLI
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:
Copyright © 2013 VMware Inc.