Troubleshooting SMTP Connectivity

  • Article

 

The SMTP service is the internal transport engine of Exchange 2003 and is involved whenever messages are transferred. The SMTP service uses SMTP connectors to transfer messages to their destinations, similar to the way in which the Exchange MTA uses X.400 connectors. SMTP connectors are configuration objects that contain parameters that determine how the SMTP service establishes connections and transfers messages. However, SMTP connectors are not an absolute requirement for SMTP connectivity. Exchange 2003 virtual SMTP servers can also communicate directly with remote SMTP hosts.

The following are typical causes of message transfer problems over SMTP:

  • Host Unreachable   If the SMTP service cannot establish a connection to the remote SMTP host, verify that the address information for the remote host is correct and that the name of the remote host can be resolved to a valid IP address. If you know the IP address of the destination system, you can use Telnet.exe to try to establish a connection to TCP port 25. If you do not know the IP address of the destination system, start the NSlookup tool (NSlookup.exe) at a command prompt, and perform the following steps to query the destination domain's mail exchanger (MX) records:

    1. In the NSlookup tool, ensure that a network connection exists to your DNS server, and then type the command set type=mx and press ENTER.

    2. Type the domain name you are interested in (for example, microsoft.com) and then press ENTER. You should notice one or more MX records and the IP addresses for those hosts in the output screen (Figure 1).

    3. Type exit and press ENTER to exit the NSlookup tool.

    Figure 1   Determining the IP Address of an MX record for a destination domain

    e906dc52-bd1d-403e-b38b-6e1cd4693331

    If you are unable to connect to TCP port 25 on the destination system using Telnet.exe, see Knowledge Base article 169790, "How to Troubleshoot Basic TCP/IP Problems" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=169790).

  • Destination domain is unreachable   A message cannot reach its final destination because the SMTP service is unable to determine the MX record that is responsible for the domain. When the SMTP domain cannot be reached, the SMTP service informs the message originator in a non-delivery report (NDR) that the destination server for the recipient could not be found in DNS. This error can also appear if an incorrect address space of type SMTP has been assigned to one or more SMTP connectors. Use Exchange System Manager or the WinRoute tool to verify the message routing topology.

  • SMTP protocol errors   Protocol errors occur when the remote SMTP host responds to the local SMTP host's EHLO command with a 500-level error (for example, because the remote host does not support Extended SMTP) or when SMTP commands are out of sequence (for example, attempting MAIL FROM before EHLO). If a protocol error is detected, the sending system will QUIT the connection and report this with an NDR indicating that the remote SMTP server cannot handle the protocol. To see why a remote SMTP server rejects protocol requests, enable SMTP logging for the virtual server or use Network Monitor to trace the network communication. To activate SMTP logging, on the virtual server's General tab, select Enabling logging, and specify the logging format you prefer under Active log format.

  • SMTP address space is not configured for inbound message transfer   You must identify the SMTP address space of your Exchange organization as inbound to reach Exchange 2003 users from the Internet or another SMTP messaging system. For example, if your SMTP address is administrator@fourthcoffee.com, and fourthcoffee.com is not identified as an inbound address space, messages from the Internet addressed to administrator@fourthcoffee.com will not reach your mailbox. To verify that the Exchange organization is configured correctly, in Exchange System Manager, open Default Recipient Policy in the Recipient Policies container, and then switch to the E-Mail Addresses tab. Verify that the SMTP address generation rule contains the correct domain information. If the address information differs from your requirements (for example, if @contoso.com is specified for the Exchange organization, and you also need @fourthcoffee.com), create an additional SMTP address generation rule and ensure that the This Exchange Organization is responsible for all mail delivery to this address check box is selected.

  • Loop-back is detected   If you have multiple SMTP virtual servers configured on your Exchange server, ensure that they serve unique incoming ports and also that the outgoing SMTP port configuration is valid to avoid looping between local virtual servers. Ensure that if you have configured multiple virtual SMTP servers on your bridgehead server, none are set to All Unassigned in the IP address list on the General tab of the virtual server.

    If you are using SMTP connectors, you should also ensure that no SMTP connectors exist that have the address space of the local organization. If you must share the SMTP address space of the local organization with another messaging system, ensure that you forward all messages to specified smart hosts. Do not select Use DNS to route to each address space on this connector in your SMTP connector configuration. For detailed instructions about how to configure an SMTP connector, see How to Configure an SMTP Connector When Migrating from a Non-Exchange Messaging System to Exchange Server 2003.

Testing Messaging Connectivity

To test messaging connectivity, send e-mail messages to an Exchange user from an Internet messaging system (for example, Microsoft Hotmail®). You can specify the SMTP address for an Exchange recipient in Active Directory Users and Computers when you display the properties of the user account and switch to the E-mail Addresses tab. Remember to reply to the test message, and ensure that you receive the reply in Hotmail to verify that message routing works in both directions.

