<p>For my money, it is a session time limit that is tripping. </p><p>I would suggest first to limit the downloading to small messages. Go to Internet Options in menu Tools and select Receiving POP3 . Click Edit on your active profile name.Then click Download Controls tab.  Once there on the item "Do not download > n bytes" enter a value like 50000, and for the default action at the bottom of the screen click "Leave on server".</p><p>Restart Pegasus Mail and attempt a normal email download. All your normal messages should get downloaded ok.   Then using Selective Download (from menu File/Selective download) select one message at a time with "Mark" and "Retrieve" (do not click Delete option). If you get a problem, that will indicate the problem message.  Repeat till all messages have been downloaded.  Don't forget to undo, the download size limit and default action set above, and use Selective download to Delete all the messages selectively downloaded.</p><p>HTH</p><p> <span style="font-size: 10pt;">Martin.</span></p>

<p>In a previous thread "Cannot receive emails larger than about 280KB"<http://community.pmail.com/forums/thread/41487.aspx>, I described a problem I am having receiving large emails.  I read the advice of bfluet as well as that of the late Thomas Stephenson (whom I always deeply respected in the past) and others in searching the forum messages for answers.</p><p>Following all of this advice, I have done the following with my copy of Pegasus 4.7:</p><blockquote><p>(1) changed general default timeout for network connections to 300 seconds</p><p>(2) changed receiving timeout to 300 seconds</p><p>(3) changed sending timeout to 300 seconds</p><p>(4) using SG TCP Optimizer, changed MTU value to 1244 (the optimal value for my 56K dialup access from testing)</p><p>(5) using SG TCP Optimizer, changed MTU Discovery value alternately to both Yes and No  [didn't seem to make any difference] </p><p>(6) using SG TCP Optimizer, changed Checksum Offloading to disabled</p></blockquote><p>However, I <u>still</u> cannot receive any of the larger emails that are waiting on my ISP's server.  The situation is starting to get to a critical point because, when using selective download, I have to download an increasing number of headers for undownloadable messages (nearing 100, about 3-6 more each day) in addition to the messages that I <u>can</u> download, and this takes longer and longer each day (which is particularly noticeable with dialup access).</p><p>A typical beginning of a session log looks like this (proving the general timeout value):</p><blockquote><p>14:24:37.796: --- 30 Jun 2014, 14:24:37.796 --- 14:24:37.796: Connect to 'pop.rcn.com', timeout 300 seconds. 14:24:39.031: >> +OK POP3 ready<cr><lf> 14:24:39.031: << USER xxxxxxxxxx<cr><lf> 14:24:39.265: >> +OK<cr><lf> 14:24:39.265: << PASS xxxxxxxxxx<cr><lf> 14:24:39.515: >> +OK server ready<cr><lf> 14:24:39.515: << STAT<cr><lf> 14:24:39.750: >> +OK 89 86292310<cr><lf> 14:24:39.750: << LIST<cr><lf> 14:24:40.140: >> +OK 89 messages<cr><lf></p></blockquote><p>I assume that the third line from the bottom indicates there are 89 messages totalling 86,292,310 bytes.  I don't know offhand how much email storage each account has on my ISP, but it might possibly be approaching the limit--hence, my urgency in trying to get this problem resolved. </p><p>Here are several endings of session logs, so that you can see the typical pattern of what's happening with <u>unsuccessful</u> downloads (to my knowledge these always follow an attachment, but I can't say that in general with 100% certainty):</p><blockquote><p>12:56:04.361: << DELE 27<cr><lf> 12:56:04.377: >> 12:56:04.377: << QUIT<cr><lf> 12:56:04.377: >> 12:56:04.377: --- Connection closed normally at 28 Jun 2014, 12:56:04.377. --- </p><p>13:02:53.861: << DELE 27<cr><lf> 13:02:53.861: >> 13:02:53.877: << QUIT<cr><lf> 13:02:53.877: >> 13:02:53.877: --- Connection closed normally at 28 Jun 2014, 13:02:53.877. --- </p><p>13:14:25.471: << DELE 27<cr><lf> 13:14:25.471: >> 13:14:25.471: << QUIT<cr><lf> 13:14:25.471: >> 13:14:25.486: --- Connection closed normally at 28 Jun 2014, 13:14:25.486. --- </p><p>01:04:12.218: << DELE 43<cr><lf> 01:04:12.218: >> 01:04:12.218: << QUIT<cr><lf> 01:04:12.218: >> 01:04:12.218: --- Connection closed normally at 30 Jun 2014, 1:04:12.218. ---</p><p>14:28:55.718: << DELE 69<cr><lf> 14:28:55.718: >> 14:28:55.718: << QUIT<cr><lf> 14:28:55.718: >> 14:28:55.734: --- Connection closed normally at 30 Jun 2014, 14:28:55.734. --- </p></blockquote><blockquote><p>14:30:58.937: << DELE 69<cr><lf> 14:30:58.937: >> 14:30:58.937: << QUIT<cr><lf> 14:30:58.937: >> 14:30:58.937: --- Connection closed normally at 30 Jun 2014, 14:30:58.937. --- </p><p>17:18:35.656: << DELE 69<cr><lf> 17:18:35.656: >> 17:18:35.656: << QUIT<cr><lf> 17:18:35.656: >> 17:18:35.656: --- Connection closed normally at 30 Jun 2014, 17:18:35.656. --- </p></blockquote><p> You'll notice that the final commands all occur within the same thousandth of a second, or else within a couple of hundredths of a second.  I point this out because <u>successful</u> downloads have a completely different pattern.  Here are several examples:</p><blockquote><p>17:47:42.872: << DELE 86<cr><lf> 17:47:43.106: >> +OK message 86 marked for deletion<cr><lf> 17:47:43.106: << QUIT<cr><lf> 17:47:43.637: >> +OK deleted 1 message(s)<cr><lf> 17:47:43.637: --- Connection closed normally at 27 Jun 2014, 17:47:43.637. --- </p><p>00:12:49.443: << DELE 98<cr><lf> 00:12:49.693: >> +OK message 98 marked for deletion<cr><lf> 00:12:49.693: << QUIT<cr><lf> 00:12:50.568: >> +OK deleted 18 message(s)<cr><lf> 00:12:50.568: --- Connection closed normally at 28 Jun 2014, 0:12:50.568. --- </p><p>09:54:52.361: << DELE 85<cr><lf> 09:54:52.596: >> +OK message 85 marked for deletion<cr><lf> 09:54:52.596: << QUIT<cr><lf> 09:54:53.018: >> +OK deleted 7 message(s)<cr><lf> 09:54:53.018: --- Connection closed normally at 28 Jun 2014, 9:54:53.018. --- </p><p>12:32:34.299: << RSET<cr><lf> 12:32:34.533: >> +OK 0 message(s) undeleted<cr><lf> 12:32:34.533: << QUIT<cr><lf> 12:32:35.268: >> +OK md04.rcn.cmh.synacor.com Zimbra POP3 server closing connection<cr><lf> 12:32:35.268: --- Connection closed normally at 28 Jun 2014, 12:32:35.268. ---</p><p>12:35:23.674: << RSET<cr><lf> 12:35:23.924: >> +OK 0 message(s) undeleted<cr><lf> 12:35:23.924: << QUIT<cr><lf> 12:35:24.174: >> +OK md04.rcn.cmh.synacor.com Zimbra POP3 server closing connection<cr><lf> 12:35:24.174: --- Connection closed normally at 28 Jun 2014, 12:35:24.174. --- </p></blockquote><blockquote><p>12:39:27.377: << DELE 71<cr><lf> 12:39:27.611: >> +OK message 71 marked for deletion<cr><lf> 12:39:27.611: << QUIT<cr><lf> 12:39:27.877: >> +OK deleted 1 message(s)<cr><lf> 12:39:27.877: --- Connection closed normally at 28 Jun 2014, 12:39:27.877. --- </p>01:12:26.968: << DELE 88<cr><lf> 01:12:27.218: >> +OK message 88 marked for deletion<cr><lf> 01:12:27.218: << RETR 118<cr><lf> 01:12:27.640: >> +OK message follows<cr><lf> </blockquote><blockquote>01:12:32.906: << DELE 96<cr><lf> 01:12:33.140: >> +OK message 96 marked for deletion<cr><lf> 01:12:33.140: << RETR 87<cr><lf> 01:12:33.609: >> +OK message follows<cr><lf> </blockquote><blockquote>01:16:47.578: << DELE 95<cr><lf> 01:16:47.812: >> +OK message 95 marked for deletion<cr><lf> 01:16:47.812: << QUIT<cr><lf> 01:16:48.468: >> +OK deleted 37 message(s)<cr><lf> 01:16:48.468: --- Connection closed normally at 30 Jun 2014, 1:16:48.468. --- </blockquote><blockquote>14:24:54.000: << DELE 88<cr><lf> 14:24:54.234: >> +OK message 88 marked for deletion<cr><lf> 14:24:54.234: << QUIT<cr><lf> 14:24:54.593: >> +OK deleted 4 message(s)<cr><lf> 14:24:54.593: --- Connection closed normally at 30 Jun 2014, 14:24:54.593. --- </blockquote><p> You'll notice that Pegasus here has waited at least 0.2 - 0.7 second between commands and responses, <u>far</u> <u>longer</u> than the figures found in the unsuccessful downloads shown earlier.  As a matter of fact, generally speaking, Pegasus seems to wait <u>not</u> <u>at</u> <u>all</u> for responses in the unsuccessful downloads.  Is this a bug?  I think it ought to wait up to at least one second (or more) for a response from the server. Why does Pegasus not wait??  Is there any setting in Pegasus that will cause it to wait for at least a specific minimum of time for a server response before "giving up" (or just "proceeding willynilly" to the next step)?</p><p> Or is there some other explanation?  I've done everything that advisers here have suggested over the years, but, as I said, I still cannot get Pegasus to properly receive a large message.  It downloads the message (the session log proves that), but it "refuses" to complete the download properly.</p><p>HELP!!!  Large messages are piling up in my ISP email account, and at the moment I can't download them with Pegasus.</p><p> </p><p>Harvey</p><p> </p>

<p>More info about the problem:</p><p> This seems to be exactly the same problem as in the thread <http://community.pmail.com/forums/thread/38009.aspx> -- no final answer there either.  Pegasus has worked for years and then suddenly this malfunction appears. </p><p>One commonality among all of my message that won't finalize the download is that they all have attachments, which puts the size of these messages in the range of around 240K and higher.  The problem never seems to happen with messages that don't have attachments.  Just to repeat the idea at the end of my original message:</p><p>The problem is NOT that the messages and attachments don't transfer (download) to my computer--the server sends them, and my computer receives them--the session logs prove this.  The problem seems to be that Pegasus doesn't properly FINALIZE the download (that is, accept the message and attachment into the Pegasus Mail system)--and the session logs prove this, too (see original message). </p><p> </p><p>Harvey</p><p> </p>