SMTP Protocol Extensions for Exchange Server 2007
Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3
The Simple Mail Transfer Protocol (SMTP) engine is a main dispatcher of COM events. The core SMTP protocol engine is responsible for all standard SMTP communication and handles most of the standard SMTP service extensions. Specifically, the core SMTP engine handles the Extended Simple Mail Transfer Protocol (ESMTP) standard that is defined in Request for Comments (RFC) 821 and RFC 1869. Protocol events can be used to modify the SMTP protocol to add new ESMTP commands or even to change the action of existing commands. Exchange Server 2007 uses these protocol events to implement Exchange-specific extended SMTP commands to communicate with other Exchange servers in the organization more efficiently than over standard SMTP.
You can verify that the extended SMTP commands for Exchange Server 2007 are loaded by using telnet to connect to the TCP port of your SMTP virtual server. When you submit the EHLO command to initiate an ESMTP connection, the server response indicates the features that the SMTP virtual server supports. The standard commands are listed when you submit a HELP command.
The following table explains the SMTP features that the Exchange-extended SMTP service supports.
SMTP features that are supported in Exchange Server 2007
SMTP Server Response | Comments |
---|---|
8BITMIME |
Indicates that the local SMTP virtual server supports 8-bit Multipurpose Internet Mail Extensions (MIME) messages. |
AUTH, AUTH GSSAPI NTLM LOGIN, and AUTH=LOGIN |
Signals that the local SMTP virtual server supports the SMTP authentication service extension. The additional information after the AUTH key word identifies the supported authentication mechanisms. |
BDAT, CHUNKING |
An alternative to the DATA command, which takes two arguments. When an SMTP virtual server responds to the EHLO command with the CHUNKING response, the SMTP server is indicating that it supports the BDAT command and will accept messages in chunks. The first argument indicates the length of the binary data packet, so that the SMTP host does not have to continuously scan for the end of the data. The receiving server counts the bytes in the message, and when the message size equals the value that is sent by the BDAT command, the server assumes that it has received all the message data. The second argument indicates whether the data packet is the last packet in the current transmission. The second argument is optional. |
BINARYMIME |
Indicates that the SMTP virtual server accepts messages that contain binary material without transport encoding. These messages must use a BODY parameter that includes the BINARYMIME value together with the MAIL command. When the SMTP server accepts a MAIL command with a BODY parameter of BINARYMIME, the server agrees to preserve all bits in each octet that are passed using the BDAT command. The BINARYMIME SMTP extension can only be used with CHUNKING. |
DATA |
Sent by a remote host to initiate the transfer of message content. |
DSN |
An ESMTP command that enables delivery status notifications as defined in Request for Comments (RFC) 1891. |
EHLO |
Sent by a client to signal the start of an ESMTP session. The server can identify its support for ESMTP commands in its response to EHLO. |
HELO |
Sent by a client to identify itself, usually with a domain name, and to signal the start of a standard SMTP session. |
HELP |
Returns a list of SMTP commands that are supported by the SMTP virtual server in standard SMTP sessions (as opposed to ESMTP sessions). |
Identifies the start of a message transfer by identifying the sender of the message; used in the form MAIL FROM. |
|
PIPELINING |
Provides the ability to send a stream of commands without having to wait for a response after each command. |
QUIT |
Signals the end of a standard or extended SMTP session. |
RCPT |
Identifies the message recipients; used in the form RCPT TO. |
RSET |
Nullifies the entire message transaction and resets the buffer. |
SIZE |
Provides a mechanism by which the SMTP virtual server can indicate the maximum supported message size. Compliant servers must provide size extensions to indicate the maximum message size that can be accepted. Remote hosts should not send messages that are larger than the size that is indicated by the server. |
STARTTLS |
Indicates that the SMTP server supports secure SMTP over Transport Layer Security (TLS). The SMTP service extension for secure SMTP over TLS is defined in RFC 2487. |
VRFY |
Verifies that a mailbox is available for message delivery. For example, VRFY TED verifies that a mailbox for Ted resides on the local server. By default, this command is available in Exchange 2007, but it does not verify users. The server will inform the remote host that, although the user cannot be verified, messages will be accepted. The server response has the following format: 252 2.1.5 Cannot VRFY user, but will take message for Ted@wingtiptoys.com |
XEXCH50 |
Provides the ability to send extended message transport envelope properties in Message Database Encoding Format (MDBEF) format during an Exchange 2007 server-to-server communication. |
X-EXPS GSSAPI NTLM LOGIN, X-EXPS=LOGIN |
X-EXPS is a command that is proprietary to Exchange. It is similar to AUTH because it indicates the methods that can be used by servers running Exchange 2007, Exchange 2003, and Exchange 2000 to authenticate, as follows: GSSAPI A method that stands for Generic Security Services Application Programming Interface and enables authentication through Kerberos. NTLM A method that stands for Windows NT and LAN Manager and enables authentication using the Windows NT Challenge/Response protocol. LOGIN A method that stands for AUTH LOGIN, a clear text authentication method using a base-64-encoded user name and password. |
X-LINK2STATE |
Adds support for link state propagation to the SMTP service. For details about the link state algorithm that is used to propagate link state information within and between routing groups, see Message Routing Architecture. |
Note
All Exchange-specific SMTP commands start with "X-" (without the quotation marks). If these commands are not listed in the EHLO response of your SMTP virtual server, then the server is running the Windows Server-based version of the SMTP service. If this occurs, you must reinstall Exchange Server 2007 and any service packs.
Protocol Event Categories
The SMTP protocol engine triggers protocol events to control the host-to-host communication. There are three main types of events that can occur in such a communication over SMTP:
The SMTP service receives an SMTP command
These events occur when a remote SMTP host or client connects to the local SMTP service and establishes a session by sending the HELO or EHLO command. Events in this category are SMTP Protocol OnInboundCommand events on incoming connections.
The SMTP service receives an SMTP response
These events occur when the local SMTP service receives responses from a remote SMTP host or client to outbound SMTP commands. Events in this category are SMTP protocol OnServerResponse events on outbound connections.
The SMTP service sends an SMTP command
These events occur when the local SMTP service connects to a remote SMTP host and establishes a session to transfer messages. Events in this category are SMTP protocol OnSessionBegin, OnMessageStart, OnPerRecipient, OnBeforeData, and OnSessionEnd events on outbound connections.
The following table summarizes the purpose of each SMTP protocol event.
Protocol events in the SMTP service
Event | Comments |
---|---|
OnInboundCommand |
Occurs when an SMTP command is received by the SMTP protocol service, which gives an event sink an opportunity to respond. |
OnServerResponse |
Occurs when the SMTP service receives an SMTP response to a previously sent SMTP command. |
OnSessionBegin |
Occurs before the EHLO command is transmitted. |
OnMessageStart |
Occurs before the MAIL FROM command is transmitted. |
OnPerRecipient |
Occurs before the RCPT TO command is transmitted. |
OnBeforeData |
Occurs before the DATA protocol command is transmitted. |
OnSessionEnd |
Occurs before the QUIT command is transmitted. |
Exchange-Specific SMTP Protocol Extensions
The Exchange Server 2007 Setup program registers Exchange-specific SMTP protocol extensions for the following SMTP protocol features.
XEXCH50
XEXCH50 is an Exchange ESMTP extension that is used to relay certain message properties, such as envelope message and recipient properties. The XEXCH50 command is a short command. An XEXCH50 command that has received a success type response is followed by a binary large object (BLOB) of variable size. (The size corresponds to the first argument of the XEXCH50 command.)
This feature is implemented using nine event sinks to support a full communication between two servers running Exchange. The following table maps the protocol events to their XEXCH50 event sinks. All XEXCH50 sinks are implemented in Peexch50.dll, which resides in the Program Files\Exchsrvr\bin directory.
Protocol extensions for the XEXCH50 command
Event sink | Protocol event | Comments |
---|---|---|
Exchange SMTP Protocol XEXCH50 Before Data Sink |
OnBeforeData |
Notifies the XEXCH50 sink that the DATA protocol command is about to be transmitted. The XEXCH50 sink now has the opportunity to ask the SMTP service to instead send an XEXCH50 command to start an XEXCH50 communication. |
Exchange SMTP Protocol XEXCH50 Inbound EHLO Sink |
OnInboundCommand |
Notifies the XEXCH50 sink that an EHLO command was received. |
Exchange SMTP Protocol XEXCH50 Inbound XEXCH50 Sink |
OnInboundCommand |
Implements the XEXCH50 command to start an XEXCH50 conversation. |
Exchange SMTP Protocol XEXCH50 Inbound MAIL Sink |
OnInboundCommand |
Implements the MAIL command in an XEXCH50 conversation. |
Exchange SMTP Protocol XEXCH50 Inbound MAIL Sink |
OnInboundCommand |
Enables the local SMTP virtual server to receive recipient information in an incoming XEXCH50 communication. |
Exchange SMTP Protocol XEXCH50 Per Recipient Event Sink |
OnPerRecipient |
Enables the local SMTP virtual server to send recipient information in an outgoing XEXCH50 communication. |
Exchange SMTP Protocol XEXCH50 Ehlo Response Sink |
OnServerResponse |
Enables the local SMTP virtual server to receive a response after an EHLO command is sent to the remote host. The response from the remote host might indicate support for XEXCH50 communications. Exchange includes XEXCH50 in the list of supported commands that are returned to the connecting host. |
Exchange SMTP Protocol XEXCH50 Response Sink |
OnServerResponse |
Enables the local SMTP virtual server to receive a response to a previously issued outbound XEXCH50 command. For example, if the local SMTP service issued an XEXCH50 command without prior authentication, the remote server responds with: 504 Need to authenticate first. |
Exchange SMTP Protocol XEXCH50 RCPT Response Sink |
OnServerResponse |
Enables the local SMTP virtual server to receive status information from the remote Exchange server for each recipient indicated with an outbound RCPT command. A recipient address might be incorrectly formatted or the server might be unable to relay. If the recipient information is correct, the remote SMTP virtual server reflects the address back to the local SMTP service with status information, such as: 250 2.1.5 administrator@tailspintoys.com. |
X-LINK2STATE
X-LINK2STATE commands and responses are specific extensions of SMTP. This command is proprietary to Exchange, and is designed to exchange routing topology information between Exchange SMTP servers. The maximum possible size of any X-LINK2STATE command and response is 1,024 bytes. This size is frequently the actual size of X-LINK2STATE commands and responses.
This feature is implemented using five event sinks. However, one event sink is used for two separate events, as indicated in the following table. All X-LINK2STATE event sinks are implemented in Xlsasink.dll in the \Program Files\Exchsrvr\bin directory.
Protocol extensions for the X-LINK2STATE command
Event sink | Protocol event | Comments |
---|---|---|
EHLO Inbound Command Handler Sink for XLSA |
OnInboundCommand |
Notifies the X-LINK2STATE event sinks that an incoming EHLO command was received. |
X-LSA Inbound Command Handler Sink |
OnInboundCommand |
Notifies the X-LINK2STATE event sinks that an incoming X-LINK2STATE command was received. |
X-LSA Sink |
OnMessageStart, OnSessionEnd |
Signals the start (MAIL command) and end (QUIT command) of an outbound X-LINK2STATE communication. Because the remote SMTP virtual server is the ultimate recipient of the Orginfo packet being transmitted, there is no need to specify recipients in an outbound RCPT command. This event sink transmits the link state information. |
X-LSA Response Handler Sink |
OnServerResponse |
Responds to an incoming X-LINK2STATE command with information about how to transmit the link state information. An example of a response is: 200 LAST CHUNK={00000029} MULTI (5) ({00000010} DONE_RESPONSE), which indicates the last chunk of data sent by this SMTP virtual server. |
EHLO Response Handler Sink for X-LSA |
OnServerResponse |
Responds to an incoming EHLO command by listing the X-LINK2STATE command in the server response |
X-EXPS
X-EXPS is a verb that is proprietary to Exchange, though it is similar to AUTH. There is no maximum size limit for the data chunks, or the number of data chunks exchanged. The syntax of the data commands and responses depends on the AUTH package that you select, such as LOGIN, NTLM, GSSAPI, or others. For more information, see the AUTH RFC.
Although EXPS stands for Exchange Protocol Security, the only protocol that it refers to is the SMTP. Some verbs that are used in Exchange 2000 Server and in Exchange Server 2003 are proprietary to these products and are together with ESMTP verbs. They are known as ESMTP X verbs.
These features are implemented using five event sinks, as listed in the following table. All protocol security extensions are implemented in Exps.dll in the Program Files\Exchsrvr\bin directory.
X-EXPS protocol security extensions
Event sink | Protocol event | Comments |
---|---|---|
Exchange SMTP Protocol Security EXPS-EOD Sink |
OnInboundCommand |
Signals the end of data transfer ( _EOD). |
Exchange SMTP Protocol Security EXPS-Aux Sink |
OnInboundCommand |
Signals an incoming AUTH command. |
Exchange SMTP Protocol Security EHLO Sink |
OnInboundCommand, OnServerResponse |
Signals an incoming EHLO command and responds to EHLO by listing the X-EXPS command in the server response. |
Exchange SMTP Protocol Security Mail Sink |
OnInboundCommand, OnServerResponse, OnMessageStart |
Indicates the start of data transfer. This event sink is implemented for all relevant MAIL command scenarios. This event sink processes events that signal an incoming MAIL command, respond to an incoming MAIL command, and issue an outbound MAIL command. |
Exchange SMTP Protocol Security EXPS Sink |
OnInboundCommand, OnServerResponse, OnSessionStart |
Indicates the start of an X-EXPS session. This event sink is implemented for all relevant X-EXPS command scenarios. This event sink processes events that signal an incoming X-EXPS command, respond to an incoming X-EXPS command, and can issue an outbound X-EXPS command. |
SPAM Control
This feature is implemented using three event sinks that process sender and recipient information on incoming SMTP connections, as listed in the following table. The spam control event sinks are implemented in Turflist.dll in the Program Files\Exchsrvr\bin directory.
Spam control SMTP extensions
Event sink | Protocol event | Comments |
---|---|---|
RCPT Inbound Command Handler Sink |
OnInboundCommand |
Signals an inbound RCPT command with a recipient address that should be checked. |
MAIL Inbound Command Handler Sink for TURF |
OnInboundCommand |
Signals an inbound MAIL command with a sender address that should be checked. |
EOD Inbound Command Handler Sink |
OnInboundCommand |
Signals an inbound _EOD command. |
X-ANONYMOUSTLS
This parameter is new for Exchange 2007. This parameter enables the selection of an inbound anonymous Transport Layer Security (TLS) certificate or the selection of an outbound anonymous Transport Layer Security (TLS) certificate. Exchange queries the Active Directory directory service to retrieve the thumbprint of the certificate on the server. The msExchServerInternalTLSCert attribute on the server object stores the certificate thumbprint.
If the msExchServerInternalTLSCert attribute cannot be read or if the value is null, Exchange does not advertise X-ANONYMOUSTLS in the SMTP session, and no certificate is loaded.
XLONGADDR
This parameter is new for Exchange 2007. This parameter enables the Receive connector to accept long X.400 e-mail addresses. The X.400 e-mail addresses are encapsulated in SMTP e-mail addresses by using the Internet Mail Connector Encapsulated Address (IMCEA) encapsulation method.
When the value of this parameter is $False, the maximum length for a complete SMTP e-mail address is 571 characters.
When the value of this parameter is $True, the following changes are made:
The XLONGADDR keyword is advertised in the EHLO response of the Receive connector.
The accepted line length of an SMTP session is increased to 8,000 characters.
Valid long addresses are accepted by the MAIL FROM: and RCPT TO: SMTP commands.
Therefore, X.400 e-mail addresses can be up to 1,860 characters long after IMCEA encapsulation.
The valid input range for this parameter is $True or $False. The default value is $False. You can only modify this parameter on Receive connectors that are configured on Hub Transport servers.
XRDST
This parameter is new for Exchange 2007. This protocol extension is used to communicate a routing destination that is associated with a message to the remote server. If a remote server does not advertise XRDST and if the message to be sent requires XRDST support, MSExchangeTransport event ID 2021 is logged in the event log. The symbolic name of this event is tuple_SmtpSendUnableToTransmitRDst. This event indicates that the message cannot be sent.
EXPS EXCHANGEAUTH GSSAPI NTLM
This parameter is new for Exchange 2007. This is a Default Receive connector services extensions that is advertised after X-ANONYMOUSTLS.
X-EXCHANGEAUTH SHA256
This parameter is new for Exchange 2007. This is a Default Receive connector services extensions that is advertised after X-ANONYMOUSTLS.