Please ignore this thread.  The issue was a firewall misconfiguration, and in no way related to Mercury/32. 

This problem started small, with 2 MS Outlook users in different locations.  At that time I went in and changed MercuryS and MercuryP timeouts from 30 seconds to 90 seconds.  Since then this error has spread to at least 6 users across my network, and I must admit my limited knowledge of Mercury/32 is what is keeping me from fixing this issue.  Any troubleshooting tips, tricks, or educated guesses would be welcome.

> This problem started small, with 2 MS Outlook users in different
> locations.  At that time I went in and changed MercuryS and
> MercuryP timeouts from 30 seconds to 90 seconds.  Since then this
> error has spread to at least 6 users across my network, and I must
> admit my limited knowledge of Mercury/32 is what is keeping me from
> fixing this issue.  Any troubleshooting tips, tricks, or educated
> guesses would be welcome.


Could still be a simple timeout.  I would turn on session logging in MercuryP and have one of the problem users connect to see what happens.

Could the also be a packet fragmentation problem.   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.

I don't believe this is a nVidia chipset problem, as everything was working for months and then suddenly things cascaded into turmoil.  Thanks for the advice on the MTU though.  I will look into this immediaqtely.