The Extended SMTP (ESMTP) protocol is fully backward-compatible with SMTP. Any SMTP commands will also work with ESMTP. The ESMTP protocol extends SMTP by offering additional commands for capabilities such as delivery notification, host authentication and encryption. In most cases, ESMTP commands are designed to improve security and efficiency over standard SMTP.
When an ESMTP-aware client attempts to send an email message, it initially tries to use ESMTP. If the recipient doesn't support ESMTP, then the host will use SMTP. The process works by transmitting an ESMTP command, and then using the response code to determine whether or not the recipient recognized the command.
The process begins when the sender initiates a connection to the recipient. When connectivity is established, the recipient returns a response code of 220, indicating that the connection is open. This is the same thing that happens when a normal SMTP connection is initiated.
When SMTP is being used, the sender then transmits a HELO command to identify itself and signal the start of an SMTP session. If the sender supports the ESMTP protocol, it will issue the EHLO command, instead of HELO. This requests that the ESMTP protocol be used for the session.
If the recipient supports ESMTP, it will respond with the code 250, indicating that the recipient recognizes the EHLO command and supports the ESMTP protocol and t will continue to use this protocol.
If the recipient doesn't support the ESMTP protocol, it won't recognize the EHLO command. Instead, it will return the response code 500, indicating that the sender should revert to the SMTP protocol. The sender will then transmit the HELO command to begin a normal SMTP session.
There are various commands available as a part of the ESMTP protocol. Most of these commands are not Microsoft-specific, with the exception of a few. Following are examples of some commands in the ESMTP protocol.
The TURN command is used in situations in which the recipient doesn't host his own mail server. In such situations, the recipient's ISP hosts its own SMTP server. When the recipient establishes a dial-up connection to the ISP, he could require that turn commands query the host for any messages that have been queued. ATRN is an authenticated turn command that only works if the session has been authenticated.
The AUTH command provides authentication. A parameter is used in conjunction to this command to tell AUTH which Simple Authentication and Security Layer (SASL) mechanism the authentication process it should use.
Microsoft hosts typically authenticate using Kerberos and NTLM. The command to support these authentication methods is AUTH GSSAPI NTLM LOGIN.
The AUTH=LOGIN command is simply the AUTH command with the LOGIN parameter specified. This command is important because it provides SASL authentication to SMTP sessions for non-Microsoft or legacy Microsoft hosts, such as Exchange 5.5.
The STARTTLS command allows a client to initiate a TLS-based Secure Socket Layer (SSL) connection between itself and the SMTP server.
The VRFY command, referenced in RFC 821, is used to determine whether or not a specified email account exists or has been disabled. This command is almost always disabled because it is easily exploitable. Spammers can use the VRFY command for directory harvesting. Likewise, hackers can use this command to figure out the names of user accounts in your organization.
The Exchange 2003 implementation of VRFY informs the host using this command that the user cannot be verified, but that messages to the user will be accepted.
Microsoft Exchange Server-specific commands
The ESMTP protocol is not Microsoft-specific; it is specified in RFC 1869. Many other SMTP-enabled applications use the ESMTP protocol. There are, however, some Exchange-specific commands that have been included in Microsoft's ESMTP implementation.
All Exchange Server-specific commands start with the letter X. The ESMTP protocol is natively supported by Exchange Server 2003, which extends the ESMPT protocol by adding the commands listed below:
Although this command might first appear to be a reference to Exchange 5.0, it is fully supported in Exchange Server 2003. This command typically is used when a connection is established between two Exchange servers. It facilitates the transfer of message transport envelope properties in Message Database Encoding Format (BDBEF) during Exchange server-to-Exchange server communications.
X-EXPS GSSAPI NTLM LOGIN
This command does almost the exact same thing as the AUTH command, except that it is meant to provide authentication between Exchange servers. It provides Kerberos and NTLM authentication to Microsoft hosts.
Regarding the command syntax, the X-EXPS portion is the actual command. The GSSAPI, NTLM, and LOGIN parameters indicate which authentication methods the Exchange Server supports.
In this command (and in the AUTH command), the GSSAPI parameter indicates that the Generic Security Service Application Programming Interface can be used. This enables Kerberos authentication.
The TNTLM protocol indicates that it supports Windows NT Challenge/Response and LAN Manager authentication. The LOGIN parameter indicates that the AUTH LOGIN command can also be used. This authentication method requires a base 64-encoded username and password.
The X-EXPS=LOGIN command is a variation of the X-EXPS command. But this variation is usually used for NTLM authentication for Exchange 5.5 servers.
This is an Exchange-specific command that allows a host to advertise that it can exchange link-state information.
TUTORIAL: A PRIMER ON SMTP AND ESMTP SERVERS AND COMMANDS
Part 1: SMTP commands and server response codes
Part 2: How to perform a Telnet SMTP session for Exchange Server 2003
Part 3: How Extended SMTP works and common ESMTP commands
Part 4: Security-related and Exchange-specific ESMTP commands
|ABOUT THE AUTHOR:|
| Brien M. Posey, MCSE
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server, and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.