X-Git-Url: http://pileus.org/git/?a=blobdiff_plain;f=todo.html;h=754942c2e2516c07e6e00e74dcb51d45f8d2738f;hb=33cddbff323efcbae1503e91e6e65b2733da80c7;hp=762859499aeebce4a7a8394c14c9a05833d02a2c;hpb=80f45bfec11103cc60131759d9abd84114cf4657;p=~andy%2Ffetchmail diff --git a/todo.html b/todo.html index 76285949..754942c2 100644 --- a/todo.html +++ b/todo.html @@ -15,36 +15,26 @@ content="Known bugs and to-do items in fetchmail" />
-Back to Eric's Home Page | -Up to Site Map | -$Date: 2003/02/28 21:57:59 $ | -
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.
-Feature request from "Ralf G. R. Bergs" POP3 can't presently distinguish a wedged or down server from an
-authentication failure. Possible fix: after issuing a PASS command.
-wait 300 (xx) seconds for a "-ERR" or a "+OK" . If nothing comes
-back, retry at the next poll event and generate no errors. If we
-get an -ERR then log an authentication failure. Let IMAP code use UID and UIDVALIDITY rather than relying on flags
+that everyone can alter. 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
@@ -52,6 +42,30 @@ 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. Alan Munday suggests message change MULTIDROP without ENVELOPE: 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?).Serious
-Normal
+
+Cosmetic
+
+
+fetchmail: warning: MULTIDROP configuration for pop.example.org requires the envelope option to be set!
+fetchmail: warning: Check ENVELOPE option if fetchmail sends all mail to postmaster!
+
+
+Feature requests/Wishlist items
+
+
Move everything to using service strings rather that port -numbers, so we can get rid of ENABLE_INET6 everywhere but in -SockOpen (this will get rid of the kluge in rcfile_y.y).
+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.
-John Summerfield suggests that specifying a localname containing -@ ought to be treated as an smtpname option, with the domain part -removed for other purposes such as local-address matching.
+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.)
-The -Debian bug-tracking page for fetchmail lists other bug -reports.
+Matthias Andree writes:
-Back to Eric's Home Page | -Up to Site Map | -$Date: 2003/02/28 21:57:59 $ | -
++ +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.
+