Part 3: How Extended SMTP works and common ESMTP commands

Learn how Extended STMP (ESMTP) works and discover the functionality of several common ESMTP commands.

ESMTP is a version of the SMTP protocol that has been augmented to support additional commands. Although ESMTP...

is the chosen protocol for SMTP communications, ESMTP is not unique to Exchange. Windows 2000 Server and Windows Server 2003 both support the ESMTP protocol by default. There also are ESMTP-based clients available for Macintosh and Unix-based operating systems.

ESMTP extends the SMTP protocol, meaning that Exchange Server and other products that support the ESMTP protocol can perform tasks that wouldn't be possible with basic SMTP, such as email message delivery notification. But both the sending host and the receiving host must support the ESMTP protocol for these extended capabilities to be realized. If the receiving host doesn't support ESMTP, the session will revert to standard SMTP.

Determining support

In Part 2, you learned how to use the HELO command to establish an SMTP session with another host. ESMTP has its own version of the HELO command -- EHLO.

When an ESMTP-enabled host wants to initiate an ESMTP session with a receiving host, the sending host initiates the session by sending the EHLO command. If the receiving host supports ESMTP, then it will recognize the EHLO command and issue a response code of 250. The sending host can now use both SMTP and ESMTP command sets.

If the receiving host does not recognize the EHLO command, then it will issue a response code of 500, which indicates that the command was unrecognized; therefore, the host doesn't support ESMTP.

If this occurs, then the sending host transmits a HELO message and initiates a normal SMTP session. In doing so, the sending host will be able to communicate with the receiving host, but the extended SMTP command set won't be available for the duration of the session.

The difference between HELO and EHLO is shown in Figures K and L. Figure K shows an SMTP session that has been initiated using the HELO command.

Figure K
Figure K. An example of a working HELO command.

Figure L shows an ESMTP session that has been established using the EHLO command

Figure L
Figure L. A look at an ESMTP session established via the EHLO command.

In Figure L, you will see that there are several lines of text displayed after the EHLO command. When the EHLO command is sent, the sending host also tests the receiving host to ensure that it supports various ESMTP commands and functions. The lines of text you see are results of these tests. For example, in Figure l, there is a line that reads:

250 – SIZE

This line is indicates that the receiving host supports the SIZE command.

Common ESMTP commands

Following is a summary of some commonly used ESMTP commands.


Many organizations implement a maximum size limit for inbound email messages. Imposing such a limit prevents senders from running a server out of disk space or launching a denial-of-service attack by emailing a message with an extremely large attachment.

The problem with specifying a maximum message size is that the basic SMTP command set doesn't acknowledge the specified message size limit. This means that if messages were sent with an attachment exceeding the maximum size, the receiving host would have to receive the message in its entirety before it could determine that the message was too large. The message would eventually be blocked, but only after wasting a lot of bandwidth.

The SIZE command, described in RFC 1870, allows the receiving host to tell the sending host the maximum message size before the message is transmitted.


The DATA command is used to send the actual SMTP message. The DATA command is free form in nature. The message can be of any length or structure. The only way that the DATA command can tell where the message ends is by looking for a special code, for example ( . ) .

If a server normally handles only small messages or a small volume of email, looking for this code is not an issue. However, scanning each packet for a termination code is inefficient, so it's impractical for larger mail systems.

This is where the BDAT command comes into play. This command replaces the DATA command. The BDAT command sends the message size and the message itself. When the receiving host has received the number of bytes specified by the BDAT command, it assumes that it has reached the end of the message. Using this technique frees the server from having to scan every packet for an end-of-message flag.

You might have noticed in Figure L that the BDAT command isn't listed among the test results. Although the BDAT command is not listed specifically, CHUNKING is listed. Chunking describes the process of transmitting a byte count prior to transmitting a chunk of data.


The CHUNKING command indicates that the recipient supports the use of the BDAT command. The BDAT command is used as an alternative to the DATA command.

When the DATA command is used, the recipient must scan the data stream continuously to determine where the email message ends. But this process is inefficient. The BDAT command contains an argument that specifies the message size. This means that the recipient can count the inbound data to determine where a message ends. The BDAT command also allows the use of an optional second argument that indicates whether or not the current data packet is the last packet in the current transmission.


The DSN command notifies the host of a delivery failure, and is considered an improvement over simple non-delivery reports. The DSN command is described in RFC 1891.


The ETRN command, described by RFC 1985, is similar to the standard SMTP TURN command. The difference is that it specifies the remote host to which mail should be delivered.


The HELP command displays a list of commands that SMTP hosts support.


When the sending host transmits a command, the SMTP protocol waits for a response code before it will transmit the next command. However, this is an inefficient way to communicate with a host.

Because current networks are reliable enough, the transmit-and-wait nature of SMTP is no longer necessary. As an alternative, ESMTP supports pipelining. Pipelining refers to the host's ability to send commands in batches, without having to wait for a response after each command.

8-bit MIME Format

To fully understand 8-Bit MIME (displayed as 8bitmime), you must understand that email has evolved. When email was first invented, messages consisted solely of ASCII text. As such, email messages typically used a 7-bit encoding scheme, which was ideally suited for messages consisting of letters, numbers and a few special symbols.

Email messages now typically include things like HTML-based bodies, large attachments and characters that are not a part of the ASCII character set. But even though the nature of email has changed dramatically, SMTP still encodes messages in a 7-bit format.

This 7-bit format was never designed to store this type of data. To get around the limitations of 7-bit encoding, SMTP messages typically are encoded in 8bitmime, and then encapsulated in a 7-bit packet for transmission. Upon receipt, the 7-bit capsule is stripped away, and the message is converted back to its original 8bitmime format.

This encapsulation process causes the mail server do additional work, which is why the ESMTP protocol supports 8bitmime natively. When an ESMTP session is established between two mail servers that support 8bitmime, then email can be transmitted and received in this format without the need for 7-bit encapsulation. This enhances server performance.


 Home: Introduction
 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

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
This was last published in November 2007

Dig Deeper on Email Protocols



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.