SMTP Commands and Sample Sessions

The easiest way to grasp how SMTP works is to look at a basic SMTP session. Example 6-1 details how a simple e-mail is transmitted between two mail devices using SMTP.

Example 6-1 SMTP Session

220 smtp-outbound.cisco.com ESMTP Sendmail 8.12.10/8.12.6 ; Fri, 20 Oct 2006

16:01:02 -0400 (EDT) HELO cisco.com

250 smtp-outbound.cisco.com Hello [192.168.1.1], pleased to meet you

MAIL FROM:< [email protected]>

250 2.1.0 [email protected]... Sender ok

RCPT TO:<
[email protected]>

250 2.1.5 [email protected]... Recipient ok

DATA

354 Enter mail, end with "." on a line by itself Subject: test message From: [email protected] To: [email protected]

Example 6-1 SMTP Session (Continued) Hello,

This is a test. Goodbye.

250 2.0.0 k9k1234567890 Message accepted for delivery QUIT

221 2.0.0 smtp-outbound.cisco.com closing connection

The SMTP session shown in Example 6-1 begins when the transmitting e-mail device or client initiates a TCP connection on port 25 to the receiving device, typically a mail server. The mail server answers the connection by identifying itself with a three-digit code followed by a greeting similar to the first line of Example 6-1. The three-digit codes preceding all the responses from the mail server are discussed later in this section. Notice that the e-mail client SMTP commands are shown in boldface type, whereas the e-mail server responses are shown in normal type.

The e-mail client responds to the server greeting with a HELO command and includes its domain name. The mail server then acknowledges the HELO command. Following that, the e-mail client submits the sending and receiving address to the mail server using the MAIL FROM: and RCPT TO:
SMTP commands. To make a parallel to standard mail, these two pieces of information are known as the SMTP envelope. The sender's e-mail address and the recipient's e-mail address are the only information used by the SMTP server to deliver the message.

The SMTP content is the body of the message, which also includes header information, and it is transmitted after proper acknowledgment from the e-mail server to the client's DATA command. Upon completion of the e-mail transaction, the e-mail client gracefully ends the SMTP session with a QUIT command.

Example 6-1 illustrates a basic SMTP session using the SMTP command HELO. However, an improved version of SMTP known as Extended Simple Mail Transfer Protocol (ESMTP) is an alternative that has more features and a greater versatility through added service extensions. ESMTP uses the command EHLO rather than HELO as an identification command. An example of an EHLO command and response session is shown in Example 6-2.

Example 6-2 EHLO Command and Response

In Example 6-2, you can see how the EHLO command elicits a more detailed response from the SMTP server. The server now includes its supported ESMTP extensions in the response. These extensions let the client know the features and other capabilities for this SMTP server. From a T.37 perspective, either ESMTP or SMTP with their respective EHLO and HELO identification commands may be used.

In addition to the SMTP commands highlighted in Example 6-1 and Example 6-2, there are additional SMTP commands. Table 6-2 lists the common SMTP and ESMTP commands and provides a brief description of each.

Table 6-2 Common SMTP/ESMTP Commands

Notice in Example 6-1 and Example 6-2 that the SMTP server always precedes its response with a numeric, three-digit code. These codes are referred to as SMTP response codes, and their definitions are defined by RFC 821. Table 6-3 details the SMTP response codes and their definitions.

DSN and MDN

Some of the most commonly used services that are added to the basic functionality of SMTP relate to giving the sender of an e-mail message a notification about the status of the message. Two such notification methods are delivery status notification (DSN) and message disposition notification (MDN) messages. Both of these delivery and processing confirmation methods are frequently integrated with T.37 store-and-forward fax.

DSN messages provide a mechanism for the mail server to convey delivery status of an e-mail message back to the sender. Depending on the mail server configuration, a DSN message can provide positive/negative delivery status information. Negative DSN informs the sender that the message was unable to be delivered or has been delayed, whereas positive DSN updates the originator that the message was successfully delivered.

DSN messages can be requested only during an ESMTP session if the ESMTP mail server explicitly offers support for these messages. Example 6-2 shows an ESMTP mail server responding to an EHLO with DSN support as one of its service extensions. Furthermore, all mail servers in the message path must support DSN for these notifications to work correctly. This concept is important because many mail messages must be routed through more than one e-mail server.

