"How Email Works" Introduction to Sun Messaging Server
By jhawk on Aug 28, 2007
This week, I am teaching in Bangalore, India. One of the presentations which I'm giving is a "Basic Functional Overview of Communications Suite." Many of us who have been working with Communications Products for over a decade sometimes find ourselves going too deep into the technical aspects of our fields. My intention of this presentation was to provide a "basic baseline introduction" to how "email works".
This write up is a basic introduction. It does avoid most of the more complicate configurations and mechanisms which are part of the Sun Java Messaging Server. The key objective is to understand "how email works" from a basic "black box" model. In the up and coming posts, I'll start getting more complicated into the internals of the Messaging Server and the other components of the Sun Java Communications Suite.
What does Messaging Server allow Users to do?
The Messaging Server allows users to interact with their email message data in three different manners:
- Users may write an email, and then send it to someone(s).
- Users may receive emails from others.
- Users may access their Mailbox
The Sun Java Messaging Server Key Components:
• Message Transport Agent (MTA)
• Message Store Database
• Message Access Services:
• IMAP / POP3
• WebMail Access for Communications Express (separate product)
The above imagine simplifies the Messaging Server into these three components.
Messages are delivered into the Messaging Server via the MTA. The MTA is the SMTP Server which accepts the email message and then route the message to it's destination. The destination for the email could be either the Message Store or to another server somewhere out over the network.
The Message Store is a Sun private database, which stores user's mailboxes and message data.
Users access their mailboxes via either IMAP, POP3 or through Webmail.
A User Decides to Send an Email
Users write their emails using any of the popular email clients out on the market. These email clients could include Mozilla/Thunderbird, Apple Mail, Outlook Express, or any other IMAP-based email application. Once the email is ready, the user would click the "SEND" button.
The "SEND" button allows the email application to connect with the MTA. The client connects to the MTA using the SMTP protocol.
On the connection to the MTA, the client will send the message over the network to the MTA. The MTA would then store the message in the Message Queue Disk and release the client connection. The message stored on the queue will then be read and the address of the message will be evaluated by using information stored in the Sun Java Directory Server using LDAP.
At this point, the MTA will attempt to deliver the message to one of three places:
- Into a User's Mailbox
- Into another Messaging Server
- Into another site on the Internet (note for security.. it is recommend that the MTA forward the message to a "smarthost" MTA to handle the message delivery over the Internet)
It is important to note that once the message is on the Message Disk Queue, and the MTA has responsibility of the message. We guarantee this responsibility by committing the message to disk. It is this commitment which provides the first clue into a our first performance limitation. We write all MTA data to a disk queue, and we therefore are bounded by the disk i/o performance of that disk system. We also need to ensure that the disk system is highly available through RAID. (Typically RAID 0+1 or RAID 5.)
Postal Service Example.. An example of this would be a letter that you drop into a postal mailbox. If you drop a letter of at the Post Office, you are assuming that the Postal Service will mail the message to the destination. You will not expect the message to get lost.
The MTA will not remove the message from the Message Disk Queue until a successful delivery. If a delivery attempt fails, it will keep trying. If it fails a final time, the message will be HELD on the disk queue and a notification sent back to the sender. The MTA logs will record the whole history.
The MTA will attempt to deliver the message in one of three possible ways:
- Message is Deposited into the User's Mailbox on the Message Store
- Message is Sent to another MTA Server on the Same Local Network
- Message is sent to the Internet by first sending to the smarthost.
The Smarthost MTA sits between the Messaging Server inside the protected network and the Internet. Typically this would be in an area outside the internal network. The Smarthost would evaluate the message address by domain name. Using DNS, the MTA would attempt to identify the DNS MX Record and A Record for the destination of the email. It would then attempt to deliver the message to the host of that IP Address using SMTP.
User Receives an Email
An email sent to a user on the Message Store. In the case of the message arriving from the Internet, the email sender would address the email to "firstname.lastname@example.org". The email sender's MTA would look up "siroe.com" in DNS and find either an MX record or an A record for this site.
The Inbound MTA for the site may be configured to detect SPAM or Viruses. In this case, the message will be sent to a anti-spam/anti-virus verdict engine (such as Cloudmark or Symantec Brightmail). If the email passes, it is evaluated for message routing. The email address is evaluated in the Directory Server. If the email address is valid, it is then sent to the user's mailbox host (mailboxb).
User Access their Mailbox
If a person wishes to access their email, they would use their email client. These clients, such as Mozilla Thunderbird or Apple Mail, connect to the mailbox using the IMAP protocol. In some cases, ISPs would limit access to POP3 protocol.
The email client would connect to the Sun Messaging Server's Mail Multiplexor Proxy (MMP). The MMP would accept the user's email credentials (their username and password) and validate their login using the Directory Server. Should the authentication be successful, the MMP would then identify the user's backend Message Store server. The MMP would then connect to this backend Message Store on the user's behalf. The user can then access their mailbox data.
The value of the MMP is that it provides 1) Security and 2) Scalability. Security is improved by the use of the MMP by isolating the Message Store from the end-users. This helps to prevent unauthorized access (hacking) into the Message Store server data. Scalability (as seen in the picture below) is improved through Horizontal Scalability. This means that the architecture can grow by adding additional MMPs and backend Message Store servers.
I hope this information is informative for anyone curious on how "email works." Specifically, how email works with our Sun Java Messaging Server. In my next post, I'm going to describe how "Calendar Services Work" using our Sun Java Calendar Server.