[quote user="Thomas R. Stephenson"] The problem is caused by the receiving system not properly handling the packet too large error message so that the sending system does not know that it must reduce the packet size.  On the Mercury system you can turn off the  MTU discovery which always uses the same packet size.  BTW, when you test the MTU size it's best to test against the server with the problem.[/quote]

Thanks for the explanation. I'm presently learning the intracies of TCP/IP and so far have discovered that there are a lot of controls in place to try to prevent this from happening. Although I still have a lot more to learn, I guess that there exists the odd system along the route that is ancient or does not comply with the RFC's.

[quote user="Thomas R. Stephenson"] Typical problem where the receiving system is not properly handling the MTU Discovery operation.  When using MTU Discovery, the sending system keeps increasing the packet size until the receiving  system sends back the packet too large message.[/quote]

Again, from I have read, TCP on the receiving system should close the receive window so that the sending system stops sending data until it receives a notification that it can resume. However, I'm still working my way through this so this statement may be rather naive...

[quote user="Thomas R. Stephenson"] If the anti-virus software is setting between Mercury and the receiving host monitoring the TCP/IP transfer then this can also cause the same sort of problem.  Most anti-virus operating as a proxy is probably causing more problems than it solves.[/quote]

Thanks for all the help. I guess that all I can do is contact the receipient and say that this behaviour is beyond our control.

Cheers!

Hi

Can anyone help explain this, please?

One of our staff uses a distribution list to email newsletters to a small group of people. The newsletter will usually contain a c. 2MB PDF attachment.

Sometimes, recipients will receive more than one copy of the message. One person received 5 copies of the same message. I contacted this person and sent a test message with a 2.2MB attachment (a BMP) and the receipient recieved 2 copies:

Mercury Log

O 20101111 1549 MG00041E greenman@lincsheritage.org  recipient@aol.co.uk         3131366