An ESMTP mail server configured for DSN support will only generate DSNs under the conditions requested by the mail client. These conditions are signaled to the mail server by the client in the "RCPT TO:" SMTP envelope command. After the e-mail address, a NOTIFY attribute is used to request the type of delivery notification for a particular recipient required by the sender. Example 6-3 illustrates DSN notification requests during an ESMTP session.

Example 6-3 ESMTP Session with DSN NOTIFY Parameters

220 smtp.cisco.com Simple Mail Transfer Service Ready EHLO cisco.com

250-smtp.cisco.com greets cisco.com

250-8BITMIME

250-SIZE

250-DSN

250 HELP

MAIL FROM:< [email protected]> RET=HDRS ENVID=124567 250 < [email protected]> sender ok

RCPT TO:< [email protected]> NOTIFY=SUCCESS,DELAY ORCPT=rfc822; [email protected] 250 < [email protected]> recipient ok

RCPT TO:<
[email protected]> NOTIFY=FAILURE ORCPT=rfc822; [email protected] 250 < [email protected]> recipient ok RCPT TO:< [email protected]> NOTIFY=NEVER R: 250 < [email protected]> recipient ok

The receivers of the mail message (specified by "RCPT TO:") in Example 6-3 each have the NOTIFY parameter after their respective e-mail addresses. This NOTIFY parameter specifies the delivery conditions under which the DSNs are requested by the sender for that particular recipient. The possible settings for the DSN NOTIFY parameter are specified in Table 6-4.

Taking into account the DSN NOTIFY parameters defined in Table 6-4, let's analyze the DSN notification for user1 in Example 6-3. The "RCPT TO:" command for user1 requests DSNs for SUCCESS and DELAY as specified in the NOTIFY extension. This means that the sender of this mail message will receive DSN messages only when the mail message is successfully delivered to user1's inbox or if it is delayed in its path to user1's inbox.

Following the NOTIFY parameter and its values, there is another parameter in the "RCPT TO:" SMTP command for user1. This parameter is the ORCPT (Original Recipient Address), and it specifies an address corresponding to the actual recipient of the delivered message.

As part of the ORCPT, an "addr-type" is specified that defines the type of mail address appearing in the ORCPT. In the case of Example 6-3, the "addr-type" for the ORCPT parameters is shown to conform to the format specified in RFC 822.

The last DSN related parameters in Example 6-3 are RET (Return) and ENVID (Envelope ID). These parameters are part of the sender's mail address that is specified in the "MAIL FROM:" SMTP envelope command.

In Example 6-3, RET=HDRS informs the mail server that the client only wants to have the e-mail headers "returned" in any DSN corresponding to a failed message delivery. The other option is RET=FULL, and this parameter requests that the full e-mail be returned for a failed message delivery DSN.

The ENVID parameter allows the client to attach an identifier that will be transmitted along with the message. This ENVID is also included in any DSNs issued for any of the recipients in the SMTP transaction. The purpose of the ENVID is to allow the sender of a message to correlate the original message with any DSNs that are received for that particular message. For a detailed explanation of DSN as a service extension to the SMTP protocol and a definition of all its associated parameters (NOTIFY, ORCPT, RET, ENVID), refer to RFC 3461.

DSN messages are used within T.37 to indicate successful delivery of a fax mail. For instance, if a fax is converted to an e-mail by the onramp gateway and it is configured for DSN, the delivery status of the mail message containing the TIFF attachment of the fax is sent to the user specified in the gateway configuration.

Example 6-4 shows an actual DSN message indicating successful delivery of a fax-mail sent by the mail server to the user specified in the configuration of the onramp gateway. For more information on configuring DSNs on a Cisco onramp gateway, see the section " Dial-Peer Configuration for Onramp Fax" in Chapter 11, "Configuring T.37 Store-and-Forward Fax." Example 6-4 T.37 DSN Success Message