You can also use Telnet.exe to quickly test inbound message transfer to an Exchange 2003 recipient, as outlined in Knowledge Base article 153119, "Telnet to Port 25 to Test SMTP Communication" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=153119).

Examining SMTP Message Flow

The SMTP service consists of the following internal components, which handle message transfer between SMTP hosts and Internet-based e-mail clients on one side and Exchange 2003 on the other side:

  • SMTP protocol service   Handles SMTP communication with remote SMTP hosts and clients. This service implements the SMTP protocol commands that Exchange 2003 supports.

  • Store driver   Allows the SMTP service to communicate with the Exchange store to save messages that are passing through the SMTP service. The store driver also handles the delivery of messages to local recipients.

  • Advanced queuing engine   Provides queue management and logic for message delivery, routing, and relay.

  • Categorizer   Provides categorization services for inbound and outbound messages, such as distribution list expansion using Lightweight Directory Access Protocol (LDAP) and Active Directory.

  • Routing engine   Provides the routing logic required to pass outbound messages to the correct messaging connector.

  • Queue manager   Manages link queues, which are used to store messages that are waiting for transfer to the next remote destination.

Figure 2 shows how messages pass through the components of the SMTP service.

Figure 2   Message flow through the SMTP transport engine of an Exchange 2003 server

21faab23-61f3-4c77-a662-20449189a037

