diff options
| author | Matthias Andree <matthias.andree@gmx.de> | 2005-07-20 10:26:14 +0000 |
|---|---|---|
| committer | Matthias Andree <matthias.andree@gmx.de> | 2005-07-20 10:26:14 +0000 |
| commit | 66df9b24a8e0bebd7b355fe349abb93c684bc506 (patch) | |
| tree | 707025529c87fb57ba2a0f08c952536f8907bc6c /design-notes.html | |
| parent | 6169ea7ebd574d50136f3769efc86575ed54feb0 (diff) | |
| download | fetchmail-66df9b24a8e0bebd7b355fe349abb93c684bc506.tar.gz fetchmail-66df9b24a8e0bebd7b355fe349abb93c684bc506.tar.bz2 fetchmail-66df9b24a8e0bebd7b355fe349abb93c684bc506.zip | |
Add new design notes document.
svn path=/trunk/; revision=4126
Diffstat (limited to 'design-notes.html')
| -rw-r--r-- | design-notes.html | 112 |
1 files changed, 112 insertions, 0 deletions
diff --git a/design-notes.html b/design-notes.html new file mode 100644 index 00000000..ffd82bf8 --- /dev/null +++ b/design-notes.html @@ -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 – 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> – 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 – 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: 2003/02/28 11:26:47 $</td> +</tr> +</table> + +<br clear="left" /> +<address>Matthias Andree <a + href="mailto:matthias.andree@gmx.de"><matthias.andree@gmx.de></a></address> +</body> +</html> |