Network Computingwww.networkcomputing.com

We will first take a look at the general procedures for sending and receiving a typical e-mail message and the technology involved at each step of the communication. After we have a good understanding of the basics, we will peer deeper into each step and discuss design decisions that you should consider. Next we will cover the configuration of your MTA and what capabilities it should have, followed by an examination of how you can use MTAs to integrate messaging systems from different networks and transports. When we are done, you will be able to investigate the role of an MTA in your network and whether or not it is being used in an efficient manner.

A Day in the Life of an E-Mail Message

Before we trace a typical e-mail message, we first need to delve into a little terminology. MTAs, as the name indicates, are responsible for transporting messages to and from their various hosts on the network. Delivery agents are responsible for delivering the message to the user when a user's mail client requests any new messages. So then is an MTA a mail server or something different? Actually, it can be either depending on the product you are talking about.

For a Windows NT-based system, an MTA is almost always integrated into the mail server solution along with a delivery agent. Products like Eudora WorldMail, Ipswitch's IMail and others contain both elements and work as one cohesive unit. Unix-based systems differ and sometimes have standalone MTAs, such as sendmail, smail or MMDF. These standalone MTAs work in conjunction with POP, IMAP and other delivery agents such as /usr/bin/mail.

For any typical mail message, there will be at least two mail clients. These are called MUAs (Mail User Agents), and there is one for the sender's host and at least one for the destination host. Some of the more popular MUAs are QUALCOMM Eudora Pro, MS Mail for PCs and Macintoshes as well as their text-based Unix counterparts, ELM, PINE and Mail. MUAs are primarily responsible for gathering all the information necessary for sending an e-mail message over the Internet.

When you send an e-mail message, your MUA first establishes a connection with your default mail server or MTA and sends a sequence of commands to it. These commands and their usage are outlined in the SMTP RFC 821 (and will be discussed shortly). Your MTA should be a well-known host and oftentimes is the same as your DNS server. Providing mail services should not be difficult for your users, who will definitely remember common host names.

Once the MTA has received a message, it then acts on it based on the destination address or addresses within the message. If a destination address is local to the MTA, the MTA will store the message and wait for an MUA to retrieve it. If a destination address is not local to the MTA, the MTA will either forward the mail message to the destination MTA, if known, or relay it to another MTA server that may be closer to the final destination. When the mail message finally arrives at the destination MTA, the message is again stored until the MUA of the destination host retrieves it.

Of course there is greater depth to the internal workings of this process at many different steps. Now we will begin to break down each step and any implementation and configuration decisions that may be needed.

Print This Page

E-mail this URL