aboutsummaryrefslogtreecommitdiffstats
path: root/tests
Commit message (Collapse)AuthorAgeFilesLines
* Fix: typo in test.Vincent Driessen2010-08-231-1/+1
|
* Bugfix for table output.Vincent Driessen2010-08-201-12/+12
| | | | | Apparently, RST requires the first line of tables to be drawn with minuses, not equal signs.
* Implemented the "reflow" command.Vincent Driessen2010-08-202-3/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For example, if you have the following table in your source file: Type Message Foo I like bananas very much. Even so much that I adore them. Position your cursor in it and call ReformatTable(). This makes the following: +======+===========================================================+ | Type | Message | +======+===========================================================+ | Foo | I like bananas very much. Even so much that I adore them. | +------+-----------------------------------------------------------+ But if you don't like these kinds of long wrappings, you can now simply remove (or add, for that matter) some of the '='-signs from the top row, like this: +======+================================+ | Type | Message | +======+===========================================================+ | Foo | I like bananas very much. Even so much that I adore them. | +------+-----------------------------------------------------------+ And then, call ReflowTable(): +======+================================+ | Type | Message | +======+================================+ | Foo | I like bananas very much. Even | | | so much that I adore them. | +------+--------------------------------+ This fixed issue #1.
* Add support for multi-line cell formatting.Vincent Driessen2010-08-191-2/+46
| | | | | | | | | | | | | | | | | For example, when given the following table: [['Foo', 'Bar'], ['x', 'This is a long line\nthat is spread out\nover multiple lines']] It will render as: +=====+=====================+ | Foo | Bar | +=====+=====================+ | x | This is a long line | | | that is spread out | | | over multiple lines | +-----+---------------------+
* Fixed the last failing test (stupid line ending bug).Vincent Driessen2010-08-191-3/+6
|
* Add line partitioner.Vincent Driessen2010-08-191-5/+17
| | | | | | | | | | | | | | | | | | Is able to parse tables of the form: +=====+=====================+ | Foo | Bar | +=====+=====================+ | x | This is a long line | | | that is spread out | | | over multiple lines | +-----+---------------------+ Into: [['Foo', 'Bar'], ['x', 'This is a long line\nthat is spread out\nover multiple lines']] The draw_table function needs to be written still, though.
* Remove CreateTable().Vincent Driessen2010-08-191-2/+2
| | | | This implementation only needs ReformatTable(), also for creation.
* Add join_rows helper function (necessary for joining long lines later on).Vincent Driessen2010-08-191-1/+29
|
* Add helper to set the fake vim cursor in tests.Vincent Driessen2010-08-191-2/+4
|
* Add ability to remove all empty columns automatically.Vincent Driessen2010-08-192-4/+20
|
* Use fixtures to make the tests more readable.Vincent Driessen2010-08-192-22/+28
|
* Added ability to parse existing tables.Vincent Driessen2010-08-191-0/+32
|
* Deal with spaces at the end of the line.Vincent Driessen2010-08-191-0/+5
|
* Fix: vim.buffer -> vim.current.bufferVincent Driessen2010-08-191-7/+7
|
* Add main logic to creating RST tables.Vincent Driessen2010-08-183-5/+142
|
* Change test root.Vincent Driessen2010-08-181-0/+14
="right">$Date$</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>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.</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>