Troubleshooting Course Content Rough Drafts-How Does Email Work
What is e-mail?
Often referred to as "e-mail", this term is frequently used or associated with the discussion of not only actual "mail" composition and retrieval, but is also used in the explanation of different protocols, standards, and architecture(s) associated with the electronic creation, submission, and retrieval of electronic messages.
We can see how "e-mail" is defined below;
e-mail: noun messages distributed by electronic means from one computer user to one or more recipients via a network. verb send an e-mail to (someone).
In this training unit, we'll look at how e-mail came about, the industry standards and protocols used today as well as the architecture and vernacular of how e-mail works within your Zimbra deployment.
The origin of e-mail and industry standard protocols
History and Background:
Dating back to the early 1960's, the first form(s) of e-mail sprouted up in the form of services like AUTODIN, a legacy data communications service developed by the U.S. Department of Defense, and MIT's CTSS Mail, where remote terminals could dial-in to share and store files on a central disk(s). Informal methods of using these type(s) of systems later evolved to pass messages between terminal users.
The first "e-mail" systems used different features and ran on different systems that were not compatible with each other; coined "host-based e-mail systems". Most of these systems required users to be logged into in the same "terminal" or "mainframe" in order for communication to occur.
Subsequent to "host-based e-mail systems" came "LAN e-mail systems", those that ran on a local area network, which still required users to be logged into the same infrastructure. Some examples of "LAN e-mail systems" include Microsoft Mail and Lotus Notes. Further evolution allowed for these types of systems to communicate outside of an organization, assuming the same email system and proprietary protocols were in use.
Circa the 1970's, more of what we see in use today was in the origin of development. It was essential that as organizations grew larger and as technology advanced, those methods of mail exchange between remote sites or other organizations provided an avenue to transport messages of text globally via telecommunication links.
Internet Message Format:
Alas, through RFC, an "Internet Message Format" was derived and published by Qualcomm. RFC5322 is not the first RFC to establish an "IMF", albeit it's the most current.
This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs.
You can read more about this RFC here; RFC5322.
Beyond Text...Multimedia Attachments (MIME):
Further expansion led to "e-mail" that not only included text, but multimedia attachments as well. Established in RFC2045, through RFC2049, Multipurpose Internet Mail Extensions or "MIME" were derived.
Consisting of two major components, e-mail messages include both a "header" and a "body" section.
This section is structured into fields, such as From, To, CC, Date, Subject, and other information pertaining to the message. An example "header" section is shown below:
Received: from zimbra.server.com (LHLO zmail.zimbra.com) (10.137.27.36) by zimbra.server.com with LMTP; Sat, 31 Jan 2015 01:05:53 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by zmail.zimbra.com (Postfix) with ESMTP id 7970049F7 for <firstname.lastname@example.org>; Sat, 31 Jan 2015 01:05:53 -0800 (PST) by localhost (zimbra.server.com [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id rPQ4Stk2X1Sy for <email@example.com>; Sat, 31 Jan 2015 01:05:52 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by zmail.zimbra.com (Postfix) with ESMTP id 3E2384A4C for <firstname.lastname@example.org>; Sat, 31 Jan 2015 01:05:52 -0800 (PST) Received: from zmail.zimbra.com ([IPv6:::1]) by localhost (zimbra.server.com [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id 24DhbFXYNwUn for <email@example.com>; Sat, 31 Jan 2015 01:05:51 -0800 (PST) Received: from zimbra.server.com (localhost [127.0.0.1]) by zmail.zimbra.com (Postfix) with ESMTP id E388C4A46 for <firstname.lastname@example.org>; Sat, 31 Jan 2015 01:05:51 -0800 (PST) Date: Sat, 31 Jan 2015 01:05:51 -0800 (PST) From: admin <email@example.com> To: firstname.lastname@example.org Message-ID: <1205797309.15.1422695151122.JavaMail.email@example.com> In-Reply-To: <843455228.13.1422695143436.JavaMail.firstname.lastname@example.org> Subject: Re: ZCS Backup Report: SUCCESS MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Auto-Submitted: auto-replied (zimbra; vacation) Precedence: bulk X-Mailer: Zimbra 8.0.6_GA_5922 Thread-Topic: ZCS Backup Report: SUCCESS Thread-Index: FP1J+yf4TQ4duzXiVDb92nMu0M2BmQ==
Included in the body is basic content in form of unstructured text; possible containing a signature block at the end. The content of this section would be comparable to the "body" of a regular letter.
An example "body" section can be seen below:
Hello, During the Zimbra Admin Training class, we will be installing Zimbra on Amazon EC2 instances. Sincerely, Your Zimbra Training Administrator Zimbra | Community & Collaboration 1855 S Grant Street, Suite 200, San Mateo, CA 94402 USA
The Message Header Explained
Every message has only one header structured into fields. Every field has a name and a value as outlined in RFC5322.
A message header mustinclude the following fields:
•From: The email address, and optionally the name of the author(s). In many email clients not changeable except through changing account settings.
•Date: The local time and date when the message was written. Like the From: field, many email clients fill this in automatically when sending. The recipient's client may then display the time in the format and time zone local to him/her.
A message header should include the following fields:
•Message-ID: Also an automatically generated field; used to prevent multiple delivery and for reference in In-Reply-To: (see below).
•In-Reply-To: Message-ID of the message that this is a reply to. Used to link related messages together. This field only applies for reply messages.
Please refer to RFC3864 for elaboration on message header fields.
Simple Mail Transport Protocol
The Simple Mail Trasnport Protocol, more commonly known as "SMTP", is an internet standard for e-mail transmission, first established in RFC821 and later expanded to include "Extended SMTP" via RFC5321; the protocol most widely used today.
SMTP by default uses port 25 for mail submission. Secure SMTP, known as SMTPS, defaults to port 465 in legacy configurations and port 587 in more current configurations.
The default values in a Zimbra deployment are port 25 for SMTP and port 587 for SMTP over TLS (SMTPS).
SMTP: Server vs. Client
Zimbra architecture employs a server side application called Postfix, which is an open source Mail Transfer Agent (MTA), for sending and receiving messages. The implementation of Postfix included with a Zimbra deployment is customized and not interchangeable with "standard" or "vanilla" Postfix installation(s).
Zimbra translates Postfix configuration variables for both users and server values into LDAP attributes and local configuration variables (zmlocalconifg read from /opt/zimbra/conf/localconfig.xml). It's important to keep in mind that any changes made to Postfix, outside of the Zimbra local configuration or modification of LDAP variables will not remain in place post upgrade.
The following files are customized for Zimbra's Postfix installation:
•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.
Despite the primary focus of SMTP protocols being related to server side operations, Client applications can also use SMTP for the submission of mail to an MTA server, or relay. In contrast, Client applications would use POP or IMAP for the retrieval of mail.
Zimbra: SMTP vs. LMTP:
While SMTP is employed by Zimbra to communicate and send mail to both Zimbra and non-Zimbra mail environments, Zimbra also uses another protocol, LMTP (Local Mail Transfer Protocol), to route messages to the appropriate mailstore.
Postfix performs the Zimbra mail transfer and relay of mail. Postfix receives inbound messages via SMTP (or SMTPS), and hands off the mail message(s) to the Zimbra server via LMTP, as shown in the following figure. The Zimbra MTA can also perform anti-virus and anti-spam filtering.
Zimbra Mail Processing:
Mail is submitted to the Zimbra Server (Mail Submission Agent) via User Agents (UA's) on either port 25 (SMTP) or port 587 (SMTP w/TLS), traditionally. From there, messages are routed from the Mail Submission Agent to the Zimbra MTA (Mail Transfer Agent). Both submission and transfer occur within the same application, albeit use different operational procedures.
As we previously discussed, mail is routed from the Zimbra back-end (mailstore) to the Zimbra MTA with the LMTP protocol. Once the mail is received by the Zimbra MTA, SMTP is used to route the messages for both local and external delivery. All mail, whether internal or external, is routed through the Zimbra MTA; this happens to ensure that the archive function (if licensed) works accurately to save a copy of every message transmitted through the Zimbra MTA, regardless of whether a message was internal or external.
During the receipt of mail, the Zimbra MTA uses a series of queues (envision a series of buckets) to manage delivery. The Zimbra MTA maintains four queues, where mail is placed temporarily during processing; incoming, active, deferred, and hold.
The qmgr(8) daemon maintains the following queues:
incoming Inbound mail from the network, or mail picked up by the local pickup(8) daemon from the maildrop directory.
active Messages that the queue manager has opened for delivery. Only a limited number of messages is allowed to enter the active queue (leaky bucket strategy, for a fixed delivery rate).
deferred Mail that could not be delivered upon the first attempt. The queue manager implements exponential backoff by doubling the time between delivery attempts.
corrupt Unreadable or damaged queue files are moved here for inspection.
hold Messages that are kept "on hold" are kept here until someone sets them free.
How Zimbra Receives Mail:
The diagram above shows how Zimbra receives mail from the "outside world", or Internet. The message originates from a senders user agent. A sender's UA is either a web or desktop Client used in the composition of mail (i.e. Zimbra Web Client, Zimbra Desktop, Outlook). Once composed, the users message is routed to an MTA (Mail Transfer Agent). The MTA is responsible for DNS lookups and for locating the receiving MTA, which resides elsewhere on the Internet.
The communication that occurs between the originating and receiving MTA uses the Simple Mail Transport Protocol. Once the Zimbra MTA (Postfix) receives the message from the Internet, an LDAP lookup is performed to determine what mail host the Zimbra user resides on. The 'zimbraMailHost' attribute set for each account is responsible for providing the users store. Once a users store is identified, messages make their way from the Zimbra MTA to the mailstore via LMTP.
Click here for more information on the Zimbra MTA
DNS and MX Records
Proper configuration of both DNS and MX records is essential in order for Zimbra to send and receive mail on the internet. As well as for a successful installation of your Zimbra deployment. Many Zimbra services rely on DNS to lookup and resolve host names both internally and externally.
Before any Zimbra installation occurs, appropriate 'A' and 'MX' records must be configured for your Zimbra hostname(s). The same holds true whether you configure a service such as 'bind' or 'named' to handle name resolution, or if you use an existing DNS service already deployed in your environment.
The A Record:
An "A" record is configured for each host that resides in your Zimbra deployment. An "A" record tells the name service the fully qualified domain name and IP of a server. This information is used to internally and externally to identify where servers are located. Often, split DNS is required should your server(s) not be resolvable from outside of your network.