> Whenever the user sends his queued messages, a small red exclamation
> point button appears on the status bar. Clicking the button gives
> this error: "Pegasus Mail has encountered an unidentified error on
> your TCP/IP network. The error code returned to Pegasus Mail was 0H.
The Zero Hex error says Pegasus Mail can't connect to the server and there was not error code provided. You should have the user Go to File | Network configuration | General and turn on "Create Internet session logs (advanced diagnostic use only)"
Checking this control tells Pegasus Mail to create special log files that show the entire exchange of information between it and the servers it connects to. Each session will be created in a file called TCPxxxx.WPM in your home mailbox directory (the "xxxx" is replaced by four digits). Creating session logs will slow down the performance of your system somewhat, and you should be aware that any username and password information exchanged between Pegasus Mail and the server will be shown in the log, *even* if you use SSL to secure the connection. Session logs are primarily useful if you need to debug a problem between Pegasus Mail and one of the servers it connects to - you should enable the option only on instructions from a system administrator or from Pegasus Mail technical support. [ Technical note: this control has the same effect as using a "-Z 32" commandline switch when you run Pegasus Mail ]
You can now try again to send/receive the mail and then look at the resulting TCP/IP debug file. Review of this file will tell you exactly what is going on between WinPMail and the server.
> Further information on this problem is unavailable - please check
> that your TCP/IP software is correctly installed and configured and
> there are no problems with your TCP/IP network at present." We are
> on an extremely large university network, so changes to the network
> are out of the question. Also, no other users of Pegasus are
> reporting any problems.
Two things come to mind, the timeout is set too low or there is a packet fragmentation problem. He first should go to Tools | Internet options | (Sending) SMTP, edit the SMTP setup and set the timeout to something like 180 seconds,
If this does not help then I suspect packet fragmentation. The POP3/SMTP transmissions 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.
> Occasionally, when sending messages, he receives a "Mail Delivery
> Failure" message saying "Delivery has failed..." due to a
> nondescript "TCP/IP error while processing job." Oddly enough, if
> you check, the e-mail actually WAS sent out. The Mail delivery
> failure is obviously coming from Pegasus, and not our Exchange
> servers.
Another sign of packed fragmentation. The SMTP process fails when the .<CR><LF> end of message is sent via a timeout but in fact the message is processed by the receiving server. Pegasus Mail gets a failure and the mail is delivered by the host. It should not deliver since there was a failure in the sending process but since it has the entire message it's not necessarily a bad thing.
&gt; Whenever the user sends his queued messages, a small red exclamation
&gt; point button appears on the status bar. Clicking the button gives
&gt; this error: "Pegasus Mail has encountered an unidentified error on
&gt; your TCP/IP network. The error code returned to Pegasus Mail was 0H.
The Zero Hex error says Pegasus Mail can't connect to the server and there was not error code provided.&nbsp; You should have the user Go to File | Network configuration | General and turn on "Create Internet session logs (advanced diagnostic use only)" &nbsp;
Checking this control tells Pegasus Mail to create special log files that show the entire exchange of information between it and the servers it connects to. Each session will be created in a file called TCPxxxx.WPM in your home mailbox directory (the "xxxx" is replaced by four digits). Creating session logs will slow down the performance of your system somewhat, and you should be aware that any username and password information exchanged between Pegasus Mail and the server will be shown in the log, *even* if you use SSL to secure the connection. Session logs are primarily useful if you need to debug a problem between Pegasus Mail and one of the servers it connects to - you should enable the option only on instructions from a system administrator or from Pegasus Mail technical support. [ Technical note: this control has the same effect as using a "-Z 32" commandline switch when you run Pegasus Mail ]
You can now try again to send/receive the mail and then look at the resulting TCP/IP debug file.&nbsp; Review of this file will tell you exactly what is going on between WinPMail and the server.
&gt; Further information on this problem is unavailable - please check
&gt; that your TCP/IP software is correctly installed and configured and
&gt; there are no problems with your TCP/IP network at present." We are
&gt; on an extremely large university network, so changes to the network
&gt; are out of the question. Also, no other users of Pegasus are
&gt; reporting any problems.
Two things come to mind, the timeout is set too low or there is a packet fragmentation problem.&nbsp; He first should go to Tools | Internet options | (Sending) SMTP, edit the SMTP setup and set the timeout to something like 180 seconds, &nbsp;
If this does not help then I suspect packet fragmentation.&nbsp; The POP3/SMTP transmissions 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.
&gt; Occasionally, when sending messages, he receives a "Mail Delivery
&gt; Failure" message saying "Delivery has failed..." due to a
&gt; nondescript "TCP/IP error while processing job." Oddly enough, if
&gt; you check, the e-mail actually WAS sent out. The Mail delivery
&gt; failure is obviously coming from Pegasus, and not our Exchange
&gt; servers.
Another sign of packed fragmentation.&nbsp; The SMTP process fails when the .&lt;CR&gt;&lt;LF&gt; end of message is sent via a timeout but in fact the message is processed by the receiving server.&nbsp;&nbsp; Pegasus Mail gets a failure and the mail is delivered by the host.&nbsp; It should not deliver since there was a failure in the sending process but since it has the entire message it's not necessarily a bad thing.
