We are using our Exchange 2013 SMTP receive connector to relay mail from our fax server to internal users.  Several times a day, our users will receive duplicate or triplicate emails from this service.  Looking at wireshark captures and the SMTP Receive logs, it appears the RightFax successfully sends the data (including the "." at the end) but doesn't receive a " 2.6.0 Mail queued for delivery" message from the Exchange server. It then resets the connection to send the message again. Often, it will receive a successful "mail queued" message the second time, but if not it retries and receives the "mail queued" message the third time.  However, on the recipient end, they receive two/three emails, all with different conversation ID's. 

If we switch the email gateway in the fax application back to our legacy Exchange 2007 environment (which we have not yet decommissioned due to this issue), the issue goes away completely.

So far, the fax application is the only application with email being relayed that we have received complaints about duplicate emails. 

We have tried:
-  Changing the application to point to a different 2013 server that doesn't have as much internal relay traffic
-  Increasing the MaxInboundConnectionsPerSource to 100 and MaxInboundConnectionPercentagePerSource to 100%
-  Increasing the timeout on the application (up to 6 minutes)

Have there been any changes to SMTP response in Exchange 2013 that would cause these issues?

Sometimes 250 2.6.0 comes with a long delay. One scenario I observed is when one of the rcpt to: address is invalid.

You may like to tune the fax app timeout to a longer value e.g. 60 seconds.

Sometimes 250 2.6.0 comes with a long delay. One scenario I observed is when one of the rcpt to: address is invalid.

You may like to tune the fax app timeout to a longer value e.g. 60 seconds.

• Proposed as answer by Allen_WangJFMicrosoft contingent staff, Moderator 21 hours 28 minutes ago

Hi,

As Li mentioned, this issue may be caused by network side.
Please try to run ping IP_address -f -l 1472  to verify whether it returns 'request time out' error.
If it is the case, please follow following KB to adjust the MTU setting for the network card:
https://support.microsoft.com/en-us/kb/314825/en-us

Additional, I find an similar thread about your question, for your reference:
https://social.technet.microsoft.com/Forums/en-US/231741f5-8950-462c-8800-980d2938e19e/smtp-diagnosticslogging?forum=exchange2010

Thanks