How email sent in Zimbra?

Demystifying the Art of Sending Emails in Zimbra! Discover the seamless steps and hidden gems to navigate the Zimbra email sending experience effortlessly, making communication a breeze.

Electronic mail fastened as an (Email, e-mail, E-mail etc.) a procedure of switching messages between people using electronic devices.

Some early email system requested the sender and the receiver to both be online at simultaneously in common with immediate massaging. Today’s email system set up on a store-and-forward model. Email server accepts, forward, deliver and store the messages.

The “Zimbra” email collaboration suite has more than 500 million trusted users worldwide. It is the leading open source for enterprise email solution and the most desired substitute to Microsoft exchange.

At silent infotech provides you consulting, implementation and migration service with the support of Zimbra mail suits.

How Did Email send in Zimbra?

The Zimbra MTA(Mail Transfer Agent) sends both incoming and outgoing mail messages. For outgoing mail, Zimbra MTA manages the destination of the receiver address.

In the localhost, the messages moved to the Zimbra server for delivery while in the remote mail server Zimbra MTA must build a transmission method to transfer the message to the remote host.

For incoming emails, MTA must be able to recognize the connection request from the remote mail server and receive messages for the local users.

To send and receive a message the Zimbra MTA must be built in DNS(Domain name system) with both “A-record” & “Mx-record”.

A-record: It is the IP Address for Zimbra server.

Mx-record (mail exchange): Mx record is an entry in a domain name that recognizes the mail server which is responsible for handling emails for the respective domain name.

For sending an email the MTA use DNS to transfer hostnames and email routing information.

Zimbra MTA implementation:

The Zimbra MTA collects emails from SMTP(Simple Mail Transfer Protocol) and tracks each message using LMTP (Local Mail Transfer Protocol) to the correct Zimbra mailbox server.

The Zimbra mailbox server includes the following program:

  • Build the postfix MTA for mail routing, mail relay, and the attachment blocking.
  • For email messages and attachment scanning, zimbra mail server uses the calm antivirus and antivirus engine.
  • A mail filter “Spam Assassin” used to identify unrequested commercial email using various mechanism.
  • Zimbra mail server uses the new postfix content filter “Amavisd” to interface between postfix and Spam Assassin.

SMTP Authentication:

SMTP authentication allows recognized mail clients from exterior networks to relay messages through the Zimbra MTA. The User Id and password is sent to the MTA when the SMTP client sends mail to the MTA can authenticate if the user is to relay email.

User Authentication is procured through the Zimbra LDAP directory server over the Microsoft active directory server.

The user can enable the controls in the executor consol so that messages are not accepted by postfix when other unrecognized behavior is displayed by incoming SMTP client. This protections are fixed up against spam sender.

Zimbra MTA queue:

Zimbra MTA fetches mail, it detours the mail wound up a series of queues to regulate the delivery. The Zimbra MTA preserve four rows where mail is transiently placed while being processed: incoming, active, deferred and hold.

Incoming: The incoming message row clutches the new mail that has been received. Each message is determinate with a particular file name. Messages in the incoming queue are dragged to the active queue when there is room in the active queue. If there are no complications, message shift through this queue very expeditiously.

Active: The active message row holds messages that are ready to be sent. The MTA fixes a border to the number of messages that can be in an active row at simultaneously. Here messages are conveyed to and from the anti-virus and anti-spam filters before being dispatched to another row.

Deferred: Message that cannot be conveyed for some limits is implanted in the deferred row. This row is scanned frequently to resend the message. If the message cannot be sent after the set number of delivery attempts, the message fails and the message is bounced back to the original sender.

Hold: The hold message row collects mail that could not be refined. Messages stay in this row until the executor moves them. No cyclic delivery pursuits are formed for messages in the holding row.

Corrupt: The corrupt Row stores flubbed unreadable messages.


in Odoo