- Anatomy of an Email Message
- Sending an Email Message
- Receiving an Email Message
- Review
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Receiving an Email Message
Internet-based email messages are typically received from senders by way of the POP3 network protocol. According to POP3, when an email program needs to receive email messages, that program establishes a two-way transmission channel (by way of sockets) to a POP3 server program that is always running on some accessible host (such as your Internet Service Provider's host). Once the email and POP3 server programs have established a two-way transmission channel, the email program issues a sequence of ASCII-based commands to the POP3 server program, and the POP3 server program replies to each command with an ASCII-based response message indicating success or failure. Initial commands identify a user's mailbox within the SMTP/POP3 email database and authenticate the user wanting to access his mailbox. Assuming successful authentication, the POP3 server program accepts email message retrieval commands from the email program and returns specified email messages (from the user's mailbox) to the email program. Figure 3 provides an illustration of this POP3 model.
){kind=link}
Figure 3 The POP3 model for receiving email messages. Sockets appear as green boxes.
POP3 recognizes a variety of commands that email programs can use to communicate with POP3 server programs. Some commands take arguments and other commands take no arguments, but each command must end with a carriage-return character followed by a newline character. Six commonly used commands are USER, PASS, STAT, RETR, DELE, and QUIT.
The previous ordering of the six commonly used POP3 commands is not an accident. The commands must be entered in their specified order (although STAT, RETR, and DELE can be entered in any order, as long as they are entered after PASS and before QUIT) because a POP3 server program is a state-based program. For each email program that establishes a two-way transmission channel with the POP3 server program, the POP3 server program maintains username/password state on the current email message transaction with that email program.
When an email program successfully connects its socket to a POP3 server program's server socket, the POP3 server program sends an initial message to the email program. That message consists of a +OK reply code and a text message identifying the SMTP server program.
The reply code, which is located at the beginning of every POP3 server program response message, is either +OK for success or -ERR for failure; this is used by email programs to automate their email message transactions with POP3 server programs. By contrast, the text message provides meaningful information to a user. An email program must check the reply code to determine its next course of action, but it may ignore the text message if it is not deemed to be relevant (such as the initial message).
After receiving the initial message, an email program begins its email message transaction by sending the USER command. USER identifies the name of the user requesting access to the user's mailbox and takes an argument that identifies the user's name. In response, the POP3 server program validates the existence of a mailbox corresponding to the specified username. Either +OK or -ERR, with a suitable message, returns to the email program.
Following USER, an email program sends the PASS command. PASS identifies the password that associates with the previously specified username. If the password is correct, the POP3 server program returns a response message beginning with +OK. Otherwise, a response message that begins with -ERR returns.
At this point, the email program is free to issue the STAT, RETR, and DELE commands (in any order) to obtain statistics on the number of messages and message size (in bytes, also known as octets), to retrieve email messages, and to delete email messages (respectively).
The STAT command takes no arguments, and its +OK x y response identifies x waiting messages having a combined size of y bytes.
Both the RETR and DELE commands take a single one-based integer argument that identifies an email message. When the email program sends the RETR command, the POP3 server program replies with a -ERR response message if there is no email message associated with the integer argument. Otherwise, the POP3 server program replies with a multiline response message, beginning with +OK y, where y identifies the total number of bytes in remaining lines. The email program must continue reading lines from the POP3 server program until it reads a line beginning with a period character (or the total number of bytes has been read, whichever comes first). That final line signifies the end of RETR's response. When the email program sends the DELE command, the POP3 server program replies with a -ERR response message if there is no email message associated with the integer argument, or a +OK response message that confirms email message deletion.
Finally, when the time comes to disconnect its transmission channel with the POP3 server program, the email program sends the no-argument QUIT command.
To help you understand POP3-based email transactions, I wrote a command line–based program called POP3Demo. When run, that program attempts to connect to my ISP's POP3 server program on standard port number 110. Although you should not need to change 110 (because that number is standard for a POP3 server program port), you will need to change mail.gatewest.net to the domain name of your ISP's host (so that the program will work for you) before compiling POP3Demo's source code. Listing 2 presents that source code.
Listing 2: POP3Demo.java
// POP3Demo.java
import java.io.*;
import java.net.*;
class POP3Demo
{
public static void main (String [] args)
{
String POP3Server = "mail.gatewest.net";
int POP3Port = 110;
Socket client = null;
try
{
// Attempt to create a client socket connected to the POP3
// server program.
client = new Socket (POP3Server, POP3Port);
// Create a buffered reader for line-oriented reading from the
// standard input device.
BufferedReader stdin;
stdin = new BufferedReader (new InputStreamReader (System.in));
// Create a buffered reader for line-oriented reading from the
// socket.
InputStream is = client.getInputStream ();
BufferedReader sockin;
sockin = new BufferedReader (new InputStreamReader (is));
// Create a print writer for line-oriented writing to the
// socket.
OutputStream os = client.getOutputStream ();
PrintWriter sockout;
sockout = new PrintWriter (os, true); // true for auto-flush
// Display POP3 greeting from POP3 server program.
System.out.println ("S:" + sockin.readLine ());
while (true)
{
// Display a client prompt.
System.out.print ("C:");
// Read a command string from the standard input device.
String cmd = stdin.readLine ();
// Write the command string to the POP3 server program.
sockout.println (cmd);
// Read a reply string from the POP3 server program.
String reply = sockin.readLine ();
// Display the first line of this reply string.
System.out.println ("S:" + reply);
// If the RETR command was entered and it succeeded, keep
// reading all lines until a line is read that begins with
// a . character. These lines constitute an email message.
if (cmd.toLowerCase ().startsWith ("retr") &&
reply.charAt (0) == '+')
do
{
reply = sockin.readLine ();
System.out.println ("S:" + reply);
if (reply != null && reply.length () > 0)
if (reply.charAt (0) == '.')
break;
}
while (true);
// If the QUIT command was entered, quit.
if (cmd.toLowerCase ().startsWith ("quit"))
break;
}
}
catch (IOException e)
{
System.out.println (e.toString ());
}
finally
{
try
{
// Attempt to close the client socket.
if (client != null)
client.close ();
}
catch (IOException e)
{
}
}
}
}
After you replace mail.gatewest.net with your ISP's hostname and compile POP3Demo's source code, type java POP3Demo. Carry out the following exercise, and you will see similar output:
The following exercise's output is from a sample session between myself (C:) and my ISP's POP3 server program (S:).
S:+OK QPOP (version 2.3) at kynes.gatewest.net starting. <27402.1015108737@kynes.gatewest.net>
This initial message was sent from my ISP's Linux-based QPOP POP3 server program to POP3Demo.
C:user jeff S:+OK Password required for jeff.
I began the email message transaction by typing user jeff, to identify my mailbox. QPOP replied with a +OK response message indicating that it is waiting for a password.
C:pass ******** S:+OK jeff has 1 message (554 octets).
I next specified my password. Although you see eight asterisks, I did not type those asterisks: I entered my actual password, instead. In response, QPOP sent a +OK message identifying one email message in my mailbox and also identifying the email message's size as 554 octets (bytes).
C:retr 1 S:+OK 554 octets S:Return-Path: <jeff@javajeff.com> S:Received: from gatewest.net (h139-142-224-80.gtcust.grouptelecom.net [139.142.224.80] S: by kynes.gatewest.net (8.12.1/8.12.0.Beta19/Debian 8.12.0.Beta19) S: for <jeff@javajeff.com>; Sat, 2 Mar 2002 16:38:29 -0600 S:Date: Sat, 2 Mar 2002 16:38:10 -0600 S:From: Jeff Friesen <jeff@javajeff.com> S:Message-Id: <200203022238.g22McAxW027265@kynes.gatewest.net> S:Subject: Test Email S:To: undisclosed-recipients:; S:X-UIDL: ef17608650892dac19191c3244fbe4a9 S: S:This is my email message. S: S:.
I decided to retrieve that email message by specifying retr 1. (I chose 1 as an argument to RETR because there was only one email message and because email message numbers begin with 1.) In response, I received lots of information. Note the g22McAxW027265 message ID. That ID identifies this email message as the first email message that I sent during my demonstration of SMTPDemo.
It might surprise you to see a From: header in the retrieved email message. After all, I did not specify a From: header when I sent the email message. From where did From: originate? When I sent the email message with SMTPDemo, my ISP's SMTP server program provided that header (starting with information gleaned from the MAIL command). You might also be surprised to see a To: undisclosed-recipients:; header because I did not specify that header when sending the email message. In the absence of To: or Cc: headers, my ISP's POP3 server program provided that header (to hide RCPT addresses).
C:dele 1 S:+OK Message 1 has been deleted.
After reading my email message, I decided to delete it from my mailbox by specifying dele 1. The +OK response message indicates successful deletion:
C:stat S:+OK 0 0
Just to confirm that my mailbox was empty, I sent the STAT command to the QPOP POP3 server program. QPOP responded with a +OK message indicating no email messages in my mailbox:
C:quit S:+OK Pop server at kynes.gatewest.net signing off.
After retrieving and deleting the email message, I had nothing else to do, so I terminated my connection with the QPOP POP3 server program.