Pileus Git - ~andy/fetchmail/blob - design-notes.html

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