fetchmail-friends
[Top] [All Lists]

[fetchmail]Re: Fetchmail-friends digest, Vol 1 #357 - 9 msgs

2002-05-02 06:53:57
try to edit the size of you MTA. that's is my problem
before.. then i tried to edit my sendmail.cf and
change the max size of mail.

--- fetchmail-friends-request(_at_)lists(_dot_)ccil(_dot_)org wrote:
Send Fetchmail-friends mailing list submissions to
      fetchmail-friends(_at_)lists(_dot_)ccil(_dot_)org

To subscribe or unsubscribe via the World Wide Web,
visit


http://lists.ccil.org/mailman/listinfo/fetchmail-friends
or, via email, send a message with subject or body
'help' to
      fetchmail-friends-request(_at_)lists(_dot_)ccil(_dot_)org

You can reach the person managing the list at
      fetchmail-friends-admin(_at_)lists(_dot_)ccil(_dot_)org

When replying, please edit your Subject line so it
is more specific
than "Re: Contents of Fetchmail-friends digest..."


Today's Topics:

   1. Bug? Fetchmail hangs when using SSL (Joseph
Barillari)
   2. Multiple recipients. (Henri van Riel)
   3. Message delimiter found while scanning headers
(Nils Holland)
   4. fetchmail hangs !! (Lokesh Khanna)
   5. Re: Multiple recipients. (Rob MacGregor)
   6. Re: Fetchmail dies silently in daemon mode on
HP-UX
       10.20 (Bjorn Wiren)
   7. Re: fetchmail hangs !! (Rob MacGregor)
   8. Fetchmail still refuses to dump spam even with
'antispam' set. (Chris Green)

--__--__--

Message: 1
To: fetchmail-friends <fetchmail-friends(_at_)ccil(_dot_)org>
From: Joseph Barillari
<joseph+fetchmail(_at_)barillari(_dot_)org>
Date: Wed, 01 May 2002 12:39:43 -0400
Subject: [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 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com


<Prev in Thread] Current Thread [Next in Thread>
  • [fetchmail]Re: Fetchmail-friends digest, Vol 1 #357 - 9 msgs, eduardo rosales <=