I sometimes wonder how I would live without email. I use email to send memos to colleagues, to submit this column, and to hear from people who've read my books and articles. Email is great...unless you're responsible for making the system work. If your firm has a server on the Internet, you have probably struggled with setting up mail servers and clients. The phrases Simple Mail Transfer Protocol (SMTP), Post Office Protocol (POP), Authenticated Post Office Protocol (APOP), Internet Mail Access Protocol (IMAP), and Enhanced Simple Mail Transfer Protocol (ESMTP) might give you pause.
I recently set up the mail server for my new minasi.com domain. In doing so, I had to relearn a few lessons. To start, I looked for the earliest Request for Comments (RFC--a file that documents an Internet standard) relevant to email. I found RFC 722, which was released in September 1980. RFC 722 describes how to set up a system that lets Internet users send messages to one another, even when message recipients aren't at their computers.
In 1980, Internauts already knew how to transfer files via FTP. However, FTP file transfers are not the same as email messages, because they transmit information between computers, not users. In those days, most people who used computers shared multiuser machines on which as many as 2000 people had accounts. Those early computer users needed a method for sending messages to another person, rather than another machine. RFC 722 introduced what we now know as email by building on FTP to define SMTP.
Most Internet users in the early 1980s worked on terminals. When a person named Joe on a computer called andromeda.acme.com sent an email message to Jane on iguana.apex.com, andromeda's SMTP software looked up iguana's IP address (for example, 188.8.131.52) and attempted to open hailing frequencies to iguana's SMTP software. Then andromeda sent the message to Jane's mailbox on iguana. The next time Jane logged on to iguana and checked her mail, she received the message.
One of the most useful things about Internet mail, and most early Internet protocols, is that the protocol consists of English-like words. Because you can access the SMTP protocol from the keyboard and because the protocol consists of semimeaningful phrases, you can easily fire up a Telnet session and mimic an SMTP sender.
To practice sending SMTP messages, I connected to my Internet Service Provider's (ISP's) mail server via Telnet and sent myself a fake email from Bill Clinton. I connected to the mail server, access4.digex.net, with the command
telnet access4.digex.net 25
The 25 is a port number. When a computer receives an incoming email message, which is basically a bunch of bytes, the computer needs to know what to do with the message. Most computers run many programs at once; your Windows NT machines probably work simultaneously as print servers, file servers, and mail servers. Data that comes in over the Internet could be an email message, a request for information on a file server, a logon request, or another type of communication. Your computer uses the port number to determine where to place incoming data. Port numbers range from 1 to 65,535. Some port numbers are widely accepted--SMTP's port, 25, is a well-known port number.
If SMTP software on a computer named andromeda wants to communicate with SMTP software on a computer named iguana, andromeda can't just ask to communicate with IP address 184.108.40.206. Nor can andromeda just ask to communicate with SMTP software. Andromeda must ask to communicate with port 25 on 220.127.116.11. Together, a port number and an IP address define a unique program running on a unique machine. The combination of an IP address and a port number is a socket. Telnet lets me connect to a particular socket when I type
The ability to telnet comes in handy when you're setting up SMTP mail clients. If you have a problem with your new mail system, you can find out whether your problem is with the server or the new mail client by attempting to connect directly to the server via Telnet.
When I connected to my ISP's mail server via Telnet, the server responded with an informational greeting that contained the date and time. Screen 1 shows my conversation with access4.digex.net. As you can see from the conversation, messages from the server start with numbers, such as 220, 250, and 550. Many Internet protocols have this feature. For example, if you surf the Internet, you have probably come across 404 messages, which alert you to errors in Internet addresses.
In answer to the server's greeting, I typed
The mmco.com defined the domain from which I was communicating. (You can't see the helo command in Screen 1 because I hadn't yet enabled the local echo in the Telnet program's Preferences menu.)
Next, I used the vrfy command to verify whether the system recognized me. Some systems administrators disable the vrfy command for security reasons. For example, try to telnet in to the White House's SMTP server and execute a vrfy command. You'll get a 500 Command not recognized message.
After the server recognized me, I started my message. I began the message with the mail from: command. I typed
to tell the mail server that the message was coming from a user named email@example.com. Note that you must put the username in angle brackets. The server verified that the name firstname.lastname@example.org makes sense and approved the mail from: command. (SMTP servers don't verify which email address a message comes from. Junk emailers often take advantage of this SMTP feature to send mass mailings from other servers' addresses. Such emails are known as SMTP relays.)
Next, I told the server where to send my message. I typed
The server also accepted this command. Then I entered the data command, which let me type the message text.
When I finished typing the text, I typed a period on a line by itself to let the SMTP server know that I had finished. Access4.digex.net then sent the message, without verifying whether mmco.com was online. SMTP mail servers don't wait for a response from the recipient machine before sending emails, so mail servers must have a continuous connection to the Internet to ensure that users receive all their email. If you set up an SMTP machine in your office to dial in to the Internet a few times a day, you will receive only those email messages that reach your computer when it is online. You would be better off keeping your email accounts on your ISP's SMTP server or paying your ISP to keep one of your computers constantly connected to the Internet.
After sending the message to mmco.com, I used the quit command to disconnect from the SMTP server. However, you can't see the quit command in Screen 1. I couldn't capture it in the screen shot because it ended my session and caused Telnet to clear the screen. Screen 2 shows the email I received as a result of my Telnet session.
The Name Game
So how did the spoof message get to my email account on my SMTP server? You'll notice I didn't include a machine name in my email address--I just sent the message to mmco.com, my server's domain. These days, most people don't want to have to know the name of the specific SMTP server on which their messages' recipients have an account. If you want to email a friend named Joe at Acme Industries, you want to just email email@example.com.
How can your mail client find Acme's central mail server? This problem, which Microsoft calls client/server rendezvous, has been an issue in all Internet protocols. The Internet has informal conventions for giving FTP servers and Web servers logical names. For example, the FTP server at 3Com has the address ftp.3com.com, and the Windows NT Magazine Web server has the address www.winntmag.com. But those conventions don't carry over to SMTP servers. You can't expect Joe's mail server to have the address mail.acme.com or smtp.acme.com.
Identifying problems inside a computer system used to be difficult. But now you can use System Management Xray (SMXray) glasses to see inside your system and identify problems at their source.
Make your system and users totally transparent!
Improper use of SMXray glasses might result in lawsuits.
I followed the evolution of SMTP through several RFCs, ending with RFC 821 from August 1982. RFC 821 explains how your SMTP client can find Joe's SMTP server, even if you don't include the SMTP machine name in Joe's email address. If you want to send firstname.lastname@example.org email, you can include andromeda in the address. You can also send the message to email@example.com. Each mail server within a domain has a mail exchanger (MX) record. When you send mail to firstname.lastname@example.org, your local SMTP server figures out which machines within the acme.com domain are SMTP servers by asking acme.com's Domain Name System (DNS) which MX records the domain contains.
You can use the nslookup command to manually access a remote SMTP server's MX records. This command is a DNS client-side tool that comes with NT Server. Open a command line on an online NT machine. Type
nslookup set type=mx
and press Enter. These commands tell nslookup that you want to see a domain's MX records. Then, type any Internet server's domain name (mmco.com will work). You'll see the names of the machines that act as SMTP servers for that domain.
If you want to make your NT machine an SMTP server, download the free software from the European Microsoft Windows NT Academic Centre (EMWAChttp://emwac.ed.ac.uk/html/internet_toolchest/ims/ims.htm) and follow the installation instructions. If you are running Exchange with Internet Mail Connector (IMC), your Exchange server is already an SMTP server. Also, the Microsoft Windows NT Server Resource Kit contains MailSrv, a tool that supposedly can turn your NT machine into an SMTP server. However, I've never managed to make the tool work, nor have I met anyone who has.
Now you know the basics of SMTP. You can set up an SMTP server to receive email using EMWAC's downloadable software. But how can you read a piece of mail once it's on your mail server? You need to use POP3. I'll discuss them next month. Until then, don't write too much spoof mail!