I never had any problems with IMAP and Pegasus Mail over the last 6
months, testing Pegasus in our software and hardware environment in the
office (privately I'm using Pegasus Mail since version 2.4x).
But this has changed. The reason might be that in the past I only
received short messages with Pegasus, but recently I had to download
some larger mails with data files as enclosures (a few hundred KB to
about one MB) and the problems occur only while downloading such larger
messages.
I made a log to see what happened and there are some things that look
strange to me but I'm not very familiar with the IMAP protocol. I'm not
able to decide if this is a Pegasus related problem or a problem of the
IMAP server. Maybe someone here can give me some enlightenment. Here are
the shortened logs, with some comments added and slightly re-formatted:
Connect to '<servername>' port 143, timeout 60.
14:44:12 >> 0090 * OK Microsoft Exchange IMAP4rev1 server version
5.5.2232.11 (<Servername>) ready\0D\0A
14:44:12 << 0048 A1 LOGIN "<user>" "<password>"\0D\0A
14:44:12 >> 0024 A1 OK LOGIN completed.\0D\0A
14:44:12 << 0019 A2 SELECT "INBOX"\0D\0A
14:44:12 >> 0012 * 1 EXISTS\0D\0A
14:44:12 >> 0012 * 0 RECENT\0D\0A
14:44:12 >> 0052 * FLAGS (\\Seen \\Answered \\Flagged \\Deleted \\
Draft)\0D\0A
14:44:12 >> 0066 * OK [PERMANENTFLAGS (\\Seen \\Answered \\Flagged \\
Deleted \\Draft)]\0D\0A
14:44:12 >> 0045 * OK [UIDVALIDITY 54311] UIDVALIDITY value.\0D\0A
14:44:12 >> 0038 A2 OK [READ-WRITE] SELECT completed.\0D\0A
14:44:12 << 0206 A3 FETCH 1 (FLAGS UID RFC822.SIZE BODY.PEEK[HEADER.
FIELDS (FROM SUBJECT ...)])\0D\0A
14:44:12 >> 0225 * 1 FETCH (FLAGS (\\Seen) UID 1090 RFC822.SIZE 644132
BODY[HEADER.FIELDS (FROM SUBJECT ...)] {228}\0D\0A
14:44:12 >> 0039 From: ***********\0D\0A
14:44:12 >> 0018 Subject: *********\0D\0A
14:44:12 >> 0029 To: myself@office\0D\0A
14:44:12 >> 0039 Date: Thu, 22 Jun 2000 10:38:26 +0200\0D\0A
14:44:12 >> 0019 MIME-Version: 1.0\0D\0A
14:44:12 >> 0064 Content-type: Multipart/Mixed; boundary=Message-
Boundary-12283\0D\0A
14:44:12 >> 0018 Priority: normal\0D\0A
14:44:12 >> 0002 \0D\0A
14:44:12 >> 0003 )\0D\0A
14:44:12 >> 0024 A3 OK FETCH completed.\0D\0A
14:44:16 << 0055 A4 UID FETCH 1090 (FLAGS UID RFC822.SIZE BODY.
PEEK[])\0D\0A
14:44:16 >> 0070 * 1 FETCH (FLAGS (\\Seen) UID 1090 RFC822.SIZE
644132 BODY[] {644132}\0D\0A
Okay, transmission of message starts here and everything seems to
work fine. But suddenly, while data still being downloaded...
14:44:17 >> 0078 gLHgoqMu2AXnevBiJbwDjVB4CUlKQQdIwOEOe1gP8fuwiEdM....
14:44:17 >> 0078 CsZDDYEHAACBBwAAFAAAAEhlbHBfaW1nL01pc3RfQlcuZ2lm....
14:44:17 >> 0078 a4mceJy0hLTTlcLmnNf/q+b/uub/r+b/uuz/uvH/xPb/xP//....
14:44:18 << 0025 A5 UID FETCH 1090 FLAGS\0D\0A
...Pegasus seems to send another UID FETCH command for the same
message. And a few seconds later...
14:44:18 >> 0078 ii/CWV+me0kKFqOeVgcqX3s6Zmep651Kl6iJdlropXzCWmKq....
14:44:18 >> 0078 jsqplwT+DJvjXM8GmeymQNxpamXEcrhjtaxGS623ruGKpKxg....
14:44:18 >> 0078 +mmoCIomnnPpQstrrS362uBqH/l6XJwziisthDgJZHB6yHSG....
14:44:22 << 0025 A6 UID FETCH 1090 FLAGS\0D\0A
...this happens again...
14:44:22 >> 0078 nGk1esih6ut4W/tpoWctbRygNWzJtZzWmOIqdp0kp+zfiDSG....
14:44:22 >> 0078 +u+9CBs8macxkRc+sGCCeqq4Kjo2utpOiBvuYVtJHLLnAlSS....
14:44:25 << 0025 A7 UID FETCH 1090 FLAGS\0D\0A
...and again. After three FETCH commands Pegasus decides...
14:44:25 >> 0078 7qYduvkcYLUNE3mSFRvD5cPShBuKItpTALRtjPkAK+iK65i8....
14:44:25 >> 0078 +rE+8bxP6UTJqMeUltMZXRPvbPp8hAtM97Q7KMWoX9P0g9v7....
14:44:27 << 0010 A8 CLOSE\0D\0A
...to close connection and...
14:44:27 >> 0078 1jhNM1AAQgAAAAcAUFJDIFNJZlAAAP////8AAAAAAAAAAAAA....
14:44:27 >> 0078 AJB+AACQfgAAkH4AAAAAd2Nsb2NrREEucHJjAAC1OW1sG9eR....
14:44:27 >> 0078 +xSXsiiKktaMJbGUGudDtbUilx8Stcssl/rwGQddnQTORxEh....
14:44:27 << 0011 A9 LOGOUT\0D\0A
... logs out while data still being transferred:
14:44:27 >> 0078 0nw4HQiSjj29r/5LNNT7ObhTm1uD9tme3lde6O8dBPhJ+GfL....
14:44:27 >> 0078 b2xsDA+DY2cQbMhzcVtI+C3CGyz43fBrwu8smVqtFNiEb4Nm....
14:44:27 >> 0078 +bhrmSZHUdfowT95XD2He4pPFgxZN8jFaNvHAXeNCq6wv3RN....
--- Connection closed normally at Thu, 22 Jun 2000 14:44:27. ---
Regards, Claus
--
UBE/UCE mails to any of my addresses are definitely not allowed. Sending
such mails to my addresses constitutes an agreement of the sender and/or
responsible but non cooperating provider to pay me a downloading, pro-
cessing and archiving fee of US$ 500,00.
--
+--------------------------------------------------+
| David J. Kocmoud (Official Pegasus Mail and Mercury Tech Support Member)
| ** I can only return your call collect to toll phone numbers **
| 2403 Colgate Circle, College Station, Texas 77840-4615 USA
| Voice: (979) 696-8586 (evenings)
| E-Mail: david-...@bigfoot.com
| Home Page: http://sago.tamu.edu/users/davek/
+--------------------------------------------------+
Claus Ruge <junkmail...@gmx.li> wrote in message
news:8itjju.3...@ruge-online.de...
On Sun, 2 Jul 2000 14:40:07 -0500, David Kocmoud wrote:
>According to the IMAP server, the message was supposedly 644132 bytes long.
>I wonder if MS Exchange actually counted the message's size incorrectly such
>that WinPMail thought it ended sooner. I'll have to check with David Harris
>on this one.
I could check the file size and it was 644132 bytes long.
>We may need to see the full exact debug message though (username and
>password removed, of course).
From the log I posted to the group I only snipped out some megs of
base64 encoded data, but it contains all the conversation between
Pegasus and the IMAP server. And I fear I already deleted the complete
log.....
BTW, it was possible to download such large files with other programs
such as Netscape and "The Bat!". This doesn't mean that Pegasus is
faulty, it could also be that those two programs are more tolerant of
misbehaving servers.