THE MAGAZINE FOR COMPUTER APPLICATIONS
Circuit Cellar Online offers articles illustrating creative solutions
and unique applications through complete projects, practical
tutorials, and useful design techniques.

AN S-7600A/PIC16F877 JOURNEY

Part 3: Hot-Wiring the System
by Fred Eady

Start ı E-Mail 101 ı Automatic Transmission ı Mail Delivered ı Sources and PDF

E-MAIL 101

Casual Windows users have few choices. E-mail is done with a graphical mail program like Microsoft Outlook or something similar. That is, the mechanics of e-mail are hidden behind a pretty and predefined package. This is a good thing, seeing that the casual e-mailer doesnıt need or want to know whatıs going on behind the scenes. He or she simply wants a message to be delivered to the recipient at a specified address. A Sendmail DLL exists that allows Windows developers or serious Windows users to mail by wire. And, as youıll see a little later on, there are commercially available and careware terminal emulators for guys and gals who want to know.

Unix and Linux users have it a little better if you consider more options and more complexity a better thing. Like the Windows user, the Unix and Linux user can use a canned mail program to send and receive messages via a mail server. Users of these systems also have the capability of writing their own programs using languages like Perl or shell scripts to send and receive mail the old-fashioned way. And, somewhat like Windows, the Unix community has a mail program interface that allows mail servers and mail clients to be created.

In either case, if thereıs a will, thereıs a way. Users of Windows- and Unix-based operating systems can use and abuse applications like Telnet or FTP to gouge their way through an e-mail transfer. Thereıs no reason to go in that direction because e-mail is really a simple and structured process that is, like most everything that works on the Internet, based on standards. In the case of e-mail, RFC 821 is the standard document for people interested in building simple e-mail devices. The official name behind e-mail and RFC 821 is Simple Mail Transfer Protocol, or SMTP. RFC 822 and no less than five updates are also part of the e-mail specification. Iıll focus on the concepts in RFC 821 and some of the language in RFC 822. Basically, Iım warning you that I wonıt be attempting to cross-reference the various RFC updates in this article, and this is by no means intended to be a doctoral thesis on e-mail. I simply want to show you how to manipulate the e-mail mechanism, enabling you to send e-mails with small embedded devices.

The whole idea behind SMTP is to make mail delivery reliable and efficient. SMTP really doesnıt care what buggy it rides on, but the buggy had better have good wheels and a horse with a sense of direction. In other words, SMTP depends on a reliable datastream like TCP/IP. Because SMTP is independent of the transport, it can work over networks of various machine types in the same room or networks of different machine types between continents.

SMTP is based on a sender/receiver relationship. The sender requests and establishes a two-way communications channel to the receiver. The SMTP receiver can be the ultimate destination or just one hop along the way. The sender is in control as commands are generated by the sender and acknowledged by the receiver. After the communications channel is open, a lock-step process is executed between the SMTP sender and receiver.

After successful connection and host verification, the first command from the sender is a MAIL command. If the receiver can handle the senderıs mail, it responds with an OK reply code. The MAIL argument specifies who the mail is from. This argument is called a reverse-path. That is, any messages, good or bad, can be sent via the reverse-path to the sender. Normally only bad messages make their way back to the sender this way.

The MAIL command is followed by a RCPT command. RCPT is short for recipient or the final intended receiver of the mail message. RCPT is termed a forward-path. Again, the receiver checks to see if it can accept the mail for the recipient, and if it can, another OK code is returned.

More than one recipient can be specified, and when all of the recipients are good to go, the mail message is transmitted to the SMTP receiver behind the DATA command. The mail message is delimited in a special way. A single period on a line by itself signifies the end of the message. If all goes well, the mail is sent along its way and the SMTP receiver issues a final OK return code. At this point, the connection between the SMTP sender and receiver is normally closed.

The return and OK codes I mentioned are actually numeric codes sometimes followed by an explanatory text message. The numeric part of the reply is intended for the machines, and the text content of the reply is for human consumption. The text makes it easy to debug an e-mail session without having to pull out the scope or read a dump. The SMTP commands and return codes, or replies, are defined in the SMTP standards. Commands and replies are not case-sensitive. A list of the commands and their syntax per RFC 821 is shown in Table 1.