Connection Log
15:50:10.402: --- Thu Nov 11 15:50:10 2010 ---
15:50:10.417: Connect to 'cluster8out.eu.messagelabs.com', timeout 30.
15:50:11.416: >> 220 server-15.tower-169.messagelabs.com ESMTP<cr><lf>
15:50:11.416: << EHLO apsarchaeology.co.uk<cr><lf>
15:50:11.463: >> 250-server-15.tower-169.messagelabs.com<cr><lf>
15:50:11.463: >> 250-STARTTLS<cr><lf>
15:50:11.463: >> 250-PIPELINING<cr><lf>
15:50:11.463: >> 250 8BITMIME<cr><lf>
15:50:11.463: << MAIL FROM:<greenman@lincsheritage.org><cr><lf>
15:50:11.541: >> 250 OK<cr><lf>
15:50:11.541: << RCPT TO:<recipient@aol.co.uk><cr><lf>
15:50:11.587: >> 250 OK<cr><lf>
15:50:11.587: << DATA<cr><lf>
15:50:11.619: >> 354 go ahead<cr><lf>
15:50:11.619: << Received: from Spooler by apsarchaeology.co.uk (Mercury/32 v4.62) ID MO00041F;<cr><lf>  11 Nov 2010 15:50:11 -0000<cr><lf>
15:50:11.619: << Received: from spooler by apsarchaeology.co.uk (Mercury/32 v4.62); 11 Nov 2010 15:49:40 -0000<cr><lf>
15:50:11.619: << From: "Greenman" <greenman@lincsheritage.org><cr><lf>
15:50:11.634: << To: recipient@aol.co.uk<cr><lf>
15:50:11.634: << Date: Thu, 11 Nov 2010 15:49:12 -0000<cr><lf>
15:50:11.634: << MIME-Version: 1.0<cr><lf>
15:50:11.634: << Content-type: Multipart/Mixed; boundary=Message-Boundary-14850<cr><lf>
15:50:11.634: << Subject: [HTL-Test] #1 Attachment 2MB<cr><lf>
15:50:11.634: << Message-ID: <4CDC1078.15783.34B47219@greenman.lincsheritage.org><cr><lf>
15:50:11.634: << Priority: normal<cr><lf>
15:50:11.634: << X-mailer: Pegasus Mail for Windows (4.52)<cr><lf>
15:50:11.634: << <cr><lf>
15:50:11.634: << <cr><lf>
15:50:11.634: << --Message-Boundary-14850<cr><lf>
15:50:11.634: << Content-type: Multipart/Alternative; boundary="Alt-Boundary-24411.884240921"<cr><lf>
15:50:11.634: << <cr><lf>
15:50:11.634: << --Alt-Boundary-24411.884240921<cr><lf>
15:50:11.634: << Content-type: text/plain; charset=US-ASCII<cr><lf>
15:50:11.634: << Content-transfer-encoding: 7BIT<cr><lf>
15:50:11.634: << Content-description: Mail message body<cr><lf>
15:50:11.634: << <cr><lf>
15:50:11.634: << Many thanks. I appreciate your help with this.<cr><lf>
15:50:11.634: << <cr><lf>
15:50:11.634: << Test message with a 2.2MB attachment.<cr><lf>
15:50:11.634: << <cr><lf>
15:50:11.634: << Please let me know how many copies you have received.<cr><lf>
15:50:11.634: << <cr><lf>
15:50:11.634: << Thanks<cr><lf>
15:50:11.634: << <cr><lf>
15:50:11.634: << Greenman<cr><lf>
15:50:11.634: << --<cr><lf>
~~~~~~~~~~~~~~~~~My Signature~~~~~~~~~~~~~~~~~
15:50:11.650: << <cr><lf>
15:50:11.650: << --Alt-Boundary-24411.884240921<cr><lf>
15:50:11.650: << Content-type: text/html; charset=US-ASCII<cr><lf>
15:50:11.650: << Content-transfer-encoding: 7BIT<cr><lf>
15:50:11.650: << Content-description: Mail message body<cr><lf>
15:50:11.650: << <cr><lf>
15:50:11.650: << <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"<cr><lf>
15:50:11.650: <<           "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><cr><lf>
15:50:11.650: << <html  xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head><cr><lf>
15:50:11.650: << <title></title><cr><lf>
~~~~~~~~~~~~~~~~~HTML Version of message~~~~~~~~~~~~~~~~~
15:50:11.681: << </html><cr><lf>
15:50:11.681: << <cr><lf>
15:50:11.681: << --Alt-Boundary-24411.884240921--<cr><lf>
15:50:11.681: << <cr><lf>
15:50:11.681: << --Message-Boundary-14850<cr><lf>
15:50:11.681: << Content-type: text/plain; charset=US-ASCII<cr><lf>
15:50:11.681: << Content-disposition: inline<cr><lf>
15:50:11.681: << Content-description: Attachment information.<cr><lf>
15:50:11.681: << <cr><lf>
15:50:11.681: << The following section of this message contains a file attachment<cr><lf>
15:50:11.681: << prepared for transmission using the Internet MIME message format.<cr><lf>
15:50:11.681: << If you are using Pegasus Mail, or any other MIME-compliant system,<cr><lf>
15:50:11.681: << you should be able to save it or view it from within your mailer.<cr><lf>
15:50:11.681: << If you cannot, please ask your system administrator for assistance.<cr><lf>
15:50:11.681: << <cr><lf>
15:50:11.681: <<    ---- File information -----------<cr><lf>
15:50:11.681: <<      File:  dcadarrow.bmp<cr><lf>
15:50:11.681: <<      Date:  17 Oct 2005, 10:55<cr><lf>
15:50:11.681: <<      Size:  2279478 bytes.<cr><lf>
15:50:11.681: <<      Type:  BMP-image<cr><lf>
15:50:11.681: << <cr><lf>
15:50:11.681: << --Message-Boundary-14850<cr><lf>
15:50:11.681: << Content-type: Application/Octet-stream; name="dcadarrow.bmp"; type=BMP-image<cr><lf>
15:50:11.697: << Content-disposition: attachment; filename="dcadarrow.bmp"<cr><lf>
15:50:11.697: << Content-transfer-encoding: BASE64<cr><lf>
15:50:11.697: << <cr><lf>
15:50:11.697: << Qk02yCIAAAAAADYAAAAoAAAAAAQAAOYCAAABABgAAAAAAADIIgAAAAAAAAAAAAAAAAAAAAAA<cr><lf>
15:50:11.697: << rOfMj+myj+myj+myj+qwj+myj+myj+myj+myj+myj+myj+myj+mtj+mtj+myj+myj+mtj+my<cr><lf>
15:50:11.697: << j+myj+mtj+myj+mtj+myj+mtj+myj+mtj+myj+myj+mtj+qwj+mtj+myj+qwj+mtj+myj+my<cr><lf>

