The sequence of events in a POP session
This section explains the several steps in a POP3 session as they are implemented in the POPular system.
When a new connection is opened from a client, the POP3 proxy ("pproxy") forks and sends a welcome message to the client. The client sends the username and password. Username, password, the client IP and some other information is then checked against one or more databases.
To be as flexible as posssible, these database checks are performed in so called POPular database modules (PDM) implemented as shared libraries loaded at runtime into the pproxy process. Several databases can be checked after another until one finds and authenticates the user.
The proxy supports IP based virtual servers. It can listen to more than one IP address and port. Depending on which IP address and port a new connection is coming in on, the proxy can use different namespaces for authentication.
From the database modules, the proxy will get back the name of the backend server, where the mailbox of this user is stored, and the protocol, which is to be used to connect to this backend. Depending on the protocol either the name of the mailbox or a username and password are also returned.
If the backend server is a POPular server, the proxy now sends a mail check requests to the backend server. This is a small UDP datagram only containing the name of the mailbox. The pcheckd process on the server will receive this mailbox name and check whether there are any mails in this mailbox It will tell the proxy by sending a UDP datagram back. Statistics have shown that about 80% of all accesses to a mailbox will find an empty mailbox, so it makes sense to check for this and optimize the common case. See below for what happens if the mailbox is empty.
If there are any mails in the mailbox the proxy will now open a TCP connection to the storage server. Depending on the procotol to be used, two different things can happen:
If the protocol is POP3 indicating a normal POP3 server is used as backend, the username and password that the proxy got from the PDM modules is send to the server. (This username and password might well be the same as the one the client sent, but this is not required.) The backend server will then authenticate the user again and answer with a positive or negative answer, which is relayed back to the client.
Because the user is already authenticated it doesn't really make sense to send the username and password and check them again on the backend server. That is why the POPular package contains a special server ("pserv") that will not check the user again, but just use a mailbox name supplied by the proxy.
If the protocol is XPOP indicating that a POPular backend server is used, the proxy first sends the name of the mailbox in a line by itself, then an ID which is used for all logging messages to easily find corresponding entries in the proxy and server log and then a line with flags. The POP server will answer with "+OK", which is relayed back to the client.
From now on the client and server will exchange POP3 requests and responses. The proxy ferries the data back and forth without interfering until one or the other closes the connection.
If the mailbox is empty the proxy server will handle this POP connection alone, i.e. it will answer all requests with "no mail" or whatever is appropriate for an empty mailbox. This reduces the load on the storage servers considerably.
