[quote user="azwolfman"]
I have opened and closed Pegasus 3 times. The second time it did actually create .wpm files which are not really any help as they make no sense to me.
00:51:57.241 >> 0016 +OK logged in.\0D\0A
00:51:57.241 << 0006 STAT\0D\0A
00:51:57.331 >> 0013 +OK 1 17100\0D\0A
00:51:57.331 << 0006 LIST\0D\0A
00:51:57.421 >> 0055 +OK POP3 clients that break here, they violate STD53.\0D\0A
00:51:57.421 >> 0009 1 17100\0D\0A
00:51:57.421 >> 0003 .\0D\0A
00:51:57.421 << 0008 RETR 1\0D\0A
00:51:58.333 >> 0026 +OK 17100 octets follow.\0D\0A
00:51:58.333 >> 0076 Return-path: <20070630MAR026T0000D7B@bouncedreports.discoverfinancial.com>\0D\0A
and so on...................
00:51:58.333 >> 0082 \09by naxp41l1.ihs.discoverfinancial.com (AIX5.3/8.13.4/8.13.4) id l626cDZr508206;\0D\0A
00:51:58.333 >> 0033 \09Mon, 2 Jul 2007 02:38:13 -0400\0D\0A
00:51:58.333 >> 0038 Date: Mon, 2 Jul 2007 02:38:13 -0400\0D\0A
00:51:58.333 >> 0078 Message-Id: <200707020638.l626cDZr508206@naxp41l1.ihs.discoverfinancial.com>\0D\0A
00:52:28.336 8: Socket read timeout.
00:52:48.345 << 0006 QUIT\0D\0A
00:52:48.435 >> 0041 Discover_eReport@discoverfinancial.com>\0D\0A
00:52:48.435 --- Connection closed normally at Mon, 02 Jul 2007 00:52:48. ---\0A\0A
I still can't receive mail. Can anyone help?
[/quote]
The system timed out at 30 seconds. What have you set the TCP/IP timeout to in the POP3 setup? If this is 30 seconds, and the server is a busy server, try increasing this to about 90-120 seconds and see if this fixes the problem. If it does not then I suspect there is a TCP/IP level Winsock problem. A POP3/SMTP transmission may fail if the MTU packet size is so large that a packet is fragmented. In many cases the receiving system router blocks the receiving servers "packets fragmented" response to the sending system using "MTU Discovery". These oversize packets are not accepted and so are resent. This results in a timeout, generally at the end of the message transmission but it can be anywhere in the process. You need to reduce the MTU size. Windows defaults to a 1500 MTU and many routers and DSL connections need 1492. You might simply want to turn off the MTU Discovery operation.
You might want to get a copy of SG TCP Optimizer that I find quite handy. http://www.speedguide.net/downloads.php This little utility will allow you to test your MTU for maximum size without fragmentation against specific servers. If will also make it easy to adjust the MTU.
And finally, does this computer, by chance, happen to have an NVidia NForce 4 chipset on the motherboard? If so, many other have had this exact problem, and it turned out to be an optimization setting for the built in NIC which caused the problems with packet fragmentation. Disabling the advanced optimization capability called "checksum offload" made all the problems of sending SMTP mail via WinPMail disappear.
[quote user="azwolfman"]<p>I have opened and closed Pegasus 3 times.&nbsp; The second time it did actually create .wpm files which are not really any help as they make no sense to me.</p>
<p>00:51:57.241 &gt;&gt; 0016 +OK logged in.\0D\0A
00:51:57.241 &lt;&lt; 0006 STAT\0D\0A
00:51:57.331 &gt;&gt; 0013 +OK 1 17100\0D\0A
00:51:57.331 &lt;&lt; 0006 LIST\0D\0A
00:51:57.421 &gt;&gt; 0055 +OK POP3 clients that break here, they violate STD53.\0D\0A
00:51:57.421 &gt;&gt; 0009 1 17100\0D\0A
00:51:57.421 &gt;&gt; 0003 .\0D\0A
00:51:57.421 &lt;&lt; 0008 RETR 1\0D\0A
00:51:58.333 &gt;&gt; 0026 +OK 17100 octets follow.\0D\0A
00:51:58.333 &gt;&gt; 0076 Return-path: &lt;<a href="mailto:20070630MAR026T0000D7B@bouncedreports.discoverfinancial.com%3E%5C0D%5C0A">20070630MAR026T0000D7B@bouncedreports.discoverfinancial.com&gt;\0D\0A</a></p>
<p>and so on...................</p>
<p>00:51:58.333 &gt;&gt; 0082 \09by naxp41l1.ihs.discoverfinancial.com (AIX5.3/8.13.4/8.13.4) id l626cDZr508206;\0D\0A
00:51:58.333 &gt;&gt; 0033 \09Mon, 2 Jul 2007 02:38:13 -0400\0D\0A
00:51:58.333 &gt;&gt; 0038 Date: Mon, 2 Jul 2007 02:38:13 -0400\0D\0A
00:51:58.333 &gt;&gt; 0078 Message-Id: &lt;<a href="mailto:200707020638.l626cDZr508206@naxp41l1.ihs.discoverfinancial.com%3E%5C0D%5C0A">200707020638.l626cDZr508206@naxp41l1.ihs.discoverfinancial.com&gt;\0D\0A</a>
00:52:28.336 8: Socket read timeout.
00:52:48.345 &lt;&lt; 0006 QUIT\0D\0A
00:52:48.435 &gt;&gt; 0041 <a href="mailto:Discover_eReport@discoverfinancial.com%3E%5C0D%5C0A">Discover_eReport@discoverfinancial.com&gt;\0D\0A</a>
00:52:48.435 --- Connection closed normally at Mon, 02 Jul 2007 00:52:48. ---\0A\0A</p>
<p>I still can't receive mail.&nbsp; Can anyone help?</p><p>[/quote]</p><p>The system timed out at 30 seconds.&nbsp; What have you set the TCP/IP timeout to in the POP3 setup?&nbsp; If this is 30 seconds, and the server is a busy server,&nbsp; try increasing this to about 90-120 seconds and see if this fixes the problem.&nbsp; If it does not then I suspect there is a TCP/IP level Winsock problem.&nbsp; A POP3/SMTP transmission may fail if the MTU packet size is so large that a packet is fragmented.&nbsp; In many cases the receiving system router blocks the receiving servers "packets fragmented" response to the sending system using "MTU Discovery".&nbsp; These oversize packets are not accepted and so are resent.&nbsp; This results in a timeout, generally at the end of the message transmission but it can be anywhere in the process.&nbsp; You need to reduce the MTU size. Windows defaults to a 1500 MTU and many routers and DSL connections need 1492.&nbsp; You might simply want to turn off the MTU Discovery operation.
You might want to get a copy of SG TCP Optimizer that I find quite handy.&nbsp; http://www.speedguide.net/downloads.php&nbsp; This little utility will allow you to test your MTU for maximum size without fragmentation against specific servers.&nbsp; If will also make it easy to adjust the MTU.&nbsp;
And finally, does this computer, by chance, happen to have an NVidia NForce 4 chipset on the motherboard?&nbsp; If so, many other have had this exact problem, and it turned out to be an optimization setting for the built in NIC which caused the problems with packet fragmentation. Disabling the advanced optimization capability called "checksum offload" made all the problems of sending SMTP mail via WinPMail disappear.
</p>