This may be an old problem, but I've seen no signs of a fix for it...
I just came out of about 24 hours of a broken SSL setup on my main
mail server (which I don't run). During that time, connections to the
POP3/SSL and IMAP/SSL ports would succeed but immediately close,
similar to what you see what tcpwrappers blocks you. (The actual
problem on the server was an inaccessible certificate.)
I'm running fetchmail 5.9.11 on Debian; I haven't gone any higher than
that because the newer Debian packages depend on later versions of
libc, which I don't want to mess with yet. I was starting to make a
.deb of fetchmail 6.1.0 when the server began working again. But I
saw nothing in the release notes indicating that the problem I saw was
fixed. Specific versions are:
This is fetchmail release 5.9.11+NTLM+SDPS+SSL+NLS
Linux deckard 2.4.19 #1 Fri Sep 13 14:32:35 EDT 2002 i486 unknown
Anyway, the problem I saw was the same thing that Simon Barnes
reported back in May: after a few rounds of failed SSL-connect
attempts, the fetchmail daemon dies with signal 14 (SIGALRM). It
didn't happen on the first wait or the second, and it seemed to be
inconsistent after that.
Since I'm also polling a second server, it's kind of important to me
that fetchmail not die. :-)
And since the server that was causing this problem is working again,
it's no longer an immediate issue for me (nor one I have much time to
look into at the moment), but I thought it was important to mention it.
--
==============================| "A microscope locked in on one point
Rob Funk <rfunk(_at_)funknet(_dot_)net> |Never sees what kind of room that
it's in"
http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind"