Eating Up E-Mail (TCP/IP) Part 2

Sharpening the Finer Points of Mail Servers

Table 13-1, a little earlier in this topic, simplifies the task of describing the mail process. For example, how does your snail mail post office know where the delivery office is? For most of us, the address of a letter contains a postal code that maps to a post office in a town or city. With e-mail, SMTP figures out how to communicate between the sender’s MTA and the recipient’s MTA.

SMTP has two options for sending e-mail from the source MTA to the destination MTA:

✓ The store-and-forward method

✓ MX (Mail Exchange) records from the Domain Name Service (DNS)

Transferring e-mail by way of store-and-forward

To understand the store-and-forward method, take a look at an example. Suppose that Sarah wants to send an e-mail message to her sister Emily. Here’s how the e-mail message is transferred from Sarah to Emily (as shown in Figure 13-6):

1. Sarah composes the message using her favorite mail user agent, or MUA.

2. When Sarah clicks Send, her MUA hands the message to an MTA on her network.

3. Sarah’s local MTA passes the message to an MTA on Emily’s network. SMTP defines how messages move from one MTA to the next.

4. Emily’s MTA receives the message and puts it in Emily’s mailbox. The simplest kind of mailbox in an e-mail system is a text file that stores all of a user’s messages.


5. After Sarah’s e-mail to Emily arrives, it sits in Emily’s mailbox until she checks her e-mail. (Knowing Emily, that’s about once a month.)

6. When Emily checks her e-mail, either POP3 or IMAP4 takes over and retrieves Sarah’s message from Emily’s mailbox.

MUAs that work with both POP3 and IMAP4 include Alpine, Apple Mail, Eudora, IBM Lotus Notes, Microsoft Outlook, Mozilla Thunderbird, Pegasus Mail, and many more. Whether POP3 or IMAP4 takes over depends on how Emily configures her e-mail client. Figure 13-6 shows you the big picture.

Lots of pieces work together to send e-mail.

Figure 13-6:

Lots of pieces work together to send e-mail.

Transferring e-mail by way of DNS MX records

Sending e-mail by using store-and-forward works well in smaller intranets. When a message is bound for the other side of the Internet, the message might have to do a lot of hopping from one MTA to another before it finally reaches its destination.

A more efficient way for MTAs to find out where to send e-mail works with special records in the DNS database. MX (Mail Exchange) records list the e-mail servers for a particular domain, such as example.com. The outbound (sending) MTA first checks to see whether the e-mail is being sent to a local address. If so, that’s great — the MTA only has to hand off the e-mail to the recipient’s MUA. However, if the message isn’t local, the outbound MTA starts to figure out the recipient’s address by using MX records from the DNS database.

The MX records in DNS define the e-mail servers for a particular domain.

Understanding How SMTP Works with MTAs

Simple Mail Transfer Protocol, or SMTP, is the part of the TCP/IP protocol suite that MTAs use to communicate with each other. Without SMTP, MTAs wouldn’t know how to send e-mail. SMTP defines how messages move from one computer’s MTA to another’s MTA, but not which path each message takes. A message can move directly from the sender’s computer to the recipient’s, or it can proceed through intermediary computers by using the store-and-forward process.

In the store-and-forward style, as each message travels through the network on its way to its destination, it can pass through any number of intermediate computers’ MTAs, where it’s briefly stored before being sent on to the next computer in the path. The process is sort of like a weary traveler stopping to rest occasionally before continuing the trip across the network galaxy.

SMTP is strictly about moving messages from one computer to another. Although SMTP doesn’t care about the content of an e-mail message, it limits the formatting attributes of the message. SMTP can transfer only text! It can’t handle fonts, colors, graphics, attachments, or any other of those fancy e-mail features that you know and love. The Multipurpose Internet Mail Extensions (MIME) standard was created to overcome this limitation. MIME encodes the deluxe features into plain old text, which SMTP transfers. So go ahead and send e-mail with sounds and pictures of your dog, for example.

MTAs also act as waystations for messages, by accepting messages not meant for them and forwarding the messages to their destinations or to another intermediary MTA. An MTA, which determines how to send messages to the appropriate recipient, sends messages to

✓ Other MTAs

✓ Mailboxes

✓ Other programs, such as spam filters, for advanced processing

Defining E-Mail Protocols

Figure 13-6 shows the protocols that are part of a complete e-mail system. Some protocols, such as POP3 and IMAP4, are optional. The following section, "Adding More Protocols to the Mix," describes protocols that are used when a mail message reaches its destination. The transfer protocols that deliver mail to its destination are described in this list:

✓ Domain Name System (DNS): A protocol, a service, an application, and a distributed database. The protocol and service translate server names into numeric IP addresses so that the e-mail can be shipped from computer to computer.

✓ Lightweight Directory Access Protocol (LDAP): Another part of the TCP/IP suite. It’s optional but can help you address your e-mail by letting your MUA look up e-mail addresses for people and groups.

✓ Simple Mail Transfer Protocol (SMTP): The TCP/IP protocol that MTAs all over the Internet use to communicate to send and deliver e-mail. SMTP might be "invisible," but it’s a hard worker. Without SMTP, there would be no way for an MTA to deliver e-mail to another MTA on another computer.

Adding More Protocols to the Mix

After SMTP hands off an e-mail message to the final destination MTA (which deposits it in the correct mailbox), the recipient controls what happens next. The e-mail environment often provides options for how and when recipients’ MUAs present messages for their reading pleasure (or not) and for where the messages are stored.

Because we’re talking about clients (MUAs) and servers (MTAs), there must be protocols — where there are protocols and servers, there are services!

