none
What configuration can be changed to deal with SMTPSEND.SuspiciousRemoteServerError ?

    Question

  • When we send emails over about 15 MB in size to other Exchange servers in our system, or to an external email provider, we sometimes see this error---

    ----

    Remote Server at ------ returned
     '400 4.4.7 Message delayed' 
    3/23/2016 11:08:41 PM - Remote Server at ------ returned
     '451 4.4.0 SMTPSEND.SuspiciousRemoteServerError; 
    remote server disconnected abruptly; retry will be delayed'

    ==

    We have checked many network settings (based on information in various forum items about this error), and we think that is not the problem.

    This only happens at one of our Exchange locations.     
    The other locations can send emails of 25 MB and they are delivered correctly / no errors.
    The ping time from the  location sending emails,  to the Exchange location receiving emails,  is 430 ms.
    That connection is over the Internet with a VPN.

    It seems like Exchange thinks this is taking too long, or too many attempts, or something like that.
       (Since somewhat smaller emails are delivered OK.)

    Is there an Exchange configuration parameter in Transport service or similar, that we can change, to tell Exchange to "wait a little longer",   before issuing that error ?

    Thanks

    Exchange 2013 CU10,  Windows server 2012 Standard, Outlook 2013, 
    SMTP,

    =======

    Thursday, March 24, 2016 1:24 PM

All replies

  • Are the "other Exchange servers in your system" in the same organization?

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Friday, March 25, 2016 7:31 AM
    Moderator
  • Hi Tycho,

    Base on my search, I found a similar case as yours, you can refer to the following method and check if any helps:
    1.Navigate to the following path in registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip\parameters

    On the Edit menu, click Add Value, and then add the following registry value:

    Value Name: EnablePMTUBHDetect
    Data Type: REG_DWORD
    Value: 1

    2.Disabling the following in Network Interface card settings

    Ø  TCP Checksum Offload (IPV4)
    Ø  TCP Checksum Offload (IPV6)

    Best regards,



    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Niko Cheng
    TechNet Community Support

    Friday, March 25, 2016 9:09 AM
    Moderator
  • Yes, all the Exchange servers are in the same Organization.

    Thanks

    ==

    Friday, March 25, 2016 9:36 PM
  • @Niko --- Thanks for the information.    We have    not    tried this method at this time.  Therefore I do not know if it is "the answer".     Thanks
    Wednesday, April 6, 2016 12:11 PM
  • Status---

    a--- for the external email, we Disabled the Send Connector at that location, and the Exchange system then decides to use a similar Send Connector at a different Exchange location.
    So the email from "Exchange location A" is sent to "Exchange location B", and then from there to the external provider.

    b---  for internal (Exchange to Exchange) the network configuration was changed to use a different network provider.  This network connects all our locations (but does not have an Internet connection).   In general it is a "slower" network.   However, it does not get the error,   and the email gets delivered. 

    Therefore, it appears the "slow" or "busy" "VPN over Internet" network highway was the cause.

    Although still not sure of the details.

    =====

    Wednesday, April 6, 2016 12:21 PM
  • Are there firewalls between the sites, and if so, are they completely open to all ports between all Exchange servers?

    Please run the following commands and post the results here.

    Get-ReceiveConnector
    Get-SendConnector


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Wednesday, April 6, 2016 6:08 PM
    Moderator