Another notification to the sender that can prove useful is message disposition notification (MDN) messages. The difference between DSN and MDN is that DSN messages notify the sender of message delivery status by the mail server, whereas MDN messages notify the sender about how the already delivered message is processed by the recipient. For example, although a DSN will notify the sender that the mail message has been successfully deposited in a user's mailbox, it does not mean that the user has viewed the message. An MDN takes the process a step further and informs the sender when the recipient has actually opened the message.

An MDN is often referred to as a "read receipt" or a "return receipt" because it informs the sender that the mail message that was sent was opened by the recipient. A sender requests an MDN by including a "Disposition-Notification-To:" field in the header of the e-mail message. The address in the "Disposition-Notification-To:" field identifies where the disposition notification should be sent.

Example 6-5 illustrates the header for an e-mail that was delivered to the recipient [email protected]. This header requests that an MDN be sent to the sender [email protected]
. Note that the Disposition-Notification-To: field is found in the header information of the SMTP content portion of an SMTP message, unlike a DSN, which makes its notification request in the SMTP envelope.

Example 6-5 E-mail Message Header with an MDN Request

Because an MDN reveals to the sender whether and when a recipient has opened the mail message, it is sometimes considered an invasion of privacy. Because of these privacy considerations, MDN support is not available in several mail clients. If it is supported, it is typically implemented in such a fashion that the recipient is explicitly asked whether to acquiesce to the MDN request by the sender.

For instance, when the recipient of the e-mail in Example 6-5 opened that mail message, his mail reader requested for him to accept or deny the sender's request for a read receipt to be sent back. The recipient agreed to the request, and the MDN shown in Example 6-6 was sent.

Example 6-6 T.37 MDN Message

From: [email protected]

Subject: Read: Incoming Fax[DNIS=9913170][ANI=9194724118]

Date: March 31, 2007 3:58:20 PM EDT

To:
[email protected]

! Output omitted for brevity

This is a receipt for the mail you sent to "gsalguei" < [email protected]> at 5/22/2007 1:05 PM

This receipt verifies that the message has been displayed on the recipient's computer at 3/31/2007 2:58 PM

Example 6-6 T.37 MDN Message (Continued)

<MIME Attachment Information Follows:>

Final-Recipient: rfc822; [email protected] Original-Message-ID: < [email protected]_2811> Disposition: manual-action/MDN-sent-manually; displayed

Let's take a look at how the actual MDN message is actually formatted. Note that the MDN in Example 6-6 indicates in the Subject: that the recipient Read: the original message. Of course, there is no way of knowing whether the message was actually read or not, but the MDN does indicate in a human-readable explanation that the recipient did in fact open the message and even provides a timestamp for when it occurred.

The MDN also contains a MIME attachment with the information shown in Example 6-6. The Original-Message-ID: field is used to easily correlate the MDN receipt with the original e-mail. Note that the Original-Message-ID: field in the MDN in Example 6-6 matches up exactly with the Message-Id: field in the header of the original e-mail in Example 6-5.

The most important information in the MDN is found in the Disposition: field. The Disposition: field is a mandatory field for an MDN, and it is used to indicate what actions the recipient performed while processing the mail message.

Several attributes make up the information in the Disposition: field. The two most important parameters are the disposition-mode and the disposition-type. Table 6-5 defines the disposition-mode parameter settings.

Table 6-5 Disposition-Mode Parameter Settings

MDN-sent-automatically The MDN was sent because the mail client is configured to do it automatically.

MDN-sent-automatically The MDN was sent because the mail client is configured to do it automatically.

Note: MDN-sent-manually and MDN-sent-automatically are mutually exclusive. One or the other must be specified.

The MDN in Example 6-6 clearly specifies in the Notification: header that the "dispositionmode" is manual-action/MDN-sent-manually. This indicates to the sender that the recipient explicitly and manually acknowledged the request for an MDN to be sent. Table 6-6 defines all the disposition-type parameter settings.

Table 6-6 Disposition-Type Parameter Settings

The Notification: field for the MDN shown in Example 6-6 has a "disposition-type" with a value of displayed. Referencing Table 6-6, this means that the recipient's mail client displayed the e-mail in Example 6-5. You can get further information on the operation of MDN and all its related parameters in RFC 2298.