In our last column we addressed one of the most commonly asked questions regarding the sending of e-mail from within a Java applet or application. This was achieved using the SMTP protocol, and by the end of the article a fully functional SMTP class was constructed. Before we continue the development of our column project, Informer, I thought it would be a good idea to complete the e-mail service by presenting the other half of the equation: picking up mail from a mailbox. This article will concentrate on building a class that can be used to interrogate a POP3 mailbox.

If you read last month's column, you may have noticed how easy it was to communicate with the SMTP server. We opened up a socket connection to the server, and then passed commands back and forth using ASCII text strings, terminated in lines.

Well, the good news is that the majority of TCP servers operate in exactly the same way; that is, using ASCII text strings to pass commands. This includes, mail servers, news servers and FTP servers. On the face of it, this doesn't seem to be the most efficient way to communicate with servers, and it isn't. But you have to look at the global picture to understand why it is implemented the way it is.

What's the one greatest strength of the Internet? And, what is the one biggest headache for software developers? The same answer can be applied to both questions: variety of platforms. The Internet is a collection of networks all communicating with one other without having to rely on a single operating system. TCP/IP is a way for a UNIX box to talk to an NT box without having to worry about its operating system. However, when asking a developer to write an application for both platforms, questions about byte and word size will be asked and invariably the answers will be different. One good thing about the computing world is that of all the different standards floating around, nearly every single machine knows of ASCII text. This makes it the ideal data transport for communicating with servers.

POP3 Server
A POP (Post Office Protocol) server is a piece of software that collects and holds mail until a client comes and requests it. Taking the analogy presented last month one step further, a POP server can be thought of as your mailbox at the bottom of your garden. When someone mails you a letter, it is placed into the post office network where it is sorted and delivered, usually by a mail carrier, to your mailbox. It is not the responsibility of the post office to try to tell you how to read it or open it. It is merely a pigeonhole in which incoming mail can be placed and removed. A POP server is no different. It performs the exact same function: providing a holding area until you pick up your mail, using your e-mail package. How the mail actually gets to your mailbox, is of no real concern to you. all you need to worry about is how to pick up the mail once it has arrived.

As stated earlier the POP server sits and listens for connections on port 110 and, once connected, uses a series of commands to communicate with the client. The complete POP version 3 (sometimes referred to as POP3) protocol can be found in the RFC document 1225. You can read this document on the web site http://www.academy97.com. If you do read this specification, you may be surprised by how small it actually is (only 16 pages) with the majority of them showing examples.

Connection
Before we can begin to send commands, we must first open a connection to the server, and this can be achieved using the Socket class, as shown in Listing 1.

Just like the SMTP class we developed last month, we create two streams that will make communicating with the server much easier. For example the BufferedReader class gives us the method readLine(), which can be used to receive data back from the server without having to worry about carriage returns, etc.

If a connection is successful, the first line we will receive back is a welcome message which may read something like:

+OK mail.n-ary.com POP server ready; Sun, 21 Sep 1997 12:42:00 GMT

Whereas the SMTP host used status codes to indicate success or failure, the POP server uses +OK and -ERR to flag status values. This makes the receiving function at the client much easier to code.

The next thing we have to do is log on. We pass the username and password of the mailbox addressee and, if it is successful, +OK will be sent back as shown in Listing 2.

We have coded two special functions, sendMessage() and rxdLine(...), that perform some additional error checking. The source for both of these can be found in Listing 3.

Mail Headers
The POP3 server only supports a very small set of commands. We have commands to retrieve just the mail headers, the number of mail messages waiting, the complete mail message and commands to delete mail messages from the server.

Messages are queued at the server one after another, generally in the order in which they arrived. The POP server gives each message an ID starting at 1. Note, that this ID is only unique for that session. If you delete message 3, for instance, and then log off and log back on again, then the message that was ID 4, now has the ID of 3. So be very careful when coding e-mail clients.

One of the most basic things that is very useful, is the ability to see what mail is waiting for us without having to download the complete message. This is especially useful for clients on a dial-up connection, where they can choose whether to accept or not accept delivery of attachments. To achieve this we must first know the number of e-mails waiting for us, so that we can then count forward to that number. We do this by sending the command STAT to the server. The server will then return the result:

+OK 4 3210

The first part of the response is the status flag, and the second is the number of messages waiting in collection. The last value is the total size of all the messages, expressed in octets. This is particularly useful, as one can calculate a very accurate progress monitor for the download status.

Having received the number of messages, we then use the TOP command to download just the message headers. The TOP accepts two parameters: the message ID and a block number. For example, we can return the header for message 2, by issuing the command TOP 2 1' to the server. The server will then return with a mail header for that message, terminated with a single ".".

As you can see, if you refer to the getMailHdr() function in the Listing 3, the header consists of many different fields, of which Subject, Date and From are of particular interest to us. We package this information up into a class wMail and return.

Using this functionality, our e-mail client can display a list of all incoming mail without having to download each one.

Mail Transfer
The next step, is to actually download the complete e-mail. This is performed using the RETR command with the mail ID. For example, to receive the e-mail, complete with header and body, the following command would be issued to the server: RETR 2.'

Again, if you refer to Listing 3, and look at the getMail(...) function, you will see this occurring. Notice how we determine the difference between the main body and the mail header. The mail header is transmitted first, with a blank line indicating the end of the header and the beginning of the main body. For ease of use, we place the body into a Vector, with each line of text as a new entry.

Mail Deletion
Deleting the message on the server, as you may have already guessed, is a simple matter of issuing the DELE command, complete with the message ID. The server will then return with a success or failure depending on whether or not the message exists.

Summary
That's it! That is the basic functionality required to implement a POP3 client. Listing 3 shows a couple of extra commands, but the core has been demonstrated in the main article body.

To see this class in action, I converted it into a Java Servlet, which allows you to check, read and delete your e-mail from a Web browser. Visit http://www.academy97.com/email_login.html.

So far, we have implemented a very basic front-end to Informer, complete with database access to a list of contacts. We also have the functionality to send e-mails and, with this article, the ability to receive e-mails as well.

Next month, we will be adding more features to Informer