Notes on the POP3 implementation
================================


- LIST and UIDL are issued only once to get information about all mails

  Therefore, mpop has to keep information about every mail in memory. Currently,
  roughly 14 bytes plus the average length of an UID are required per mail on a 
  32 bit system. In most cases, less than 35 bytes are needed, so you can handle
  1000 mails in less than 35 KB, or 100000 mails in less than 3.5 MB.

  A malicious server can send a very big total number of mails in response to
  the STAT command. The maximum number accepted by mpop is POP3_MAX_MESSAGES
  (currently 1000000). This means that mpop can try to allocate very large
  amounts of memory, up to roughly 35 MB. This should not be a problem on most
  systems, but if your system does not have that much free memory, the following
  can happen:
  1) xmalloc() fails, mpop aborts.
  2) xmalloc() succeeds (for example on overcommitting OSes like Linux). The 
     next thing mpop does is issuing the LIST command to request the size of 
     each mail. Then two things can happen:
     a) The server is not able to deliver them all, mpop terminates.
     b) mpop tries to access much of the allocated memory and gets killed by the
        OOM killer.


- Pipelining can be used for TOP, RETR, and DELE.

  Pipelining works by sending up to PIPELINE_MAX commands to the server, then 
  begin to read its answers, and refill the command pipeline when the number of
  unanswered commands drops to PIPELINE_MIN.
  Pipelining results in great speed improvements because many round trips are 
  saved. It is automatically enabled for modern servers that can announce their
  capabilities. You can enable it with the command "pipelining on" for obsolete 
  servers, too.
  The values PIPELINE_MIN and PIPELINE_MAX are defined in pop3.c. If these 
  defaults cause trouble for you or you find better values, please send a mail.


- The UIDLs file is always updated

  Once the first message is retrieved and successfully delivered, mpop cannot 
  simply abort, because the information about the delivered mail would be lost.
  So even if the session becomes unusable due to network errors, protocol 
  violations, or signals, mpop makes sure that the UIDLs file is updated.
  This means that no message that was successfully delivered before will be 
  retrieved a second time. All successfully delivered messages will be deleted
  at the end of a session (unless 'keep' is set, of course), regardless of when
  they were delivered. Thus, once mpop can end a session normally (without 
  errors or signals interrupting it), no stale mails will be left on the server.
