Community Discussions and Support
Sending same email mulitple times to recipient

[quote user="David Meyer"]This problem seems to be resolved. I am not sure if it was the dns timeout or removing BitDefender.[/quote]

 

Personally I think it was the latter.  None of the anti-virus programs seem to get the Winsock level stuff right when setting between server and clinet.

 

<p>[quote user="David Meyer"]This problem seems to be resolved. I am not sure if it was the dns timeout or removing BitDefender.[/quote]</p><p> </p><p>Personally I think it was the latter.  None of the anti-virus programs seem to get the Winsock level stuff right when setting between server and clinet.</p><p> </p>

Hi,

I have configured Mercury on a small LAN and every thing seems to be fine except in certain circumstances with attachments it will send the same email to the external recipient numerous times (up to 12 times).  It happens infrequently and to different addresses.  The attachments are pdf or doc or both.

What am I doing wrong?

 

Peter

 

 

<P>Hi,</P> <P>I have configured Mercury on a small LAN and every thing seems to be fine except in certain circumstances with attachments it will send the same email to the external recipient numerous times (up to 12 times).  It happens infrequently and to different addresses.  The attachments are pdf or doc or both. </P> <P>What am I doing wrong?</P> <P mce_keep="true"> </P> <P>Peter</P> <P mce_keep="true"> </P> <P mce_keep="true"> </P>

I've seen a few reports like this, and have spent quite some time trying to track it down. It appears to me that this is only possible if Mercury connects to a remote host that does not properly follow RFC2821 when errors occur.

Mercury's queueing mechanism, especially in v4.51 (where it was completely overhauled) simply won't permit a message to be sent multiple times by error, unless the remote client is accepting and delivering the message then returning an error response to Mercury (something it should not be doing). The other possibility, of course, is that the message is being *sent* multiple times (i.e, there are actually multiple copies of the message being submitted to Mercury for delivery). Aside from that, I can't see any other way for this to happen.

It's my belief, based on protracted testing, that this is not a problem in Mercury. If you can give me a reliable way of reproducing it, though (something I've never been able to do, which tends to reinforce my view), I'll look into it further.

Cheers!

-- David --

I've seen a few reports like this, and have spent quite some time trying to track it down. It appears to me that this is only possible if Mercury connects to a remote host that does not properly follow RFC2821 when errors occur. Mercury's queueing mechanism, especially in v4.51 (where it was completely overhauled) simply won't permit a message to be sent multiple times by error, unless the remote client is accepting and delivering the message then returning an error response to Mercury (something it should not be doing). The other possibility, of course, is that the message is being *sent* multiple times (i.e, there are actually multiple copies of the message being submitted to Mercury for delivery). Aside from that, I can't see any other way for this to happen. It's my belief, based on protracted testing, that this is not a problem in Mercury. If you can give me a reliable way of reproducing it, though (something I've never been able to do, which tends to reinforce my view), I'll look into it further. Cheers! -- David --

[quote user="pws80"]

Hi,

I have configured Mercury on a small LAN and every thing seems to be fine except in certain circumstances with attachments it will send the same email to the external recipient numerous times (up to 12 times).  It happens infrequently and to different addresses.  The attachments are pdf or doc or both.

What am I doing wrong?

 

Peter

 

 

[/quote]

I suspect that you are having some sort of packet fragmentation problem where the failure occurs right at the time the end of message .CR/LF is sent.  The could cause the receiving system to deliver the message and the sending system to see a failure and resend.  A POP3/SMTP transmission 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.



[quote user="pws80"]<p>Hi,</p> <p>I have configured Mercury on a small LAN and every thing seems to be fine except in certain circumstances with attachments it will send the same email to the external recipient numerous times (up to 12 times).  It happens infrequently and to different addresses.  The attachments are pdf or doc or both. </p> <p>What am I doing wrong?</p> <p mce_keep="true"> </p> <p>Peter</p> <p mce_keep="true"> </p> <p mce_keep="true"> </p><p>[/quote]</p><p>I suspect that you are having some sort of packet fragmentation problem where the failure occurs right at the time the end of message .CR/LF is sent.  The could cause the receiving system to deliver the message and the sending system to see a failure and resend.  A POP3/SMTP transmission 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. </p>

I see this problem also. I get this message back & sometimes there are 2 different IP addresses involved. The problem definitely occurs with pdf attachments but not always. It annoys the recipients a lot! The problem started when I upgraded to the latest version.

 

<!--StartFragment -->Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www

 