Check the SMTP message flow in the following order:

  1. **Check the SMTP log   **When you enable SMTP logging, as mentioned earlier in this topic, verify that messages from a remote host are transferred successfully to the local SMTP protocol service, or that messages from the local SMTP protocol service are transferred successfully to a remote host. The following is a sample log listing that shows the results of the Telnet communication discussed earlier:

    #Software: Microsoft Internet Information Services 6.0

    #Version: 1.0

    #Date: 2003-11-30 22:33:03

    #Fields: date time c-ip cs-username s-sitename s-computername s-ip s-port cs-method cs-uri-stem cs-uri-query sc-status sc-win32-status sc-bytes cs-bytes time-taken cs-version cs-host cs(User-Agent) cs(Cookie) cs(Referer)

    2003-11-30 22:33:03 192.168.202.223 - SMTPSVC1 SERVER01 192.168.202.199 0 HELO - - 250 0 50 4 10 SMTP - - - -

    2003-11-30 22:34:05 192.168.202.223 - SMTPSVC1 SERVER01 192.168.202.199 0 MAIL - +FROM:<user@contoso.com> 250 0 41 28 40 SMTP - - - -

    2003-11-30 22:35:03 192.168.202.223 - SMTPSVC1 SERVER01 192.168.202.199 0 RCPT - +TO:<Administrator@contoso.com> 250 0 38 35 10 SMTP - - - -

    2003-11-30 22:37:42 192.168.202.223 - SMTPSVC1 SERVER01 192.168.202.199 0 DATA - <SERVER01MTwKnhoKQXw00000001@server01.contoso.com> 250 0 133 30 134223 SMTP - - - -

    2003-11-30 22:38:16 192.168.202.223 - SMTPSVC1 SERVER01 192.168.202.199 0 QUIT - - 240 331987 69 4 10 SMTP - - - -

  2. Check the Messages Pending Submission queue   In Exchange System Manager, in the Queues container, select Messages Pending Submission, and then click Find Messages. When the SMTP protocol service accepts and acknowledges a message, it places the message in this queue. The Messages Pending Submission queue is also called the pre-submission queue, because messages in this queue have not been processed by the categorizer yet. The pre-submission queue is the entry point into the advanced queuing engine.

    Note

    If messages constantly accumulate in the pre-submission queue, this might indicate a performance problem. Occasional peaks in CPU performance can cause messages to appear in this queue intermittently. Frequently, problems with event sinks (for example, custom SMTP processing code for antivirus screening and for disclaimers) cause messages to accumulate in this queue.

  3. Check the Messages Awaiting Directory Lookup queue   The advanced queuing engine places the message from the pre-submission queue into this queue so that the categorizer can process it. The Messages Awaiting Directory Lookup queue is also called the pre-categorization queue, because it is a throttling queue for the categorizer. The Messages Awaiting Directory Lookup queue contains messages while the categorizer resolves the sender and recipient information against Active Directory, expands distribution lists, checks restrictions, applies per sender and per recipient limits, and so on.

    Messages can accumulate in the pre-categorization queue if the categorizer cannot process the messages. The categorizer might not be able to access the global catalog to access recipient information, or the global catalog lookup might be performed slowly. On front-end servers, messages also remain in the Messages Awaiting Directory Lookup queue if you disable the Exchange store. It is recommended that you keep the Exchange Information Store service running on front-end servers to process messages successfully.

    If you want to obtain information about categorizer processing, increase the level of event logging for the MSExchangeDSAccess and MSExchangeTransport services. Set the logging level for all categories to Maximum to obtain most detailed information.

    Note

    Setting the diagnostics logging level to Maximum can cause a large number of events to be written to the application event log. As a best practice, set the size of the application and system event log to 30 MB, and enable the option to overwrite events as needed. Remember to reapply the default setting of None after you finish connector testing.

  4. Check the Local Delivery queue   When the recipient's mailbox resides on the local Exchange 2003 server, the message categorizer marks the recipient as local by setting a per-recipient property that indicates the destination server according to the recipient's homeMDB attribute, which points to the private store where the recipient's mailbox resides. (At this point, the messages are in the post-categorization queue.) For local recipients, routing is skipped, and the advanced queuing engine transfers the messages to the Local Delivery queue, from which the Exchange store driver obtains them for local delivery to an Exchange mailbox. Messages accumulate in this queue if the Exchange Information Store service is not accepting messages or has a performance problem. To obtain detailed information in the application event log about why messages are accumulating in the Local Delivery queue, you can enable diagnostics logging for the MSExchangeIS service and for the MSExchangeTransport service.

  5. Check the Messages Waiting To Be Routed queue   This queue holds messages for remote delivery. The advanced queuing engine transfers messages for non-local recipients from the post-categorization queue into this queue, which is also called the pre-routing queue. The advanced queuing engine then calls the routing engine to move the messages to their respective link queues. Messages might accumulate in the pre-routing queue if routing problems exist. If messages accumulate in the pre-routing queue, increase the diagnostics logging level for the MSExchangeTransport service for the Routing category to obtain additional information.

  6. Check the remote delivery (link) queues   Link queues are dynamic in nature and are managed by the queue manager component. The name of the queue matches the remote delivery destination. If the queue is in a retry state (that is, failed connection attempts occurred), use Telnet.exe to try to connect to the destination host, as explained earlier in this section. To immediately retry sending the messages that are queued, restart the virtual SMTP server.

  7. Check the Messages With An Unreachable Destination queue   Messages in this queue cannot reach their final destination server. For example, Exchange cannot determine a route or a connector to the final destination, or all available routes or connectors are labeled as down. Check the routing configuration in your Exchange 2003 organization to ensure that at least one connector to the destination is available. To retry sending the messages that are queued, restart the virtual SMTP server.

  8. Check the Messages Queued For Deferred Delivery queue   This queue contains messages that are queued for later delivery. When this option is set, the Messages Queued for Deferred Delivery queue includes messages that were sent by older versions of Microsoft Outlook, such as Microsoft Outlook 2000. Newer versions of Outlook queue these types of messages in the Exchange store. Messages remain in the Messages Queued For Deferred Delivery queue until their scheduled delivery time. Other reasons why messages can end up in this queue include:

    • A message is sent to a user's mailbox while the mailbox is being moved.

    • The user does not yet have a mailbox, and no master account security ID (SID) exists for the user. For further information, see Knowledge Base article 316047, "XADM: Addressing Problems That Are Created When You Enable ADC-Generated Accounts" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=316047).

    • SMTP message routing is configured in a way that causes a message to loop. SMTP moves looping messages to this queue, so you can correct the problem without messages immediately returning an NDR. Moving messages to the Messages Queued For Deferred Delivery queue also helps to prevent a performance impact to the server resources.

  9. Check the DSN Messages Pending Submission queue   This queue contains delivery status notifications (DSNs) that are waiting to be rendered by Exchange. For example, NDRs are delivery status notifications. Messages can accumulate in the DSN Messages Pending Submission queue under the following conditions:

    • The Information Store service is unavailable or is not running.

    • A private store is not mounted.

    • Issues exist with the IMAIL Exchange store component. IMAIL is the component that performs message conversion.

    To obtain detailed information in the application event log about why messages are queuing up in the DSN Messages Pending Submission queue, increase diagnostics logging for all categories of the MSExchangeIS service.

Check the Failed Message Retry queue   This queue contains messages that failed a queue submission. Messages can fail a queue submission for several reasons, and the failure can occur before any other processing has been done. If messages are corrupted or system resources are low, messages appear in this queue. If messages appear in the Failed Message Retry queue, review your server configuration to determine whether you have non-Microsoft programs or event sinks installed, such as virus scanners, that can interfere with message queuing. If the computer responds slowly, use Windows Task Manager to identify processes that use too many system resources. Restarting the Internet Information Services (IIS) Admin service might provide temporary relief until you can determine the root cause of the problem. By default, messages in the Failed Message Retry queue are reprocessed every 60 minutes.