1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
|
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.
|