Your mail server must give you a way to access the mail in your mailbox. These days, most mail server software gives you several choices, including these:

✓ Post Office Protocol, version 3 (POP3)

✓ Internet Message Access Protocol, version 4 (IMAP4)

✓ Hypertext Transfer Protocol (HTTP)

✓ Lightweight Directory Access Protocol (LDAP)

In most cases, these services are so tightly integrated with the mail server software that you can’t tell them apart.

POP3

By default, POP3 e-mail processing is offline. Your MUA connects to the POP3 server by using a valid username and password and then downloads all messages in your mailbox and deletes them from the e-mail server. This means you have to read e-mail on your local computer, but after POP3 downloads your e-mail to your computer, you can disconnect from the network, if you want.

If you read your e-mail from many different computers, you can also wind up with "puddles" of e-mail all over the place! Messages you read at work aren’t available at your home computer and vice versa. Fortunately, you can override the default behavior by configuring an option in your MUA to leave messages on the server until you explicitly delete them.

IMAP4

In contrast to POP3, the default for IMAP4 e-mail processing is online. Your MUA accesses the IMAP4 server and your mailbox as though it were on your local computer. With IMAP4, you keep e-mail on either the server or your local computer or both. You set the message storage options when you set up your MUA. You can read e-mail from your computer at home, your workstation at the office, and a PDA while on a business trip, all without moving messages off the server or transferring them between your various computers. You can scroll through the headers and download only the messages you want to be local.

Table 13-2 lists the differences between POP3 and IMAP4.

Table 13-2

POP3 versus IMAP4

Feature

POP3

IMAP4

Default storage location

User’s computer

Server

Default reading style

Offline

Online

TCP port number

110

143

Server overhead

Small

Large

Network connect time

Small

Depends; usually longer

Disk storage restrictions

Size of local drive

Possibility of disk quotas and limits

Ease of configuration

Simple

Complicated

Value for mobile

No

Yes

You must match your MUA’s protocol to that of the e-mail server with the MTA you’re connecting to. For example, a POP3 MUA cannot communicate with an IMAP4 server.

HTTP

If you read your e-mail with a Web browser, you’re using HTTP. It isn’t an e-mail protocol, but then your browser isn’t an e-mail client either. It works and we like it, so who cares?

LDAP

Lightweight Directory Address Protocol (LDAP) is another optional piece of an e-mail system that makes your MUA more user friendly. If your MUA works with LDAP, you may never need to type another e-mail address. Popular e-mail clients can all use LDAP. When you send a message, LDAP makes it possible for you to enter a name rather than an address for the recipient.

LDAP helps your MUA work with a directory service, which is simply a type of database that stores information — in the case of e-mail, information about people, including their e-mail addresses. Here’s how it works:

1. Rather than address,Sarah presses Ctrl+E (or chooses the EditOFindOPeople command).

2. Sarah selects a directory service from the Look In menu.

3. She fills in Emily’s name and clicks the Find Now box.

4. The MUA contacts the directory service by following LDAP rules and looks up Emily.

5. If the directory service finds multiple instances of people named Emily,

it tells the MUA, and the MUA gives Sarah a list of people named Emily to choose from. Sarah selects one and sends the message.

DNS and its MX records

Every MX record contains the name of the domain that the e-mail is being sent to, the priority for the record, and the hostname that receives e-mail for that domain. The MX record with the lowest preference is the first server to try. The following two records list the hosts that can deliver e-mail for example.com:

example.com MX 5 mailsrv1.example.com example.com MX 10 mailsrv2.example.com

Both mailsrv1 and mailsrv2 can accept e-mail for example.com, but mailsrv1 is the "preferred" server because it has the higher priority.

In the preceding section, Sarah wanted to send an e-mail message to her sister Emily. In Figure 13-7, Sarah’s message benefits from an MX record that specifies the e-mail server for Emily’s domain.

Sarah's MTA checks for the MX records that lead to Emily's mailbox.

Figure 13-7:

Sarah’s MTA checks for the MX records that lead to Emily’s mailbox.

Here are the steps for getting Sarah’s e-mail to Emily:

1. On her computer, Sarah writes the message in her MUA, specifies Emily’s e-mail address and clicks Send. The MUA puts the message in local storage for outbound e-mail and sends the stored message to Sarah’s e-mail server by using SMTP.

2. The MTA on Sarah’s e-mail server receives the message and puts it in local storage for outbound e-mail because the message isn’t intended for any user of that e-mail server. The server asks the DNS for information about eastmail.example.com.

3. The DNS server’s response includes the MX records for the entire example.com domain. They declare that this message to Emily can’t go directly to her e-mail server. It must go through the "front door," mail.

example.com.

4. The MTA on Sarah’s e-mail server sends the stored message to mail. example.com by using SMTP. The MTA on mail.example.com receives the message and puts it in local storage for outbound e-mail (messages it needs to send) because the message isn’t intended for any user of that e-mail server. This step represents store-and-forward in action!

5. The MTA on mail.example.com sends the stored message to Emily’s e-mail server by using SMTP. The MTA receives the message and puts it in Emily’s mailbox.

6. When Emily chooses to read her e-mail, her MUA retrieves the message from her e-mail server by using POP3 (or perhaps IMAP4) and puts it in local storage on Emily’s computer. The message may or may not be deleted from the server, depending on how Emily configures her MUA.

To discover the MX records that are registered for a domain, you need software that handles name server queries. The most common are dig, host, and nslookup. Here’s an example of using nslookup to find Apple Computer’s MX records:

tmp16-49

Next post:

Previous post: