AntiSpam -- 10054 Connection Reset by Peer

Hi,

I am trying to understand a problem with my anti-Spam software.

Every so often I get a piece of spam that will cause indigestion for Mailwasher. What happens is that Mailwasher will do its thing populating the list of messages on the POP server and while doing so will begin its RBL lookups, but certain pieces of spam will cause the POP server to terminate the connection with Mailwasher before it can enumerate the problem message -- error message: Connection Reset by Peer.

Usually I can then close Mailwasher and run G-Lock SpamCombat, which is my backup program. Typically G-Lock will not encounter the same problem. It will enumerate messages on the POP server and will allow me to delete the offending piece of Spam.

Today, however, I had a piece of Spam that caused the POP server to reset the connection with G-Lock, not while it was enumerating messages but while it was trying to delete the problem message. Error message: 10054 Connection Reset by Server.

Interestingly the POP server never resets the connection when any e-mail client accesses a problem message. It will happily allow the problem Spam to be downloaded and deleted from the server.

Looking through G-Lock's support forums, I found the suggestion that anti-virus e-mail scanning be turned off as a work around measure. And indeed, disabling e-mail scanning does seem to make the problem go away. Both Mailwasher and G-Lock will happily enumerate messages and delete any problem items. But there is a measure of protection removed.

I am curious as to why the whole problem arises. Why is it ever only Spam, and a very small subset of Spam in general, that causes the connection reset? What are the mechanics here?



Any thoughts?

 

See if any of this gives you an idea:



Windows Sockets Error Codes

http://msdn.microsoft.com/library/en-us/winsock/winsock/windows_sockets_error_codes_2.asp?FRAME=true



WSAECONNRESET
10054


Connection reset by peer.
An existing connection was forcibly closed by the remote host. This normally results if the peer application on the remote host is suddenly stopped, the host is rebooted, the host or remote network interface is disabled, or the remote host uses a hard close (see setsockopt for more information on the SO_LINGER option on the remote socket). This error may also result if a connection was broken due to keep-alive activity detecting a failure while one or more operations are in progress. Operations that were in progress fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET. **


Regards

Snowie The Snowman

 

Hi Snowie.

Thanks.

G-Lock's website had a paraphrasing of this explanation. It relates in very general terms possibilites why a connection might be reset.

My curiousity here is more focused.