For a University of Nottingham module I developed an email server to translate POP3 commands into server calls.
Date written: 2013
The program opens up a listen socket so that POP3 clients can connect to, in order to access email.
Details of the POP3 protocol can be found at http://www.apps.ietf.org/rfc/rfc1939.html
The program supports the following POP3 commands: USER PASS QUIT STAT LIST RETR DELE NOOP RSET TOP UIDL
The three main components are:
Converts the POP3 commands coming from the network connection into method calls to the database back-end and generates the responses to send back along the network connection.
Opens a network connection to listen for incoming connections from the email program. Supports more than one concurrent connection so uses threading.
The emails are stored in a standard SQL database, this part of the program fetches the relevant emails from the database using the Java database APIs in response to the method calls from the Command Interpreter.
The interface between the network component and command interpreter is relatively simple. Each active network connection will have a command interpreter object that it will call handleInput on to pass it a string containing the next command received from the client. However, the interface between the Command Interpreter and the Database back-end is more formal, using a normal Java interface. This is so the command interpreter is independent of the database back-end.
Converts the POP3 commands coming from the network connection into method calls to the database back-end and generates the responses to send back along the network connection.
This handles the POP3 commands listed above, that are sent to the POP3 server over the network connection from the POP3 client. The network section has already converted the commands from a sequence of bytes (octets, in network speak) into a Java String.
-
POP3 sends commands over the network connection in ASCII with each command on one line, these have been converted into Strings by the Network section.
-
The command interpreter is presented (by calls to its method) with each command as a string. Firstly, it works out which command has been received (RETR, or USER, for instance). Once this has been done it has to ensure that any parameters required by the command are present, and correct. It converts them into a relevant Java type (for example, RETR takes a message id as a parameter, this is an integer number so should be converted to an int).
-
Once the string has been parsed, relevant methods are called via the interface that links to the back-end to fetch the relevant details from the database. The result of this call should then be packaged up as a correct POP3 response to the client (e.g. if the client tries to use RETR to access a non-existent message then the client should return an error response as defined in the RFC).
-
The command interpreter makes sure that it keeps the correct state
This section opens a listen socket on the local machine, on a port specified on the command line that starts the server. When a client connects to the server, it accepts the connection and route the input from the client to the Command Interpreter. Any responses generated by the Command Interpreter should be routed back to the client over the network connection.
- Opens a network socket that is set to listen for incoming connections on a port. The port number is passed to the server as a command argument (although port 110 is usually used for mail).
- The server takes two parameters on the command line when it is started. The first is the port number. The second should be an integer representing a timeout value in seconds. This should default this to 600 seconds as per the POP3 specification. So to run the server a typical command might be, java Pop3Server 110 600
- Accepting multiple, concurrent, incoming connections from clients.
- Data from each client should be routed to a separate Command Interpreter object for each client and the responses from this object routed back to the correct client.
- When the Command Interpreter finishes the session, the network connection closes.
- The connection should be terminated after a fixed length period of inactivity as given in the POP3 specification.
This implements the interface designed, as well as connects to the University of Nottingham's MySQL server to access the emails stored in it. The back-end translates the method calls into actions on the database to complete the task (retrieve an email, delete an email, etc.). A setup file creates the tables for the database and pre-populates it with some sample emails.
The table m_Mail is used to store the email messages and has four fields.
iMailID is an integer and is used as the primary key to identify each entry in the database.
iMaildropID defines which maildrop the email is associated with. The actual email it self is stored in txMailContent as one long string.
Finally, vchUIDL contains a unique identifier for each email (as required by the POP3 specification). As provided, the database is setup to contains eight emails ranging from under 1k to a couple around 150k which include some attachments.
There are also three user accounts defined in m_Maildrop for the testing of simultaneous logins. The fields are fairly obvious: vchUsername, and vchPassword contain the username and password (in plaintext) resepectively, while iMaildropID is the primary key and contains an integer number to identify each mail drop.
tiLocked is used to note whether the account has been locked or not.
The back-end object exposes the emails stored in the database to the rest of the program. Connecting to the MySQL database, a JDBC connection is established to the database, which is on the machine mysql.cs.nott.ac.uk. The MySQL connectors jar file used in the CLASSPATH can be found here.
Module Taught By: Steven R. Bagley, Colin Higgins & Stephen Nutbrown