locked
Error 421 Exchange Server 2007 RRS feed

  • Question

  • Recently, our Exchange server stopped receiving incoming e-mails.  When I ran the Remote Connectivity Analyzer, I get the following error:

    Analyzing SMTP Capabilities for server mail.company.com:25
    The test passed with some warnings encountered. Please expand the additional details.

    Additional Details

    Unabled to determine SMTP capabilities. Reason: Unexpected SMTP server response. Expected: 220, actual: 421, whole response: 421 4.3.2 Service not available, closing transmission channel
    Elapsed Time: 208 ms.
    Attempting to send a test email message to user@company.com using MX mail.company.com.
    Delivery of the test email message failed.

    Additional Details

    The server returned status code 421 - Service not available, closing transmission channel. The server response was: 4.3.2 Service not available, closing transmission channel
    Exception details:
    Message: Service not available, closing transmission channel. The server response was: 4.3.2 Service not available, closing transmission channel
    Type: System.Net.Mail.SmtpException
    Stack trace:
    at System.Net.Mail.SmtpConnection.GetConnection(ServicePoint servicePoint)
    at System.Net.Mail.SmtpClient.Send(MailMessage message)
    at Microsoft.Exchange.Tools.ExRca.Tests.SmtpMessageTest.PerformTestReally()
    Elapsed Time: 204 ms.

    The MX record points to the correct name/address.  All of the Exchange Server 2007 services are up and running.  No service packs or updates have been installed that I can see.  We can send outgoing mail and can receive e-mails internally.  However, we did recently have a DNS issue that needed an IPCONFIG /flushdns.  Any help would be greatly appreciated.    

    Tuesday, November 4, 2014 9:09 PM

Answers

  • The IP range configured for the default connector (which is not the default setting, by the way, as you observed when you created the new custom connector), prevented reception of mail from servers *without* those IP addresses.

    Since 192.168.x.x is a private IP range, it is expected that you would not be able to receive mail from external servers (that will necessarily have a publicly routable IP address - so something out of the 10.x.x.x, 172.16-21.x.x and 192.168.x.x ranges).

    Since mail reception was working before, something must have been changed at some point.

    Do you happen to know why the default IP range was changed on the default connector?

    I would tend to suggest changing the IP range setting back to the default - but of course I have no idea what someone may have been trying to accomplish.


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

    Wednesday, November 5, 2014 4:44 PM
  • I am assuming that the default range was changed to "lock down" Exchange to only accepting mail from the private network (where the Exchange Server resides).  However, if that is the case, I wonder why they didn't just limit it to the single IP (192.168.1.2) of the server itself.  Shouldn't the "Receive mail from these remote servers that have these IP addresses" field only list the mail servers that the company accesses?  I am wondering why does it now only work only if I keep the entire default (0.0.0.0 to 255.255.255.255) range of IPs.

    Anyway, it is working now and for the last three days since I deleted the old connector and created a new one.

    Friday, November 7, 2014 3:28 PM

All replies

  • Actually, I take back the part about updates.  It does appear that on 10/12, 

    Update Rollup 14 for Exchange Server 2007 SP3 and

    Update Rollup 8 Version 2 for Microsoft Exchange Server 2007 Service Pack 3 (SP3) 

    were installed.

    Update Roll
    Tuesday, November 4, 2014 9:16 PM
  • Have you made any changes to the receive connectors?  Are you sure that you have a receive connector that will accept the connection?

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Tuesday, November 4, 2014 10:31 PM
  • 1. Is it receieving emails if sent to this server internally? did you check the get-queue for that specific server?

    2. if you are having multiple HT servers, are you having any WNLB configured between them and make sure teh WNLB works fine. If required remove the node and readd or reconfigure the WNLB.

    3. if you can send email directly to that specific HT server from your mail gateway or from outside , what happens?

     
    Tuesday, November 4, 2014 11:30 PM
  • Hi,

    From your description, I would like to clarify the following things:

    1. Ensure that your transport is listening on 25, and there is no other program using it.

    2. Make sure that you have enough disk space. If no, please free up some space and check the result.

    Hope this can be helpful to you.

    Best regards,


    Amy Wang
    TechNet Community Support

    Wednesday, November 5, 2014 9:42 AM
    Moderator
  • Have you made any changes to the receive connectors?  Are you sure that you have a receive connector that will accept the connection?

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    No changes have been made to the receivers.
    Wednesday, November 5, 2014 4:00 PM
  • 1. Is it receieving emails if sent to this server internally? did you check the get-queue for that specific server?

    2. if you are having multiple HT servers, are you having any WNLB configured between them and make sure teh WNLB works fine. If required remove the node and readd or reconfigure the WNLB.

    3. if you can send email directly to that specific HT server from your mail gateway or from outside , what happens?

     

    1.  Users can send and receive emails internally (i.e. user1@company.com can send and receive to user2@company.com and vice versa).  Users can send out, also.  It is only on incoming mails not from our domain. 

    2.  We only have one HT server.  This is a small office using a single SBS2008 box.

    3.  Currently, no external emails come through.


    Wednesday, November 5, 2014 4:00 PM
  • Hi,

    From your description, I would like to clarify the following things:

    1. Ensure that your transport is listening on 25, and there is no other program using it.

    2. Make sure that you have enough disk space. If no, please free up some space and check the result.

    Hope this can be helpful to you.

    Best regards,


    Amy Wang
    TechNet Community Support


    1.  The receive connector is configured to port 25.  There have been no installations of any programs that would use port 25 since long before the problem arose on 10/10.

    2.  There are 103 GBs available on the drive that houses the Exchange mailbox.


    Wednesday, November 5, 2014 4:01 PM
  • OK.  I'm getting somewhere.  The default connector had the following configuration:

    Receive mail from remote servers that have these IP addresses:

    192.168.1.0-192.168.1.0

    192.168.1.2-192.168.1-255

    I disabled that connector and created a new custom connector with similar configuration.  However,  I left the default entry for the remote server IPs, which are:

    0.0.0.0-255.255.255.255

    With this new connector, I was then able to telnet into the server on port 25 without getting the 

    421 4.3.2 Service not available, closing transmission channel

    Does this ring a bell?

    Wednesday, November 5, 2014 4:01 PM
  • The IP range configured for the default connector (which is not the default setting, by the way, as you observed when you created the new custom connector), prevented reception of mail from servers *without* those IP addresses.

    Since 192.168.x.x is a private IP range, it is expected that you would not be able to receive mail from external servers (that will necessarily have a publicly routable IP address - so something out of the 10.x.x.x, 172.16-21.x.x and 192.168.x.x ranges).

    Since mail reception was working before, something must have been changed at some point.

    Do you happen to know why the default IP range was changed on the default connector?

    I would tend to suggest changing the IP range setting back to the default - but of course I have no idea what someone may have been trying to accomplish.


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

    Wednesday, November 5, 2014 4:44 PM
  • I am assuming that the default range was changed to "lock down" Exchange to only accepting mail from the private network (where the Exchange Server resides).  However, if that is the case, I wonder why they didn't just limit it to the single IP (192.168.1.2) of the server itself.  Shouldn't the "Receive mail from these remote servers that have these IP addresses" field only list the mail servers that the company accesses?  I am wondering why does it now only work only if I keep the entire default (0.0.0.0 to 255.255.255.255) range of IPs.

    Anyway, it is working now and for the last three days since I deleted the old connector and created a new one.

    Friday, November 7, 2014 3:28 PM