locked
Inbound Email delivery delayed from MessageLabs RRS feed

  • Question

  • We recently had a storage problem that lasted for about 8 hours.  During this time a large queue - 50,000 + messages built up at our SPAM service provider MessageLabs.  Initially, we had problems with delayed delivery internally and disabled the back pressure features on our Hub Transports, which fixed that problem.  However, we have been unsuccessful at getting the queue backlog at Messagelabs to decrease a significant amount.  They are reporting the following error: 

    Delivery attempt failure - transient
    Attempted delivery 57/14-08994-19EF59E4 to
    152.72.185.12 on Wed Oct 12 21:40:24 2011
    Error Message:
    "421 4.3.2 The maximum number of concurrent connections has exceeded a limit, closing transmission channel"
    Retries attempt:
    3
    Time message queued:
    2743.28seconds

    We are currently using Exchange 2007 SP2 servers for our Hub Transports and they seem to be performing well.  We have opened a call with Microsoft and that has not led to any resolution.  Is there something we should try or that we are missing here?

    Thursday, October 13, 2011 11:25 PM

Answers

  • Hi Exchange Feak,

    Per your description, there are too many message on the SMPM service provider MessageLabs, due to the storage rpbolem, and maybe there are some failure when they send to the exchange server, and the email will retry the dilivery. So many connections would occured, and the server performance would be affected.
    The back pressure, when a Hub Transport or Edge Transport server is under resource pressure, it rejects incoming connections.
    So if you disable the feature, the delay issue resolved.
    And the error you referred, if it is occured on the third party product, you could turn to help from the vender, confirm the third party product connection limits configuration firstly.
    Some information related configuration on exchange server, please checked the receive connector settings on Edge server which is responsible to receive emails from the the Messagelabs, confirm the MaxInboundConnectionPerSource value, you could change it by:
    Set-ReceiveConnector "receive connector name" -MaxInboundConnectionPerSource 100(example)

    Regards!
    Gavin
    TechNet Subscriber Support in forum
    If you have any feedback on our support, please contact tngfb@microsoft.com
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

     

    • Marked as answer by Exchange Freak Thursday, November 17, 2011 7:56 PM
    Friday, October 14, 2011 9:07 AM

All replies

  • Hi Exchange Feak,

    Per your description, there are too many message on the SMPM service provider MessageLabs, due to the storage rpbolem, and maybe there are some failure when they send to the exchange server, and the email will retry the dilivery. So many connections would occured, and the server performance would be affected.
    The back pressure, when a Hub Transport or Edge Transport server is under resource pressure, it rejects incoming connections.
    So if you disable the feature, the delay issue resolved.
    And the error you referred, if it is occured on the third party product, you could turn to help from the vender, confirm the third party product connection limits configuration firstly.
    Some information related configuration on exchange server, please checked the receive connector settings on Edge server which is responsible to receive emails from the the Messagelabs, confirm the MaxInboundConnectionPerSource value, you could change it by:
    Set-ReceiveConnector "receive connector name" -MaxInboundConnectionPerSource 100(example)

    Regards!
    Gavin
    TechNet Subscriber Support in forum
    If you have any feedback on our support, please contact tngfb@microsoft.com
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

     

    • Marked as answer by Exchange Freak Thursday, November 17, 2011 7:56 PM
    Friday, October 14, 2011 9:07 AM
  • Hi

    Any update for your issue?

    Regards!
    Gavin

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Monday, October 31, 2011 1:52 AM
  • I would also suggest you to run EXMON Microsoft Exchange Server User Monitor (ExMon) tool and check which user are sending high amount of data packets (It might be posssible that any user computer on the network is infected with virus and is sending high amount of data packets (Spam E-mails)

    As per above reports it seems that some one is trying to send bulk spam e-mails and exchange server is rejecting the request based on concurrent connection settings.

    Hope this helps.

     


    Viral Rathod Blog : http://viralr.wordpress.com
    Monday, October 31, 2011 7:13 AM