This has been resolved. Spamina replied and said that the problems were a result of the 'connection's service provider' at their end and that it has been fixed. Indeed, I am no longer seeing the errors in Mercury's output window. They said they will provide more details when they have them.

Hooray :)

Hi

We are using Mercury/32 V4.74 installed on Windows 2008 Server (64Bit). All the machines on the LAN connect to the Internet via a router. Our connection speed is reasonable for downloads (10 - 14Mbps) but the upload speed could be better and varies between 0.6 - 0.7Mbps.

We have configured Mercury to use the MercuryC SMTP relaying client when connecting to the host (Spamina) that filters our mail. Since we changed to Spamina some time ago we are seeing many instances of the following displayed in the MercuryC window:

15 Jan 13 08:20, Servicing job MO0020AA...  Network failure during DATA with 109.74.250.8
TCP/IP error during processing.
 failed.
Error FF servicing queue job.

These were never displayed before the change.

I have raised a support ticket with Spamina and they have asked if the mail server makes more than five connection attempts at the same time (the actual wording is: Please, verify that the sender server doesn't made 5 or more connections from the same IP.)

I have looked at the output from the MercuryC window and cannot see that 5 or more jobs are being processed at the same time when this error is logged:

15 Jan 13 02:16, Servicing job MO002081... OK.
15 Jan 13 02:16, Servicing job MO002080... OK.
15 Jan 13 02:24, Servicing job MO002087... OK.
15 Jan 13 02:43, Servicing job MO002095... OK.
15 Jan 13 08:13, Servicing job MO0020A7... OK.
15 Jan 13 08:13, Servicing job MO0020A6... OK.
15 Jan 13 08:20, Servicing job MO0020AA...  Network failure during DATA with 109.74.250.8
TCP/IP error during processing.
 failed.
Error FF servicing queue job.

This happens with large messages (10MB) and small messages (26KB). The session logs show the same error when an error is logged:

08:21:37.746: << sd397ud4POj7cPCY5b/rQD2t6EB8lvvmiAGvvBqtygQHj6kHOiat1w+LJODudB6AJFPF2t3T<cr><lf>
08:21:37.746: << x1Lf7/9JysrsU1eAyIH1TMpA/E1UkONQvZBHUKEco+ZN7tv5jRFDBvUbMnJwrz4jRg8bPnLo<cr><lf>
08:21:59.040: 9: Socket write error 10054 (connection aborted by remote host)
08:21:59.040: << QUIT<cr><lf>
08:21:59.040: 9: Socket write error 10054 (connection aborted by remote host)
08:21:59.040: --- Connection closed normally at Tue Jan 15 08:21:59 2013. ---
08:21:59.040:

10:12:24.543: <<  SCOM and explains how Quest Foglight for SQL Server extends the value of S=<cr><lf>
10:12:24.543: << COM, enabling you to go beyond simple up/down monitoring and effectively ma=<cr><lf>
10:12:24.543: 9: Socket write error 10054 (connection aborted by remote host)
10:12:24.543: << QUIT<cr><lf>
10:12:24.543: 9: Socket write error 10054 (connection aborted by remote host)
10:12:24.543: --- Connection closed normally at Tue Jan 15 10:12:24 2013. ---
10:12:24.543:

When this first appeared we increased the timeout to 60secs but this has not helped.

We have confirmed that the messages are delivered without any problems (which I don't understand if the session logs do not contain .<cr><lf>).

Can anyone help to shed some light on this please? Do I need to worry about it?

Thanks!

Things to check:

1.  Check the TCP/IP timeout setting.  You may need to set it as high as 600 seconds.
2.  Packet fragmentation can cause this.  Here are the notes I made to myself 
back when I had the problem:
    Packet fragmentation can cause random problems with sending mail.  "TCP/IP 
    Error" is what is reported.
    The remedy is twofold:
    1)  Determine max MTU and manually set the MTU in Windows (TCPOptimizer can 
    automate this).
    2)  Turn off MTU Discovery in Windows so that the manually set MTU is honored.
    	- In the registry, navigate to the following registry key:
    	      [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
    	- Find the "EnablePMTUDiscovery" parameter and set its value as "0".   
    	  If the "EnablePMTUDiscovery" parameter doesn't exist select New - DWORD and  
    set its name as "EnablePMTUDiscovery" and set its value as "0"
3.  Quoted from earlier post by Thomas Stephenson:
    > 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.

 4.  That 5 message number you mentioned may indicate that when more than 5 messages are sent during the same connection Spamina assumes you are sending spam and drops the connection.  Do your logs confirm the error occurs consistently around the 6th message?  Must your outgoing mail go through Spamina?

Thanks a lot for replying, Brian.

All the messages are delivered, which is strange. Would using a different set of IP ranges cause packet fragmentation or the MTU to change? Like I said, we never experienced this when using MessageLabs or Webroot.

I have just received a notification from Spamina that they will be upgrading their UK datacentres, and will also be changing the IP ranges that mail will be sent to/received from. This is due to take place during February so I will hold off making any changes until after the upgrade has occurred. Hopefully, this will help solve the issue...

Cheers!

[quote user="Greenman"]All the messages are delivered, which is strange. Would using a different set of IP ranges cause packet fragmentation or the MTU to change? Like I said, we never experienced this when using MessageLabs or Webroot.[/quote]

Yes, a change in the destination could change the max MTU.  From wikipedia: "The Internet Protocol defines the "Path MTU" of an Internet transmission path as the smallest MTU of any of the IP hops

of the "path" between a source and destination. Put another way, the

path MTU is the largest packet size that can traverse this path without

suffering fragmentation."

[quote user="bfluet"]...

Yes, a change in the destination could change the max MTU.  From wikipedia: "The Internet Protocol defines the "Path MTU" of an Internet transmission path as the smallest MTU of any of the IP hops of the "path" between a source and destination. Put another way, the path MTU is the largest packet size that can traverse this path without suffering fragmentation."[/quote]

D'oh! I did know that. Thanks for posting :)

Hopefully, this will be resolved by the end of Feb.

Thanks for the post.