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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Updated design notes on fetchmail</title>
<link rev="made" href="mailto:matthias.andree@gmx.de" />
<meta name="description" content="Updated design notes on fetchmail." />
<meta name="keywords" content="fetchmail, POP, POP2, POP3, IMAP, ETRN, ODMR, remote mail" />
<style type="text/css">
/*<![CDATA[*/
h1.c1 {text-align: center}
/*]]>*/
</style>
</head>
<body>
<table width="100%" cellpadding="0" summary="Canned page header">
<tr>
<td width="30%">Back to <a href="index.html">Fetchmail Home Page</a></td>
<td width="30%" align="right">$Date$</td>
</tr>
</table>
<hr />
<h1 class="c1">Design Notes On Fetchmail</h1>
<h2>Introduction</h2>
<p>This document is supposed to complement <a
href="esrs-design-notes.html">Eric S. Raymond's (ESR's)
design notes.</a> The new maintainers don't agree with some of the decisions
ESR made previously, and the differences and new directions will be laid
out in this document. It is therefore a sort of a TODO document, until
the necessary code revisions have been made.</p>
<h2>Security</h2>
<p>Fetchmail was handed over in a pretty poor shape, security-wise. It will
happily talk to the network with root privileges, use sscanf() to read
remotely received data into fixed-length stack-based buffers without
length limitation and so on. A full audit is required and security
concepts will have to be applied. Random bits are:</p>
<ul>
<li>code talking to the network does not require root privileges and
needs to run without root permissions</li>
<li>all input must be validated, all strings must be length checked,
all integers range checked</li>
<li>all types will need to be reviewed whether they are signed or
unsigned</li>
</ul>
<h2>SMTP forwarding</h2>
<p>Fetchmail's multidrop and rewrite options will process addresses
received from remote sites. Special care must be taken so these
features cannot be abused to relay mail to foreign sites.</p>
<p>ESR's attempt to make fetchmail use SMTP exclusively failed,
fetchmail got LMTP and --mda options – the latter has a lot of
flaws unfortunately, is inconsistent with the SMTP forwarder and needs
to be reviewed and probably bugfixed. --mda doesn't properly work with
multiple recipients, it cannot properly communicate errors and is best
avoided for now.</p>
<h2>Server-side vs. client-side state.</h2>
<h3>Why we need client-side tracking</h3>
<p>ESR asserted that server-side state were essential and those persons
responsible for removing the LAST command from POP3 deserved to
suffer. ESR is right in stating that the POP3 UID tracks which messages
have been read <em>by this client</em> – and that is exactly what
we need to do.</p>
<p>If fetchmail is supposed to retrieve all mail from a mailbox
reliably, without being disturbed by someone occasionally using another
client on another host, or a webmailer, or similar, then
<em>client</em>-side tracking of the state is indispensable. This is
also needed to match behavior to ETRN and ODMR or to support read-only
mailboxes in --keep mode.</p>
<h3>Present and future</h3>
<p>Fetchmail supports client-side state in POP3 if the UIDL option is
used (which is strongly recommended). Similar effort needs to be made to
track IMAP state by means of UIDVALIDITY and UID.</p>
<p>This will also mean that the UID handling code be revised an perhaps
use one file per account or per folder.</p>
<h2>Concurrent queries/concurrent fetchmail instances</h2>
<p>ESR refused to make fetchmail query multiple hosts or accounts
concurrently, on the grounds that finer-grained locks would be hard to
implement portably.</p>
<p>The idea of using one file per folder or account to track UIDs on the
client-side will make solving this locking problem easy – the lock can
be placed on the UID file instead.</p>
<h2>Multidrop issues</h2>
<p>Fetchmail tries to guess recipients from headers that are not routing
relevant, for instance, To:, Cc:, or Resent-headers (which are rare
anyways). It is important that fetchmail insists on the real envelope
operation for multidrop. This is detailed in <a
href="http://home.pages.de/~mandree/mail/multidrop">my
article "Requisites for working multidrop
mailboxes"</a>.</p>
<p>As Terry Lambert pointed out in the FreeBSD-arch mailing list on
2001-02-17 under the subject "UUCP must stay; fetchmail sucks",
fetchmail performs DNS MX lookups to determine domains for which
multidrop is valid, on the assumption that the receiving SMTP host
upstream were the same as the IMAP or POP3 server.</p>
<hr />
<table width="100%" cellpadding="0" summary="Canned page footer">
<tr>
<td width="30%">Back to <a href="index.html">Fetchmail Home Page</a></td>
<td width="30%" align="right">$Date$</td>
</tr>
</table>
<br clear="left" />
<address>Matthias Andree <a
href="mailto:matthias.andree@gmx.de"><matthias.andree@gmx.de></a></address>
</body>
</html>
|
