TODO   [plain text]


  (This file was generated from ../todo.html)

                         Fetchmail Bugs and To-Do Items

   Note that there is a separate TODO.txt document of different content
   than this.

   I try to respond to urgent bug reports in a timely way. But fetchmail
   is now pretty mature and I have many other projects, so I don't
   personally chase obscure or marginal problems. Help with any of these
   will be cheerfully accepted.

Serious

   Let IMAP code use UID and UIDVALIDITY rather than relying on flags that
   everyone can alter.

Normal

   POP3 hang when polling mail with NUL char that is rejected (David
   Greaves)
   https://lists.berlios.de/pipermail/fetchmail-devel/2004-October/000154.
   html

   It has been reported that multidrop name matching fails when the name
   to be matched contains a Latin-1 umlaut. Dollars to doughnuts this is
   some kind of character sign-extension problem. Trouble is, it's very
   likely in the BIND libraries. Someone should go in with a debugger and
   check this.

   The Debian bug-tracking page for fetchmail lists other bug reports.

Cosmetic

   Alan Munday suggests message change MULTIDROP without ENVELOPE:
fetchmail: warning: MULTIDROP configuration for pop.example.org requires the en
velope option to be set!
fetchmail: warning: Check ENVELOPE option if fetchmail sends all mail to postma
ster!

Feature requests/Wishlist items

   Feature request from "Ralf G. R. Bergs" <rabe@RWTH-Aachen.DE> "When
   fetchmail downloads mail and Exim+SpamAssassin detecs an incoming
   message as spam, fetchmail tries to bounce it. Unfortunately it uses an
   incorrect hostname as part of the sender address (I've an internal LAN
   with private hostnames, plus an official IP address and hostname, and
   fetchmail picks the internal name of my host.) So I'd like to have a
   config statement that allows me to explicitly set a senderaddress for
   bounce messages."

   In the SSL support, add authentication of Certifying Authority (Is this
   a Certifying Authority we recognize?).

   Laszlo Vecsey writes: "I believe qmail uses a technique of writing
   temporary files to nfs, and then moving them into place to ensure that
   they're written. Actually a hardlink is made to the temporary file and
   the destination name in a new directory, then the first one is
   unlinked. Maybe a combination of this will help with the fetchmail lock
   file."

   Maybe refuse multidrop configuration unless "envelope" is _explicitly_
   configured (and tell the user he needs to configure the envelope
   option) and change the envelope default to nil. This would prevent a
   significant class of shoot-self-in-foot problems.

   Given the above change, perhaps treat a delivery as "temporarily
   failed" (leaving the message on the server, not putting it into
   .fetchids) when the header listed in the "envelope" option is not
   found. (This is so you don't lose mail if you configure the wrong
   envelope header.)

   Matthias Andree writes:

     NOTE that the current code need optimization, if I have unseen
     articles 3 and 47, fetchmail will happily request LIST for articles
     3...47 rather than just 3 and 47. In cases where the message numbers
     are far apart, this involves considerable overhead - which could be
     alleviated by pipelining the list commands, which needs either
     asynchronous reading while sending the commands, or knowing the send
     buffer, to avoid deadlocks. Unfortunately, I don't have the time to
     delve deeper into the code and look around.

     Note that such a pipelining function would be of universal use, so
     it should not be in pop3.c or something. I'd think the best approach
     is to call a "sender" function with the command and a callback, and
     the sender will call the receiver when the send buffer is full and
     call the callback function for each reply received.

     See the ESMTP PIPELINING RFC for details on the deadlock avoidance
     requirements.
     __________________________________________________________________


    -2003 Eric S. Raymond <esr@thyrsus.com>
    2004- Matthias Andree <matthias.andree@gmx.de>