[fetchmail]Bug? Fetchmail hangs when using SSL

Hello,

I think I've found a bug in fetchmail: while retrieving messages with
certain headers, it hangs. Unusually enough, it only does so when SSL
is enabled. Disabling SSL or changing the headers (by editing the
message on the IMAP server with Mutt)[0] eliminates the lockup.

As a preface, I've noticed reports of similar bugs while browsing the
fetchmail mailing list archives. The consensus seemed to be that these
bugs are usually caused by server problems. This would seem to fit, as
fetchmail usually bails out with a server timeout, like so:

[jbarilla(_at_)washer jbarilla]$ fetchmail
3 messages for jbarilla at mmp.princeton.edu.
reading message jbarilla(_at_)mmp(_dot_)princeton(_dot_)edu:1 of 3 (3017 header 
\
octets) ..fetchmail: timeout after 300 seconds waiting for \
server imap.princeton.edu.
fetchmail: client/server synchronization error while fetching \
from imap.princeton.edu
fetchmail: Query status=7 (ERROR)

[Long lines broken at \ marks in the interests of netiquette].

Because the problems seem to be unique to fetchmail, however (mutt
using SSL has no trouble with these messages), I thought it ought to
be reported. To produce the error, I invoked fetchmail with no
command-line options.

My OS is:  (uname -a)
Linux washer.barillari.org 2.4.18 #2 Mon Apr 1 15:50:54 EST 2002 i686 unknown

fetchmail -V produces the following:

[jbarilla(_at_)washer jbarilla]$ fetchmail -V
This is fetchmail release 5.9.11+SSL+NLS
Linux washer.barillari.org 2.4.18 #2 Mon Apr 1 15:50:54 EST 2002 i686 unknown
Taking options from command line and /home/jbarilla/.fetchmailrc
Idfile is /home/jbarilla/.fetchids
Fetchmail will forward misaddressed multidrop messages to jbarilla.
Options for retrieving from jbarilla(_at_)imap(_dot_)princeton(_dot_)edu:
  True name of server is imap.princeton.edu.
  Protocol is IMAP.
  All available authentication methods will be tried.
  SSL encrypted sessions enabled.
  Server nonresponse timeout is 300 seconds (default).
  Default mailbox selected.
  All messages will be retrieved (--all on).
  Fetched messages will not be kept on the server (--keep off).
  Old messages will not be flushed before message retrieval (--flush off).
  Rewrite of server-local addresses is enabled (--norewrite off).
  Carriage-return stripping is disabled (stripcr off).
  Carriage-return forcing is disabled (forcecr off).
  Interpretation of Content-Transfer-Encoding is enabled (pass8bits off).
  MIME decoding is disabled (mimedecode off).
  Idle after poll is disabled (idle off).
  Nonempty Status lines will be kept (dropstatus off)
  Delivered-To lines will be kept (dropdelivered off)
  Messages will be SMTP-forwarded to: localhost (default)
  Recognized listener spam block responses are: 571 550 501 554
  Single-drop mode: 1 local name(s) recognized.
  No UIDs saved from this host.

The greeting line from the IMAP server is:

Trying 128.112.129.114...
Connected to mmp.Princeton.EDU.
Escape character is '^]'.
* OK imap.Princeton.EDU IMAP4 service

[I think it's a Netscape/iPlanet server, but am not certain.]

Fetchmail is forwarding to Sendmail 8.11.6/8.11.6 on the local
machine.

I built fetchmail from source with RedHat's gcc:
[jbarilla(_at_)washer jbarilla]$ gcc -v 
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)

A sample message with those headers is attached. Unfortunately, I
can't reproduce the bug by uploading the message to the IMAP server
with mutt and trying to fetch it with fetchmail, because that changes
the date on the 'From ' line. A potential solution would be to place
the message on the server via FTP. I can't do this; it's on a sealed
server. I may be able to persuade one of the admins to do it, if it's
likely that that would be helpful. 

At present, I have the bad message (actually, a few of them) saved in
an alternate mailbox. Moving it between that mailbox and my INBOX
doesn't destroy its ability to cause the problem (it probably
preserves the headers -- I assume the IMAP server stamps the message
when it arrives on the machine, not when it moves between folders.)

Output from fetchmail -v -v is attached.

Does anyone have any suggestions? My inclination is to suspect a bug
in the IMAP server, but I'm at a loss to explain how mutt could avoid
it, given that it uses the same libraries.

Cordially,

Joe Barillari

[0] Editing the headers in Mutt also changes the 'From ' line, so there
is no way to revert changes completely (Mutt does not expose the
'From ' line for editing).

out
Description: Fetchmail output

badmsg
Description: bad message