aboutsummaryrefslogtreecommitdiffstats
path: root/website
Commit message (Expand)AuthorAgeFilesLines
...
* Link fetchmail-EN-2010-03 and update front page.Matthias Andree2010-10-163-7/+21
* Updated website for 6.3.18.Matthias Andree2010-10-121-13/+14
* Correct typo: IMAP7 -> UTF7.Matthias Andree2010-07-021-1/+1
* Link to Mailbox/UTF7 document in NEWS section.Matthias Andree2010-05-271-0/+10
* Hook Mailbox-Names-UTF7 document to build and website.Matthias Andree2010-05-271-0/+1
* Also upload to SourceForge.Matthias Andree2010-05-271-0/+12
* Fix timestamp on security website.Matthias Andree2010-05-061-1/+1
* Link CVE-2010-1167/fetchmail SA-2010-02.Matthias Andree2010-05-061-0/+8
* Update website for 6.3.17 release.Matthias Andree2010-05-062-9/+10
* Add a prominent pointer to c_rehash and FAQ #R14.Matthias Andree2010-04-181-0/+9
* Record 6.3.16.Matthias Andree2010-04-061-10/+8
* Update website to reflect 6.3.15 release.Matthias Andree2010-03-281-5/+5
* Add CVE for sdump X.509 display bug in 6.3.11-6.3.13.Matthias Andree2010-02-091-2/+3
* Split security information out from front page.Matthias Andree2010-02-082-19/+68
* Update documents/scripts after SVN -> Git move.Matthias Andree2010-02-062-26/+23
* Update website after release.Matthias Andree2010-02-052-7/+12
* Fix link to release notes.Matthias Andree2009-10-301-1/+1
* Update upload script, use local public_html stagingl.Matthias Andree2009-10-301-2/+6
* Release 6.3.13.Matthias Andree2009-10-301-5/+5
* Put 6.3.12 on front page.Matthias Andree2009-10-051-8/+8
* Also upload website to TU Dortmund mirror at http://mandree.home.pages.de/fet...Matthias Andree2009-08-181-4/+18
* Remove one version reference to avoid inconsistencies.Matthias Andree2009-08-061-1/+1
* Update website for 6.3.11 release.Matthias Andree2009-08-062-2/+4
* Bump version for security release.Matthias Andree2009-08-051-10/+6
* website: Update front page.Matthias Andree2009-07-021-15/+9
* Fix permissions for rsync uploads.Matthias Andree2009-05-241-1/+2
* WRT 6.3.8 security issues, replace 'for the nonce' by 'for 6.3.8'Matthias Andree2008-12-171-3/+3
* after 6.3.9 release, change will be -> has been fixed for CVE-2008-2711 and Matthias Andree2008-12-171-2/+2
* Fix HTML validator warnings, add HTML and CSS logos.Matthias Andree2008-11-271-15/+18
* Provide Security Alerts as a list, add intro, update solution.Matthias Andree2008-11-271-11/+18
* Since BerliOS's SSL setup is b0rked, use http:// rather than https://Matthias Andree2008-11-161-1/+1
* Update BerliOS release ID.Matthias Andree2008-11-161-1/+1
* Move 6.3.9 tag.Matthias Andree2008-11-161-33/+17
* Update timestamp.Matthias Andree2008-06-241-1/+1
* Mark CVE-2008-2711/fetchmail-SA-2008-01 revised 2008-06-24.Matthias Andree2008-06-241-4/+8
* Track website in separate SVN directory (mostly symlinks for now).Matthias Andree2008-06-1722-0/+505
generated by cgit v1.2.3 (git 2.46.0) at 2026-03-29 10:36:03 +0000
plement <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 &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 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 &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$</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>