[quote user="bfluet"]

Two things to check.

1.  Make sure there is not a max message size set.  The setting is in the Download controls tab of the POP3 host configuration.

My setting is "0", which I presume means that there is no max size.  (The meaning of "0" is not covered in "Help".)

2.  Check the timeout settings.  There is one in the General tab of the Internet Mail options and one in the General tab of the POP3 host configuration.  The host configuration takes precedence but if it is set to zero the other one is used as the default.  More info in the help file.  I set mine at 120.

Aren't those two actually the SAME setting?  If I change one, the other is automatically changed as well.  I changed mine to 120, but I doubt that that is the problem.

[/quote]

I analyzed the session log clips I posted previously a little more.  I noticed something that I did not address last time, and there's the possibility that it points to Pegasus Mail as the culprit.

On the SUCCESSFUL downloads, Pegasus waited 0.266 secs, 0.281 secs, 0.282 secs, and 0.359 secs for the ISP server response.

On the UNSUCCESSFUL downloads, it appears that Pegasus waited 0.000 secs for all four responses--that is, it didn't wait at all!

I don't know why Pegasus would behave this way for downloads greater than some (arbitrary??) size.

I don't know of any setting anywhere in Pegasus for indicating the minimum length of time that Pegasus must wait for a server response.  (For example, in my case, it might be useful to specify that Pegasus must wait at least 0.5 sec (or 1 sec, or perhaps even more) for a response from the ISP server before it gives up (as it seems to do now on an instant basis).  Does such a setting already exist?  If so, where is it located, so that I can change it?

Thanks to all who can provide further help or information!

Harvey

I'm a longtime user of Pegasus Mail (since the mid 1990s) and have had very few problems that I've run into over the years.  However, starting last fall, sometime between September and November, I have no longer been able to receive emails that are larger than somewhere around 280KB.  (Previously, I'd been able to receive occasional emails at least 10MB in size.)

I thought that I had narrowed it down to my ISP (RCN). However, I've talked with the support team there, and, after looking at the problem, they got back to me and maintained that the problem has to be in my email client (Pegasus).  Since I know very little about the technical innards of Pegasus, I thought I'd share the problem here and see if anyone has any insights to a solution.

I've checked past forum messages, and, although some have similarities, none was really quite the same problem that I have. I decided to create some Internet session logs in Pegasus to see if there were any clues.  Here is what the ending of a successful Pegasus 4.63 email download looks like:

14:39:52.015 >> 0002 \0D\0A
14:39:52.015 >> 0003 .\0D\0A
14:39:52.015 << 0009 DELE 64\0D\0A
14:39:52.281 >> 0036 +OK message 64 marked for deletion\0D\0A
14:39:52.281 << 0006 QUIT\0D\0A
14:39:52.562 >> 0026 +OK deleted 1 message(s)\0D\0A
14:39:52.562 --- Connection closed normally at Mon, 23 Jun 2014

and here is what the ending of a successful Pegasus 4.70 email download looks like:

22:36:56.087: >> .<cr><lf>
22:36:56.087: << DELE 62<cr><lf>
22:36:56.369: >> +OK message 62 marked for deletion<cr><lf>
22:36:56.369: << QUIT<cr><lf>
22:36:56.728: >> +OK deleted 9 message(s)<cr><lf>
22:36:56.728: --- Connection closed normally at 23 Jun 2014,

You'll notice that the ISP's POP3 server responds to the Pegasus DELE and QUIT commands. Here is what the ending of an unsuccessful Pegasus 4.63 email download looks like:

14:35:54.265 >> 0002 \0D\0A
14:35:54.265 >> 0003 .\0D\0A
14:35:54.265 << 0009 DELE 20\0D\0A
14:35:54.296 << 0006 QUIT\0D\0A
14:35:54.296 --- Connection closed normally at Mon, 23 Jun 2014

and here is what the ending of an unsuccessful Pegasus 4.70 email download looks like:

23:25:32.666: >> .<cr><lf>
23:25:32.666: << DELE 43<cr><lf>
23:25:32.666: >>
23:25:32.681: << QUIT<cr><lf>
23:25:32.681: >>
23:25:32.681: --- Connection closed normally at 23 Jun 2014,

Nothing shows in response to the DELE and QUIT commands.  This results in a failed successful receipt of the email in the Pegasus system, even though the entire email has actually downloaded from the ISP's server!  It just does not finish up correctly, and I presume that the downloaded email is dumped by Pegasus into a cyber black hole.

The question is "why?"--and how can this problem be resolved?  I originally discussed with the ISP support team that their server seemed not to send anything larger than about 275KB in size.  After researching it, they subsequently insisted that their server DOES send large emails, and the Pegasus session logs above verify that fact (in the session logs, the full emails preceded the final lines shown above). Although I have a little technical knowledge, I'm stumped.  Any ideas?  Is Pegasus at fault here, since the full emails have actually downloaded from the POP3 server?  Any failure in the receipt process results in a halt to the download session.

Additionally, the idea of a size limit somewhere in Pegasus (or at my ISP??) continues to haunt me.  When I displayed the system messages following a startup of Pegasus, the following is what I saw:

Mon, 20:15:38  Loading local legacy folders from cache file...
Mon, 20:15:38  Spamhalter bayesian plugin 4.5.2.179 started.
Mon, 20:15:38  Spamhalter message size limit is: 250000 bytes
Mon, 20:15:38  Program started

That third line is what especially caught my eye.  Since I have NOT enabled Spamhalter, this shouldn't make any difference.  But the message size limit is so close to where the cutoff seems to be in my problem, it makes me wonder if there is some relationship.  I'm a little surprised that Spamhalter is automatically started even though I don't want it enabled at all--and BEFORE Pegasus starts up!.  Is there any way to ensure that the second and third lines will NEVER appear in the Pegasus startup sequence?  The third line is the ONLY suggestion of any limits whatsoever in my setup.  I have always ensured that, in all my configuration settings, there is never any message size limit.  I'm my own spam deleter (in selective download mode), and I can easily delete any outlandishly large email on the server before it is actually downloaded.  I don't have huge quantities of email, so this method works for me.  Anyway, could the third line above be responsible for the email message size limit I'm experiencing?

 Finally, do any potential solutions account for the fact that the problem seems to have started out of nowhere?

I'm (slightly) sorry for the quantity of information above, but, browsing other messages in this forum, I noticed that a common theme was the people answering the questions asking for full information that wasn't given in the original queries.  I tried to do that above.  I hope it is helpful to understanding the problem and to finding a resolution.  Thanks!

Harvey

Two things to check.

1.  Make sure there is not a max message size set.  The setting is in the Download controls tab of the POP3 host configuration.

2.  Check the timeout settings.  There is one in the General tab of the Internet Mail options and one in the General tab of the POP3 host configuration.  The host configuration takes precedence but if it is set to zero the other one is used as the default.  More info in the help file.  I set mine at 120.