I doubt this machine has the NForce video chip.


 
&lt;DIV&gt;I see this problem also. I get this message back &amp;amp;&amp;nbsp;sometimes there are 2 different IP addresses involved. The problem definitely occurs with pdf attachments but not always. It annoys the recipients a lot! The problem started when I upgraded to the latest version.&lt;/DIV&gt; &lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt; &lt;DIV&gt;&lt;!--StartFragment --&gt;Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www&lt;/DIV&gt; &lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt; &lt;DIV&gt;I doubt this machine has the NForce video chip.&lt;/DIV&gt; &lt;DIV&gt; &amp;nbsp;&lt;/DIV&gt;

[quote user="David Meyer"]

I see this problem also. I get this message back & sometimes there are 2 different IP addresses involved. The problem definitely occurs with pdf attachments but not always. It annoys the recipients a lot! The problem started when I upgraded to the latest version.

 

<!--StartFragment -->Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www
Network write failure during data transmission to zzz.yyy.xxx.www

 

I doubt this machine has the NForce video chip.


 

[/quote]

 

You need to know what is going on and why they are breaking the connection.  Turn on session logging and send a message to this address.  The session log should give you a good idea what's happening is not why.  That said, I find that when connection are broken for no reason at all it's a fragmented packet problem.  It does not have to a an nvidia chip set, these are just the easy ones to handle.  If nothing else turn off the discovery operation on your end.

 

[quote user=&quot;David Meyer&quot;]&lt;div&gt;I see this problem also. I get this message back &amp;amp;&amp;nbsp;sometimes there are 2 different IP addresses involved. The problem definitely occurs with pdf attachments but not always. It annoys the recipients a lot! The problem started when I upgraded to the latest version.&lt;/div&gt; &lt;div&gt;&amp;nbsp;&lt;/div&gt; &lt;div&gt;&lt;!--StartFragment --&gt;Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www Network write failure during data transmission to&amp;nbsp;zzz.yyy.xxx.www&lt;/div&gt; &lt;div&gt;&amp;nbsp;&lt;/div&gt; &lt;div&gt;I doubt this machine has the NForce video chip.&lt;/div&gt; &lt;div&gt; &amp;nbsp;&lt;/div&gt;&lt;p&gt;[/quote]&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;You need to know what is going on and why they are breaking the connection.&amp;nbsp; Turn on session logging and send a message to this address.&amp;nbsp; The session log should give you a good idea what&#039;s happening is not why.&amp;nbsp; That said, I find that when connection are broken for no reason at all it&#039;s a fragmented packet problem.&amp;nbsp; It does not have to a an nvidia chip set, these are just the easy ones to handle.&amp;nbsp; If nothing else turn off the discovery operation on your end. &lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;

Thomas,

 

Thanks for your suggestions.

 

I resent one of the offending emails with session logging on.

 

This was the message at the end of the file.

 

17:51:02.500: 9: Socket write error 10054 (connection aborted by remote host)
17:51:02.531: 9: Socket write error 10054 (connection aborted by remote host)
17:51:02.593: << QUIT<cr><lf>
17:51:02.609: 9: Socket write error 10054 (connection aborted by remote host)
17:51:02.640: 7: Socket read error 10054 (connection aborted by remote host)
17:51:02.671: --- Connection closed normally at Sun Aug 05 17:51:02 2007. ---
17:51:02.687:

It seems like you were correct about the error. I adjusted the MTU -, the TCP Optimizer suggested 1465 for this. I keep getting these errors after sending the original message even after adjusting the MTU and rebooting the server. I assume this is the mail server trying to deliver the email again but I don't see why it should continue to fail after the MTU setting was changed.
&lt;DIV&gt;Thomas,&lt;/DIV&gt; &lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt; &lt;DIV&gt;Thanks for your suggestions.&lt;/DIV&gt; &lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt; &lt;DIV&gt;I resent one of the offending emails with session logging on.&lt;/DIV&gt; &lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt; &lt;DIV&gt;This was the message at the end of the file.&lt;/DIV&gt; &lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt; &lt;DIV&gt;17:51:02.500: 9: Socket write error 10054 (connection aborted by remote host) 17:51:02.531: 9: Socket write error 10054 (connection aborted by remote host) 17:51:02.593: &amp;lt;&amp;lt; QUIT&amp;lt;cr&amp;gt;&amp;lt;lf&amp;gt; 17:51:02.609: 9: Socket write error 10054 (connection aborted by remote host) 17:51:02.640: 7: Socket read error 10054 (connection aborted by remote host) 17:51:02.671: --- Connection closed normally at Sun Aug 05 17:51:02 2007. --- 17:51:02.687: &lt;/DIV&gt; &lt;DIV&gt;It seems like you were correct about the error. I adjusted the MTU -, the TCP Optimizer suggested 1465 for this. I keep getting these errors after sending the original message even after adjusting the MTU and rebooting the server. I assume this is the mail server trying to deliver the email&amp;nbsp;again but I don&#039;t see why it should continue to fail after the MTU setting was changed.&lt;/DIV&gt;

