SMTP Protocol Extensions

 

Topic Last Modified: 2006-11-03

The advanced queuing engine is not the only dispatcher of COM events in the SMTP service. The SMTP protocol engine is also a main dispatcher of COM events, specifically SMTP protocol events. The core SMTP protocol engine is responsible for all standard SMTP communication and handles most of the standard SMTP service extensions (that is, the Extended Simple Mail Transfer Protocol (ESMTP) standard, as defined in 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 2003 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 2003 are loaded when you connect to the TCP port of your SMTP virtual server using telnet. As shown in the following figure, the server response indicates the features that the SMTP virtual server supports when you submit the EHLO command to initiate an ESMTP connection. The standard commands are listed when you submit a HELP command.

Standard and extended SMTP commands of Exchange Server 2003

7fee5659-17ca-4ed0-9e01-97592772cb9e

The following table explains the SMTP features that the Exchange-extended SMTP service supports.

SMTP features supported in Exchange Server 2003

SMTP Server Response Comments

8BITMIME

Indicates that the local SMTP virtual server supports eight-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 keyword with CHUNKING, 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 sent by the BDAT command, the server assumes it 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 contains binary material without transport encoding by using a BODY parameter with a value of "BINARYMIME" 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 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 (Figure 6.14).

ENHANCEDSTATUSCODES

Indicates that the SMTP server provides enhanced error status codes. Text part of all SMTP status responses, other than the initial greeting and any response to HELO or EHLO, are prefaced with a status code as defined in RFC 1893.

ETRN

Sent by an SMTP server to request that the local virtual server send any e-mail messages that it has in the queue for the domains indicated in the ETRN command.

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

MAIL

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

TURN

Allows a remote host and the local host to switch roles and send mail in the reverse direction, without establishing a new connection.

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 2003, but 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@TailspinToys.com>

XEXCH50

Provides the ability to send extended message transport envelope properties in Message Database Encoding Format (MDBEF) format during an Exchange Server 2003 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 Server 2003 and Exchange 2000 Server 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 used to propagate link state information within and between routing groups, see Message Routing Architecture.

noteNote:
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 2003 base version of the SMTP service. In this case, you must reinstall Exchange Server 2003 and any Service Packs.

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.

The Exchange Server 2003 Setup program registers Exchange-specific SMTP protocol extensions for the following SMTP protocol features:

  • XEXCH50   This feature is implemented using nine event sinks to support a full communication between two servers running Exchange Server. 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 request the SMTP service to send an XEXCH50 command instead 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 RCPT 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 (Figure 6.14).

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

For complete information about SMTP, see SMTP Server.

 

Community Additions

ADD
Show: