Many thanks, Thomas!

<P>How do the experts handle this problem?  The download que gets blocked at some point due to an email Pmail cannot deliver.  Then either it tries all day and there are multiple downloads of the messages in the que (above or below?) the bad one OR, if you are there when it occurs, you see an error message for 20secs...a message which does not really indicate (to me) which email it is that is bad nor why.  I then go to the selective download and try to both download and delete the emails one or two at a time until I find the offending one and delete it .... with knowledge of the sender, but no awareness of the content.</P> <P>If there are 30 emails in the server que it can take quite some time to discover the bad one.  Often I am able to note that it is, say, the 14th, but I don't know if that is from the top or the bottom of the list.</P> <P>Also, is there a way to force ALL the bad email error message pop-ups to stay until closed OR can that only be done if one is there and sees the individual or particular message?</P>

<blockquote>If there are 30 emails in the server que it can take quite some time to discover the bad one.  Often I am able to note that it is, say, the 14th, but I don't know if that is from the top or the bottom of the list.</blockquote>Here's a few things to do. <p>1.  Use the File | Selective mail download to download the mail from the host.  Pick a bunch of files to be processed.  Usually the unsuccessful download is a huge file. </p><p>2.  Limit the number of messages downloaded in a session via the POP3 download controls to 1 and then down load every 30 seconds.  ;</p><p>3.  Increase the TCP/IP timeout to around 300 seconds.</p><p>4.  Turn off the MTU discovery.</p><p>This last one needs a bit of explanation.  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.  <font face="arial black,avant garde">You might simply want to turn off the MTU Discovery operation.</font> <font face="arial black,avant garde">(preferred)</font> </p>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. <p> </p><p> </p><p>.</p><p> </p><p> </p>