One other thing I have found since upgrading is that I get Error 451 trying to connect to the email server (when replying to emails) when I am away from the office. I can't see why this should happen. I can create a new email and send it to the same recipients but replying fails.

 

My guinea pig email recipient reports that he is still getting multiple copies of my test email (901 K email with a pdf attachment).

 

The session log lists this at the end.

 

21:42:44.265: 9: Socket write error 10054 (connection aborted by remote host)
21:42:44.296: 9: Socket write error 10054 (connection aborted by remote host)
21:42:44.359: << QUIT<cr><lf>
21:42:44.390: 9: Socket write error 10054 (connection aborted by remote host)
21:42:44.421: 7: Socket read error 10054 (connection aborted by remote host)
21:42:44.453: --- Connection closed normally at Tue Aug 07 21:42:44 2007. ---
&lt;DIV&gt;One other thing I have found since upgrading is that I get Error 451 trying to connect to the email server (when replying to emails) when I am away from the office. I can&#039;t see why this should happen. I can create a new email and send it to the same recipients but replying fails. &lt;/DIV&gt; &lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt; &lt;DIV&gt;My guinea pig email recipient reports that he is still getting multiple copies of my test email (901 K email with a pdf attachment).&lt;/DIV&gt; &lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt; &lt;DIV&gt;The session log lists this at the end.&lt;/DIV&gt; &lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt; &lt;DIV&gt;21:42:44.265: 9: Socket write error 10054 (connection aborted by remote host) 21:42:44.296: 9: Socket write error 10054 (connection aborted by remote host) 21:42:44.359: &amp;lt;&amp;lt; QUIT&amp;lt;cr&amp;gt;&amp;lt;lf&amp;gt; 21:42:44.390: 9: Socket write error 10054 (connection aborted by remote host) 21:42:44.421: 7: Socket read error 10054 (connection aborted by remote host) 21:42:44.453: --- Connection closed normally at Tue Aug 07 21:42:44 2007. ---&lt;/DIV&gt;

I have now had this problem with a rar file I sent and then an email without any attachment I sent to the same address. In this case though rather than receiving 10-12 copies neither email was received at all.
&lt;DIV&gt;I have now had this problem with a rar file I sent and then an email without any attachment I sent to the same address. In this case though rather than receiving 10-12 copies neither email was received at all.&lt;/DIV&gt;

The last reported problem turned out to be due to a dns issue.

 

Thomas recommended to change the windows MTU (1500 defualt) to something different as the adsl connection uses 1492. I have reset mine to 1465 but this hasn't fixed the problem.

 

I am still having problems with at least one email recipient (I use him as a test dummy). I did find that my antivirus program (BitDefender) was spending a lot of CPU time scanning so for the moment I have turned this off. I also found some issues with the timeout settings in Mercury for dns (20 seconds seemed quite low so I increased this to 60). The latest emails seems to have been sent with no errors! I am crossing my fingers.
&lt;DIV&gt;The last reported problem turned out to be due to a dns issue.&lt;/DIV&gt; &lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt; &lt;DIV&gt;Thomas recommended to change the windows MTU (1500 defualt) to something different as the adsl connection uses 1492. I have reset mine to 1465 but this hasn&#039;t fixed the problem. &lt;/DIV&gt; &lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt; &lt;DIV&gt;I am still having problems with at least one email recipient (I use him as a test dummy). I did find that my antivirus program (BitDefender) was spending a lot of CPU time scanning so for the moment I have turned this off. I also found some issues with the timeout settings in Mercury for dns (20 seconds seemed quite low so I increased this to 60). The latest emails seems to have been sent with no errors! I am crossing my fingers.&lt;/DIV&gt;

This problem seems to be resolved. I am not sure if it was the dns timeout or removing BitDefender.

This problem seems to be resolved. I am not sure if it was the dns timeout or removing BitDefender.
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Cancel
Delete
Pending draft ... Click to resume editing
Discard draft