Hello,
I sent this mail to this list earlier, but apparently it was neither
accepted nor rejected. So here's a retry:
Using fetchmail-5.9.13/Linux there is a problem with these weird
appointments from Notes(?). They solely consist of a mailheader with no body
at all. I cannot give you a whole message, but they usually look like this:
----8<---------------------------
Return-path: <oo(_dot_)bar(_at_)customer(_dot_)com>
Received: from xxxxxxx.xxxxx.xxx.xxx (unverified [xxx.xxx.xx.xx]) by
me01.web2000.activeisp.com
(Rockliffe SMTPRA 4.5.6) with ESMTP id
<B0025877515(_at_)me01(_dot_)web2000(_dot_)activeisp(_dot_)com> for
<p(_dot_)steiner(_at_)aconis(_dot_)com>;
Mon, 19 Aug 2002 09:08:58 +0200
Received: from xxxxxxx.xxxxxxxx.xxx (not verified[127.0.0.1]) by
xxxxxx.xxxxxx.xxx.xxx with MailMarshal (4,2,5,0)
id <B0002ace69>; Mon, 19 Aug 2002 09:08:13 +0200
X-Notes-Item: 1;
name=$PublicAccess
X-Notes-Item: 1;
type=300; name=SEQUENCENUM
X-Notes-Item: 3D9F01772A62B0E7C1256C1A0026FE4A;
name=APPTUNID
X-Notes-Item: 2;
name=$CSVersion
Subject: Testing fetchmail
=?iso-8859-1?Q?-_Pr=FCfung_fetchmail_=2830_Aug_14=3A?=
=?us-ascii?Q?00?= CEDT in Foobar - D.123
=?iso-8859-1?Q?-_B=FCro_aconis=29?=
X-Notes-Item: 19-Aug-2002 09:07:20 CEDT/19-Aug-2002 09:07:21 CEDT
=?us-ascii?Q?=2C_19-Aug-2002_09=3A08=3A21_CEDT=2F19-Aug-2002_09=3A08=3A21?=
CEDT
=?us-ascii?Q?=2C_19-Aug-2002_09=3A08=3A11_CEDT=2F19-Aug-2002_09=3A08=3A11?=
CEDT;
type=401; flags=0; name=RouteTimes
X-MIMETrack: Serialize by Router on XXXXXX/YYYYY(Release 5.0.8 |June 18, 2001)
at
19.08.2002 09:08:13
MIME-Version: 1.0
.
----8<---------------------------
When fetchmail reads this message it tells me:
reading message p(_dot_)steiner(_at_)ACONIS(_dot_)COM@webmail.activeisp.com:1
of 9 \
(5147 octets) fetchmail: message delimiter found while scanning headers
fetchmail: timeout after 60 seconds.
I guess the pop server is broken. The problem is that these mails get stuck
in the pop server and require manual removal. It would be nice if fetchmail
could deal gracefully with them.
The greeting line of the pop server is:
+OK MailSite POP3 Server 4.5.6.0 Ready
<133303176(_dot_)1030353433(_dot_)796(_at_)webmail(_dot_)activeisp(_dot_)com>
I tried using IMAP but it seems even more unreliable.
* OK MailSite IMAP4 Server 4.5.6.1 ready
Sometimes the advertised body length and the real length seem to differ by
about the number of lines in the mail. So I guess someone is converting
CR/LF to LF after counting the body size. I don't have a usable example at
the moment, because I can't find a way to retrive an unmodified version from
the server for comparison.
Greetings,
Peter Steiner