SMTP, Simple Mail Transfer Protocol
Besides telnet itself and DNS, for which good tools are available, the most important text-based protocol for communicating b etween machinesover a network is SMTP, Simple Mail Transfer Protocol. Although virtually all computers today speak SMTP, it was developed on Unix and provides a good example of how Unix thinks about networking.
Learning to talk SMTP manually is useful when trying to debug mail problems. (Can I connect to the Mail server? Does a message sent directly to the server, which it accepts, make it to the user?) It is also useful to learn SMTP to provide a practical foundation for thinking about networking in more abstract cases.
SMTP is used for sending mail, which is different from reading your mail. That is done with either the POP3 or IMAP4 protocols. Instead, SMTP is what is used when you send email in response to a message you've read or when you send out an entirely new message. Let's look at an SMTP session and see how it works. We'll deal with two users, jon (That's me) and elvis (That's not me).
[ jon@frogbog jon ]$ telnet razorback 25 Trying 192.168.0.10... Connected to razorback.localdomain. Escape character is '^]'. 220 razorback.localdomain ESMTP Sendmail 8.9.3/8.9.3; Wed, 5 Jan 2000 09:32:34 -0500
After I've connected, the mail server displays a header showing the host name, the time, the date, and the version of the mail server. More importantly, however, is the three-digit number before the message. When an automated program talks to a mail server, it doesn't read the message, just the three-digit status code.
HELO frogbog.localdomain 250 razorback.localdomain Hello IDENT:email@example.com [192.168. 0.33], pleased to meet you
First, we identify ourselves to the mail server with a HELO frogbog.localdomain. Because my home network is not connected to the Internet, I use .localdomain as my top-level domain. Most SMTP commands are a few letters long. Although SMTP commands are not case sensitive, capitalizing them certainly makes it more obvious what's a command and what's an argument. Some servers support a HELP command, which lists all valid commands; other SMTP servers don't support this command, which is unfortunate when you've manually connected to the SMTP server.
The HELO command is used to authenticate the host sending email for the server logs and as an anti-spam measure. An ever-dwindling number of servers don't require this command. The mail system checks to see that the machine you claim to be (in this case frogbog.localdomain) can possibly be correct. It might also try to figure out what user you are on that system. (In this case, the response notes that I'm firstname.lastname@example.org.) In some cases, the system might not care who you claim to be, as when for example you're sending mail within a system. The mail daemon (a Unix term referring to a constantly running system process) responds with some information and, more importantly, a 250 status code. 250 essentially means, "All okay, go ahead."
mail from: jon@frogbog 250 jon@frogbog... Sender ok rcpt to: jon@razorback 250 jon@razorback... Recipient ok
Next, we tell the system who we are to send mail-jon@frogbog, again-and the system verifies that this is a reasonable combination, again as an anti-spam measure. Some systems make sure that the domain name or even the host name is legitimate, and some systems have further restrictions on this. The system responds with a 250 again, and we let it know who we're sending mail to. It checks that this is a valid user and responds in the affirmative with a 250.
data 354 Enter mail, end with "." on a line by itself From: Jon <jon@frogbog> To: Myself <jon@razorback> Subject: Demonstration of email I'm just typing this message in entirely by myself, just over telnet. If you're curious, the name for the service on port 25 is 'smtp' (no quotes), and other than that, this message is entirely content-free. . 250 JAA05993 Message accepted for delivery
Next we give the DATA command, and we can input our message. It's very important that the from: and to: we've already set don't need to match the headers in the message itself. Most users only see the headers that are part of the message, the ones I manually typed in the previous case (From: jon To: myself, and so on). If the data given directly to the mail daemon is saved at all, it ends up in a received: header hidden by most mail clients. We enter a dot on an empty line to end the message, and the system responds back with a 250 telling us we're okay.
mail from: jon@frogbog 250 jon@frogbog... Sender ok rcpt to: elvis@razorback 550 elvis@razorback... User unknown quit 221 razorback.localdomain closing connection Connection closed by foreign host. [ jon@frogbog jon ]$
Just for kicks, I tried to send a message to Elvis, who doesn't have an account on razorback, and the system responded back with a 550 error, letting me know that Elvis was not in the building. Finally, we QUIT. The system responds with a 221, gives us a "quitting" message, and kicks us out.