And, Table 2 shows what the replies look like as of RFC 821.

Table 2 is a bit overwhelming at first glance, but the truth is that you only need five of the commands to successfully send e-mail. And, if youıre doing things right, youıll only encounter three of the replies. One of those commands you havenıt been formally introduced to is HELO. HELO is like Mickıs line in the song "Sympathy for the Devil." You know, "Please allow me to introduce myselfı."

When the sender and receiver open a communications channel, an exchange between the hosts occurs to verify whoıs who. As you have ascertained, HELO is short for hello. HELO and the domain argument are sent by the SMTP sender to identify the senderıs domain. The receiver replies with another line from Mickıs song, "Pleased to meet you; hope you guessed my name." (Hey, the name Muhammed Ali is used in an RFC 822 example, so I can use Mick in mine canıt I?)

Now that you kind of know what to expect in terms of command and reply, this is a good spot to show you how an SMTP session works graphically. Photo 1 is a screen shot of an SMTP session that I invoked manually using a careware terminal emulator called EasyTerm. You can read about careware and get a copy of EasyTerm by visiting www.arachnoid.com. Iıll follow the example session in RFC 821, and at the end, should I be successful, an e-mail message will be generated and sent.

Referencing the commands and replies I listed earlier, reply 220 is usually a good thing. The first line of the manual e-mail session is a 220 OK reply returned for a good TCP/IP connection between my EasyTerm terminal and the mail port (0x19 or 25 decimal) at my ISP cfl.rr.com. I then entered HELO cfl.rr.com and hit Enter. The 250 reply is the high sign for the HELO command. As you can see in the text of the 250 reply, the receiver identifies itself to the sender here. This sequence of HELO commands and replies is an indicator that no transactions are in progress, and the e-mail process is in the cleared and idle state as far as buffers and state tables are concerned.

The MAIL FROM: command and its argument, which was also entered manually, starts the process that puts mail data in a mailbox. The MAIL command also clears the forward- and reverse-path buffers and inserts the argument (in this case, fleady@cfl.rr.com) in the reverse-path buffer. That means any error messages will be returned to fleady@cfl.rr.com. Another 250 reply tells you that the sender is valid.

If youıre wondering why there are two OK replies, 220 and 250, the story lies in the numbers themselves. The most significant digit, 2, means that the message is a positive completion reply. If the middle digit is also 2, then the reply has to do with a connection or the communications channel. A middle digit of 5 references the mail system. The third digit gets into specifics of what the first two digits are coarsely defining. A good set of replies to look at includes the 220, 221, and 421 replies. To give you an idea as to how the replies use numbers to group themselves, Iıve included the reply list (as of RFC 821) sorted by functional group (see Table 3).

Getting back to the manual e-mail session, the next command I entered is RCPT and its argument, the destination address of the mail data. There can be bunches of RCPT command lines, and again, 250 is the reply you want. The argument of the RCPT command is put into the forward-path buffer.

The next command I entered is DATA. After the 354 is returned, everything in the ASCII character set that follows this command is buffered in the mail data buffer. An end-of-mail indicator, <CRLF>.<CRLF>, is appended to the text after the message body. After the end-of-mail indicator is sensed, all the data in the forward-path, reverse-path, and mail data buffers is used to get the mail from point A to point B. If everything goes as planned, the mail is forwarded, all of the buffers are cleared, and a 250 OK reply is returned.

There are a couple of things missing in Photo 1. The first missing item is the fifth command, QUIT. Every command must have a single reply. So, the last missing element is the 221 reply from the receiver. After that, itıs lights out. All of that manual labor paid off as the e-mail you see in Photo 2.

Note the "Subject:" and "To:" in the message after the 354 reply. This is an optional header you can insert. It is followed by a blank line, which separates the header from the message body. This format is some of what youıll find in RFC 822. Leaving out the header would not have put any text in the received e-mail noteıs "Subject:" line, and the RCPT argument would have replaced the received e-mail noteıs "To:" line text.

I have by no means delved deeply into the bowels of SMTP. I suggest looking deeper at RFC 821 and RFC 822 if you require further knowledge about the commands and replies. These RFCs are good reading, and if you really want to drive the SMTP process hard, thereıs plenty of content there to help you succeed.

PREVIOUS • NEXT