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�
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.