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: 2003/02/28 11:26:47 $</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 is supposed to complement <a
  30     href="esrs-design-notes.html">Eric S. Raymond's (ESR's)
  31     design notes.</a> The new maintainers don't agree with some of the decisions
  32 ESR made previously, and the differences and new directions will be laid
  33 out in this document. It is therefore a sort of a TODO document, until
  34 the necessary code revisions have been made.</p>
  35
  36 <h2>SMTP forwarding</h2>
  37
  38 <p>Fetchmails multidrop and rewrite options will process addresses
  39 received from remote sites. Special care must be taken so these
  40 features cannot be abused to relay mail to foreign sites.</p>
  41
  42 <p>ESR's attempt to make fetchmail use SMTP exclusively failed,
  43 fetchmail got LMTP and --mda options &ndash; the latter has a lot of
  44 flaws unfortunately, is inconsistent with the SMTP forwarder and needs
  45 to be reviewed and probably bugfixed. --mda doesn't properly work with
  46 multiple recipients, it cannot properly communicate errors and is best
  47 avoided for now.</p>
  48
  49 <h2>Server-side vs. client-side state.</h2>
  50
  51 <h3>Why we need client-side tracking</h3>
  52
  53 <p>ESR asserted that server-side state were essential and those persons
  54 repsonsible for removing the LAST command from POP3 deserved to
  55 suffer. ESR is right in stating that the POP3 UID tracks which messages
  56 have been read <em>by this client</em> &ndash; and that is exactly what
  57 we need to do.</p>
  58
  59 <p>If fetchmail is supposed to retrieve all
  60 mail from a mailbox reliably, without being disturbed by someone
  61 occasionally using another client on another host, or a webmailer, or
  62 similar, then <em>client</em>-side tracking of the state is
  63 indispensable. This is also needed to match behavior to ETRN and ODMR.</p>
  64
  65 <h3>Present and future</h3>
  66
  67 <p>Fetchmail supports client-side state in POP3 if the UIDL option is
  68 used (which is strongly recommended). Similar effort needs to be made to
  69 track IMAP state by means of UIDVALIDITY and UID.</p>
  70
  71 <p>This will also mean that the UID handling code be revised an perhaps
  72 use one file per account or per folder.</p>
  73
  74 <h2>Concurrent queries/concurrent fetchmail instances</h2>
  75
  76 <p>ESR refused to make fetchmail query multiple hosts or accounts
  77 concurrently, on the grounds that finer-grained locks would be hard to
  78 implement portably.</p>
  79
  80 <p>The idea of using one file per folder or account to track UIDs on the
  81 client-side will make solving this locking problem easy &ndash; the lock can
  82 be placed on the UID file instead.</p>
  83
  84 <h2>Multidrop issues</h2>
  85
  86 <p>Fetchmail tries to guess recipients from headers that are not routing
  87 relevant, for instance, To:, Cc:, or Resent-headers (which are rare
  88 anyways). It is important that fetchmail insists on the real envelope
  89 operation for multidrop. This is detailed in <a
  90     href="http://home.pages.de/~mandree/mail/multidrop">my
  91     article &quot;Requisites for working multidrop
  92     mailboxes&quot;</a>.</p>
  93
  94 <p>As Terry Lambert pointed out in the FreeBSD-arch mailing list on
  95 2001-02-17 under the subject "UUCP must stay; fetchmail sucks",
  96 fetchmail performs DNS MX lookups to determine domains for which
  97 multidrop is valid, on the assumption that the receiving SMTP host
  98 upstream were the same as the IMAP or POP3 server.</p>
  99
 100 <hr />
 101 <table width="100%" cellpadding="0" summary="Canned page footer">
 102 <tr>
 103 <td width="30%">Back to <a href="index.html">Fetchmail Home Page</a></td>
 104 <td width="30%" align="right">$Date: 2003/02/28 11:26:47 $</td>
 105 </tr>
 106 </table>
 107
 108 <br clear="left" />
 109 <address>Matthias Andree <a
 110         href="mailto:matthias.andree@gmx.de">&lt;matthias.andree@gmx.de&gt;</a></address>
 111 </body>
 112 </html>