How Email Works (part 2): Intro to the Sun MTA

Last week.. We covered the "high level" explanation of "How Email Works." If you like, I suggest you read my last post before you read this.

See my last post in this series.. Introduction to Sun Messaging Server : How Email Works

This week we are looking at the MTA. The Mail Transport Agent (MTA) is a critical part of the Sun Java Messaging Server. The MTA's function is to transport messages to either other computers or to user applications. The question is now, how does the message go from one MTA to another MTA.

A Quick Review from Last Time..

Nearly all of us have written a email in our day to day life. When we click the "send" button on our email software, the message disappears and "hopefully" appears in someone else's email mailbox. On the setup of our Email Software, we are asked for an SMTP Server. The SMTP Server (or MTA-Outbound) provides (#1) the initial acceptance of the message from the author of the email.

Once the email has been accepted by the MTA-Outbound. The MTA will then evaluate the message recipient's address. If the recipient is not local to the MTA, the MTA will attempt to deliver the message to another site.

The recipient address of "" has two parts. The first is the user part which is "jonathan." The second part is the domain part which is the "" If the domain part does not equal the MTA Server's local settings, it then decides that the message must be delivered to another site (#2). The address of the site is looked up using the MX DNS Record to find the IP Address of that site. This allows the MTA-Outbound to create an SMTP Connection to the Remote Site's MTA-Inbound.


Figure 1 - Example of a User from one site sending an email to a User at another Site

The MTA-Inbound handles all incoming requests (#3) from the Internet. It takes the SMTP connections, and validates the email message's "user address" as a valid user. If the user is valid, it writes the message to its internal message queues. If the user is invalid, it may reject the message. In the Sun Java Messaging Server, we validate the email user addresses using our Sun Java Directory Server.

The MTA must place messages "in transit" in a message queue. The purpose of this message queue is to protect the message from potential system failures, such as loss of power. Only when the message is successfully committed to a message queue will the MTA confirm that it accepted the email message. The example here is.. When you drop off a letter at the local Post Office, you have a reasonable assumption that the Post Office will accept responsibility of the delivery of that message.

After the message has been written to a Message Queue, the MTA will then dequeue the message. The message will be dequeued to either 1) deliver to another site or 2) be delivered into the Message Store. In this case, the MTA-Inbound will evaluate the email address in the Directory Server, and then deliver the message to another server. The Sun Java Messaging Server will deliver to local Messaging Servers using Sun's version of LMTP.

Messaging Server Internals

Now let's look at how the Sun Java Messaging Server does the above from the "inside." (Figure 2) The MTA is a major portion of the Messaging Server. This is because it implements a "channel-based" architecture. The channel-based architecture allows the MTA to provide extensive processing and routing of messages that pass through its system.

Figure 2 - Overview of the Internals of the Sun Java Messaging Server

The above picture (Figure 2) provides the highlights of the Messaging Server. The key components of the Messaging Server are the MTA (discussed in this article), the Message Store, and the Access Services (IMAP, POP3, and WebMail).


Figure 3 - Initial state where the MTA's Dispatcher starts SMTP_SERVER Processes

For our discussion, we can consider the initial state of the MTA to look like Figure 3. The Dispatcher (a maintenance process) will start up a number of system processes (SMTP_SERVER) to listen to TCP/IP ports. In this case, the processes are setup to listen to port 25 (SMTP) and port 443 (SMTP w/ SSL).

Figure 4 - Incoming SMTP Connections connect to the SMTP_SERVER Processes

As other servers and email programs connect to the MTA using SMTP, the multiple connections are handled by the SMTP_SERVER processes. As a connection is established, the client will attempt to start a SMTP session. This SMTP session includes the author's email address (FROM address), the receiver's address(es) (TO address), and the actual email itself.


Figure 5 - SMTP Session provides addressing information. This is evaluated by the Mappings Table and Rewrite Rules.

Once the FROM address and the TO address is given, the MTA will then assign channels to each of these addresses. These will be the SOURCE Channel and the DESTINATION Channel. The MTA will also track the SOURCE Channel of the connection's IP Address. This process of Channel assignment is based on the rewrite rules provided in the MTA's configuration files. (imta.cnf)

Figure 6 - Channel's Architecture. Slave Process (enqueues) messages to a Queue. Master Process (dequeues) is assigned to service (dequeue) a Message Queue.

The above figure 6 shows an example "channel-based" architecture. The slave process is the SMTP_SERVER which enqueues the message into the message queue.

Figure 7 - Evaluation of addresses assign the message to be written to disk on a Message Queue file system.


Figure 8 - Messages in the Message Queue are then dequeued and processed by a Master Process.

Additional Reading:
1. Sun Java System Messaging Server 6.3 Administration Reference,

Technorati Tags: , , , , ,


Post a Comment:
Comments are closed for this entry.

I'll be writing about topics that would interest users and developers of Sun Java Communication Suite.


« June 2016