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

Zimbra MTA > Receiving and Sending Mail through Zimbra MTA

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.
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.
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.
Messages that cannot be delivered for some reason 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. The message is bounced back to the original sender. The default for the bounce queue lifetime is five days. You can change the default MTA value for bounce_queue_lifetime from the zmlocalconfig CLI.
Before the bounce queue lifetime sends the message back to the sender, senders can be notified that the message they sent is in the Deferred queue and has not been delivered. This is set up from the zmlocalconfig CLI. The following attributes are configured to send a warning message to the sender:
postfix_delay_warning_time=0h.The time after which the sender receives the message headers of email that is still queued.
postfix_bounce_notice_recipient=postmaster. The recipient of postmaster notifications with the message headers of mail that the MTA did not deliver.
postfix_notify_classes=resource,software. The list of error classes that are reported to the postmaster.
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 Mail Queues on page 202.
Copyright © 2013 VMware Inc.