Fetchmail Bugs and To-Do Items

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.