| Back to Eric's Home Page - | Up to Site Map - | $Date: 2001/07/06 01:18:42 $ - |
- -Errors in RCPT TO responses aren't handled gracefully. This shows up -if you enable FEATURE(delay_checks, friend) in sendmail, so that you -can accept mail to postmaster from sites otherwise blocked by my -access database. The effect of this feature is that the MAIL FROM: -address is always accepted OK, and any rejection of the sender is -delayed until the RCPT TO: part of the SMTP transaction. This includes -rejects such as 553 for invalid sender address. In this configuration -fetchmail cannot deliver mail with invalid sender addresses, so you'll -get lots of bounce messages when some spammers hit your mailbox (a -pair of bounces every time fetchmail runs; one to FETCHMAIL-DAEMON -generated by sendmail when fetchmail's bounce to the spammer is -rejected, and one postmaster notify for that bounce). The problem is -that fetchmail only recognises the 553 response in reply to MAIL FROM: -and not RCPT TO:, see the unused code near sink.c:690. A really -correct fix would callling a modified version of handle_smtp_error -that doesn't RSET the connection. - -Using LMTP alias with a local name that is not a full name fails horribly -(the LMTP port never gets stripped off the name). - -The UIDL code seems rather broken. It's a nasty swamp. Somebody who -actually uses it should fix it -- every time I try I seem to make -things worse....
- -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.
- -SMTP authentication a la RFC 2554 ought to be supported. The Exim -reference has a - -whole chapter on this topic.
- -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.
- -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."
- -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).
- -The Debian -bug-tracking page for fetchmail lists other bug reports.
- -
| Back to Eric's Home Page - | Up to Site Map - | $Date: 2001/07/06 01:18:42 $ - |
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.
+ +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 +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:
++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 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.
+