XFOR: SMTP Mail Relay May Stop Working When Using IIS/MCIS SMTP Service and Non-RFC EHLO/HELO Command Format

View products that this article applies to.

This article was previously published under Q240832

Expand all | Collapse all

SUMMARY

The Simple Mail Transfer Protocol (SMTP) service comes in Internet Information Server (IIS) 4.0 (Windows NT 4.0 Option Pack), IIS 5.0, and Microsoft Commercial Internet System (MCIS) 2.0 and 2.5. The SMTP service can be configured to relay mail between different mail systems (for example, Lotus Notes, Exchange Server, or UNIX SendMail). A connecting mail server using an improperly formatted EHLO/HELO command syntax can cause the connection to close and mail relay to stop working. For additional information, click the article number below to view the article in the Microsoft Knowledge Base:

230235 (http://support.microsoft.com/kb/230235/EN-US/ ) XCON: How to Configure the IIS SMTP Service to Relay SMTP Mail

The purpose of this article is to identify a possible source of a mail relay failure and suggest corrective action.

MORE INFORMATION

SMTP is used to send mail over the Internet. SMTP transactions use connection-oriented TCP as a transport layer mechanism. TCP Port 25 is the default port for sending mail. TCP Ports 110 or 143 are the default ports for receiving mail (clients typically use POP/POP3 or IMAP compliant mail applications for receiving mail--for example, Microsoft Outlook or Outlook Express).

A sending mail server transfers mail by first resolving the name and IP address of the mail servers for the destination domain by using the Domain Name Service (DNS). After the name of a mail server for the destination domain is resolved, the transmitting mail server establishes a session with that server. The initial session setup is by means of what is called a "three-way handshake" using the TCP/IP protocol stack. For additional information about three-way handshakes, click the article number below to view the article in the Microsoft Knowledge Base:

172983 (http://support.microsoft.com/kb/172983/EN-US/ ) Explanation of the Three-Way Handshake via TCP/IP

After the session is established on port 25, the receiving mail server reports a ready status. A network trace shows a response similar to the following:

SMTP: Rsp: Service ready, 133 bytes
      SMTP: Response = 220-mail.your-domain.com Microsoft SMTP MAIL ready at Sat, 28 Aug 1999 09:32:00 
          SMTP: Data = -0400 Version: 5.5.1774.114.11
          SMTP: Data = 220 ESMTP spoken here

The sending mail server is then required by RFC-1869 to start an SMTP session by sending an EHLO or HELO command. The EHLO command is supposed to be sent first and is recognized by SMTP servers that support Extended Simple Mail Transport Protocol (ESMTP). The EHLO/HELO command syntax requires that the domain name follow the EHLO/HELO command as shown here:

SMTP: Data, 12 bytes
      SMTP: Data = EHLO sub2.your-domain.com

If the receiving SMTP server does not recognize the EHLO command, it returns a Code 500 in accordance with RFC 821, and remains in the same ready state. The sending mail server should then try to start a session using HELO. If the receiving mail server is able to decipher the parameter in the EHLO/HELO command, normal session setup occurs. If the parameters cannot be interpreted, an error is generated. Possible errors include:

Code 501: If the SMTP server implements the EHLO command, but the command argument is unacceptable.
Code 502: If the SMTP server recognizes, but does not implement, the EHLO command.
Code 421: If the SMTP server determines that the SMTP service is no longer available.

If the sending mail server receives any of the above errors, it should issue an HELO or a QUIT command.

An example of an improper command argument is:

SMTP: Data, 12 bytes
      SMTP: Data = EHLO sub2.

This generates the following response from the receiving mail server:

SMTP: Rsp: Command syntax error in parameters or arguments, 21 bytes
      SMTP: Response = 501 Invalid Address

The sending mail server will re-try using the HELO format but the same error will occur. After a failure using both EHLO and HELO formats, the sending mail server will issue

  SMTP: Cmd: Quit, losing connection, 6 bytes
      SMTP: Command = QUIT

and the session will end and no mail transfer will occur between the two domains. In this particular instance, the receiving mail server is expecting a host name only or a Fully Qualified Domain Name (FQDN) following the EHLO/HELO command. Because there is a "trailing dot" after the host name (sub2.), this is interpreted as incorrect syntax and a 501 error is generated.

To remedy this situation, the sending mail server needs to be configured to send a host name only (sub2) or FQDN (sub2.your-company.com). If there is a host name only, the receiving mail server appends its own domain name, and the SMTP session is set up, provided there are no security restrictions that prevent mail relay from specific domains.

This behavior is by design and is in accordance with RFC 821 and 1869.