The implementation of the pop3 protocol (client and server) for mail retrieval is spread over 16 files.
We have 2 shared files (net/pop3/port.tcl and net/pop3/auth.tcl), they contain the port definition and a type checker for the possible authentication modes (APOP vs USER/PASS).
After that there are 3 base classes defining the interface between the two cores (client, server) and their external supporters.
Seven files define the various sequencers actually executing the command/reply-chains the pop protocol is made of. With the exception of the login sequencers every operation utilizes only a single command. Their implementation is built on top of the general sequencer framework and and POP specific baseclass in net/pop3/seq.cls.
| File | Operation | POP3 command(s) |
|---|---|---|
| net/pop3/seq.cls | Contains common functionality of all POP sequencers | - |
| net/pop3/open.cls | Open connection to a server | - |
| net/pop3/apop.cls | Login to server. This uses the packages Trf and Memchan to generate the necessary hashvalue (and hex-encoded MD5 hash) | APOP, STAT |
| net/pop3/user.cls | Login to server | USER, PASS, STAT |
| net/pop3/top.cls | Query for header of mail message | TOP |
| net/pop3/retr.cls | Retrieve complete mail message from server | RETR (TOP) |
| net/pop3/dele.cls | Delete message at server | DELE |
| net/pop3/close.cls | Close connection to server | QUIT |
All sequencers understand the options pop3Sequencer:conn, pop3Sequencer:done and pop3Sequencer:sock. The value of the first refers back to the connection object which initiated the sequencer, the second names the method to call in that object after the sequencer has done its work. The last specifies the channel used to talk to the POP server. Of course, sequencer:timeout is understood too.
To get a connection to the pop server the open sequencer has to know the host to connect to (pop3OpenSeq:host), the maximum number of tries before giving up (pop3OpenSeq:maxtries) and the delay between tries (optionRef pop3OpenSeq retrydelay]). The latter is given in milliseconds.
Both login sequencers (net/pop3/apop.cls, net/pop3/user.cls) understand pop3ApopSeq:user and pop3ApopSeq:secret as the way to specify the name of the user trying to login to the server, and its password. The APOP sequencer additionally uses pop3ApopSeq:greeting to get at the greeting sent by the server, and the timestamp buried in it, as it is essential in the generation of the hashvalue encoding the password.
All sequencers executing message specific operations (net/pop3/retr.cls, net/pop3/top.cls and net/pop3/dele.cls) additionally understand the option pop3DeleteSeq:msg which specifies the numerical index of the message to operate on.
The retrieve sequencer (net/pop3/retr.cls) is special in that he understands one more option, pop3RetrSeq:use-top. This is a boolean flag, with a default value of false. Setting it to true forces the sequencer to use the command 'TOP x 0' instead of 'RETR x'. I added it because my provider had a brain dead pop3 server for some time. It did not accept RETR, but delivered the whole mail if 0 was given as second argument to TOP. I don't know wether similar versions of this server are lurking out there, but better be prepared. This option should be left alone under normal circumstances.
The close sequencer makes no use of additional options.
The remaining files implement the server core (net/pop3/server.cls) and the client. The latter is split into two classes, a baseclass encapsulating the access to the various sequencers (net/pop3/pop3.cls), thus managing a single POP connection, and based on that the core and its statemachine itself (net/pop3/client.cls).
The phrase core means that the associated classes manage all aspects of running the pop protocol by themselves, but rely on external objects to handle the following tasks:
POP3 server core, resp. POP3 client core will be discussed in more detail at the refered pages.
Generated by AutoDoc 2.4 at 09/14/2000, invoked by Andreas Kupries