~~~~~~~~~~~~~~~~~Attachment Data~~~~~~~~~~~~~~~~~

15:51:52.364: << fmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZm<cr><lf>
15:51:52.364: << fmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZm<cr><lf>
15:51:52.364: << fmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZmfmZm<cr><lf>
15:51:52.364: << <cr><lf>
15:51:52.364: << --Message-Boundary-14850--<cr><lf>
15:51:52.364: << .<cr><lf>
15:51:52.598: >> 250 ok 1289490712 qp 15806 server-15.tower-169.messagelabs.com!1289490610!46497168!1<cr><lf>
15:51:52.614: << QUIT<cr><lf>
15:51:52.645: >> 221 server-15.tower-169.messagelabs.com<cr><lf>
15:51:52.645: --- Connection closed normally at Thu Nov 11 15:51:52 2010. ---

Now, I can see that the message was successfully delivered to MessageLabs and will contact them to see if they might be able to explain what is causing this. However, I would appreciate a 'second opinion' so if anyone has encountered this before and is aware of any conditions that can cause this I would appreciate it if you could reply. I have asked the recipient for an alternative address (non AOL), to email further test messages but have yet to receive a reply.

Many thanks.

> Now, I can see that the message was successfully delivered to MessageLabs and will contact them to see if they might be able to
> explain what is causing this. However, I would appreciate a 'second opinion' so if anyone has encountered this before and is aware of any
> conditions that can cause this I would appreciate it if you could reply. I have asked the recipient for an alternative address (non
> AOL), to email further test messages but have yet to receive a reply.

Typically this points to a problem with fragmented packets where the message transmission fails when the .CRLF end-of-message marker is sent.  This means the sending system sees this as a failure and re-queues the message for sending, however the receiving system still delivers the message since it was fully received. This continues until the retry limit is reached or the message is delivered, which ever comes first

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 on the sending sustem.

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.

Hey, Thomas

Thanks for responding.

I had already run the utility you linked to and it recommended an MTU of 1500. The display adaptor is a Matrox G200eW Nuvoton on a Windows 2008 64bit storage server.

Judging by your response, are these symptoms usually caused by the originating mail transfer agent? If fragmentation is an issue with SMTP delivery, is it possible to configure Mercury to set the fragmentation bit so that fragmentation is not allowed?

What is interesting is that the same people receive the duplicate message - others in the list do not. I regularly send myself data via email to my personal address and have never received more than one copy of any messages.

[Edit]

Also, although anti-virus is installed on this server, it does not check incoming/outgoing email and both the Pegasus Mail mail boxes and the entire Mercury folder are excluded from on-access scanning.

Judging by your response, are these symptoms usually caused by

the originating mail transfer agent? If fragmentation is an issue with

SMTP delivery, is it possible to configure Mercury to set the

fragmentation bit so that fragmentation is not allowed?

The problem is caused by the receiving system not properly handling the packet too large error message so that the sending system does not know that it must reduce the packet size.  On the Mercury system you can turn off the  MTU discovery which always uses the same packet size.  BTW, when you test the MTU size it's best to test against the server with the problem.

What is interesting is that the same people receive the duplicate

message - others in the list do not. I regularly send myself data via

email to my personal address and have never received more than one copy

of any messages.

Typical problem where the receiving system is not properly handling the MTU Discovery operation.  When using MTU Discovery, the sending system keeps increasing the packet size until the receiving  system sends back the packet too large message. 

[Edit]

Also, although anti-virus is installed on this server, it does not

check incoming/outgoing email and both the Pegasus Mail mail boxes and

the entire Mercury folder are excluded from on-access scanning.

If the anti-virus software is setting between Mercury and the receiving host monitoring the TCP/IP transfer then this can also cause the same sort of problem.  Most anti-virus operating as a proxy is probably causing more problems than it solves.