]> Pileus Git - ~andy/fetchmail/blobdiff - design-notes.html
Add new design notes document.
[~andy/fetchmail] / design-notes.html
diff --git a/design-notes.html b/design-notes.html
new file mode 100644 (file)
index 0000000..ffd82bf
--- /dev/null
@@ -0,0 +1,112 @@
+<?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: 2003/02/28 11:26:47 $</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>SMTP forwarding</h2>
+
+<p>Fetchmails 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 &ndash; 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
+repsonsible 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> &ndash; 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.</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 &ndash; 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 &quot;Requisites for working multidrop
+    mailboxes&quot;</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: 2003/02/28 11:26:47 $</td>
+</tr>
+</table>
+
+<br clear="left" />
+<address>Matthias Andree <a
+       href="mailto:matthias.andree@gmx.de">&lt;matthias.andree@gmx.de&gt;</a></address>
+</body>
+</html>