Editing Simple Mail Transfer Protocol (section)

==SMTP transport example==
A typical example of sending a message via SMTP to two mailboxes (''alice'' and ''theboss'') located in the same mail domain (''example.com'') is reproduced in the following session exchange. (In this example, the conversation parts are prefixed with ''S:'' and ''C:'', for ''server'' and ''client'', respectively; these labels are not part of the exchange.)

After the message sender (SMTP client) establishes a reliable communications channel to the message receiver (SMTP server), the session is opened with a greeting by the server, usually containing its [[fully qualified domain name]] (FQDN), in this case ''smtp.example.com''. The client initiates its dialog by responding with a <code>HELO</code> command identifying itself in the command's parameter with its FQDN (or an address literal if none is available).{{ref RFC|5321}}

 <span style="color: gray">S:</span> <span style="color: blue">220 smtp.example.com ESMTP Postfix</span>
 <span style="color: gray">C:</span> HELO relay.example.org
 <span style="color: gray">S:</span> <span style="color: blue">250 Hello relay.example.org, I am glad to meet you</span>
 <span style="color: gray">C:</span> MAIL FROM:<bob@example.org>
 <span style="color: gray">S:</span> <span style="color: blue">250 Ok</span>
 <span style="color: gray">C:</span> RCPT TO:<alice@example.com>
 <span style="color: gray">S:</span> <span style="color: blue">250 Ok</span>
 <span style="color: gray">C:</span> RCPT TO:<theboss@example.com>
 <span style="color: gray">S:</span> <span style="color: blue">250 Ok</span>
 <span style="color: gray">C:</span> DATA
 <span style="color: gray">S:</span> <span style="color: blue">354 End data with <CR><LF>.<CR><LF></span>
 <span style="color: gray">C:</span> {{codett|2=email|From: "Bob Example" <bob@example.org>}}
 <span style="color: gray">C:</span> {{codett|2=email|To: "Alice Example" <alice@example.com>}}
 <span style="color: gray">C:</span> {{codett|2=email|Cc: theboss@example.com}}
 <span style="color: gray">C:</span> {{codett|2=email|Date: Tue, 15 Jan 2008 16:02:43 -0500}}
 <span style="color: gray">C:</span> {{codett|2=email|Subject: Test message}}
 <span style="color: gray">C:</span>
 <span style="color: gray">C:</span> Hello Alice.
 <span style="color: gray">C:</span> This is a test message with 5 header fields and 4 lines in the message body.
 <span style="color: gray">C:</span> Your friend,
 <span style="color: gray">C:</span> Bob
 <span style="color: gray">C:</span> .
 <span style="color: gray">S:</span> <span style="color: blue">250 Ok: queued as 12345</span>
 <span style="color: gray">C:</span> QUIT
 <span style="color: gray">S:</span> <span style="color: blue">221 Bye</span>
 <span style="color: gray">{The server closes the connection}</span>

The client notifies the receiver of the originating email address of the message in a <code>MAIL FROM</code> command. This is also the return or [[bounce address]] in case the message cannot be delivered. In this example the email message is sent to two mailboxes on the same SMTP server: one for each recipient listed in the <code>To:</code> and <code>Cc:</code> header fields. The corresponding SMTP command is <code>RCPT TO</code>. Each successful reception and execution of a command is acknowledged by the server with a [[List of SMTP server return codes|result code and response message]] (e.g., <code>250 Ok</code>).

The transmission of the body of the mail message is initiated with a <code>DATA</code> command after which it is transmitted verbatim line by line and is terminated with an end-of-data sequence. This sequence consists of a new-line (<code><CR><LF></code>), a single [[full stop]] (<code>.</code>), followed by another new-line (<code><CR><LF></code>). Since a message body can contain a line with just a period as part of the text, the client sends ''two'' periods every time a line starts with a period; correspondingly, the server replaces every sequence of two periods at the beginning of a line with a single one. Such escaping method is called ''dot-stuffing''.

The server's positive reply to the end-of-data, as exemplified, implies that the server has taken the responsibility of delivering the message. A message can be doubled if there is a communication failure at this time, e.g. due to a power outage: Until the sender has received that <code>250 Ok</code> reply, it must assume the message was not delivered. On the other hand, after the receiver has decided to accept the message, it must assume the message has been delivered to it. Thus, during this time span, both agents have active copies of the message that they will try to deliver.<ref>{{IETF RFC|1047}}</ref> The probability that a communication failure occurs exactly at this step is directly proportional to the amount of filtering that the server performs on the message body, most often for anti-spam purposes. The limiting timeout is specified to be 10 minutes.<ref>{{cite IETF| rfc=5321|section=4.5.3.2.6|sectionname=DATA Termination: 10 Minutes.| title =Simple Mail Transfer Protocol | date = October 2008| access-date = June 7, 2010| last1 = Klensin| first1 = John C.}}</ref>

The <code>QUIT</code> command ends the session. If the email has other recipients located elsewhere, the client would <code>QUIT</code> and connect to an appropriate SMTP server for subsequent recipients after the current destination(s) had been queued. The information that the client sends in the <code>HELO</code> and <code>MAIL FROM</code> commands are added (not seen in example code) as additional header fields to the message by the receiving server. It adds a <code>Received</code> and <code>Return-Path</code> header field, respectively.

Some clients are implemented to close the connection after the message is accepted (<code>250 Ok: queued as 12345</code>), so the last two lines may actually be omitted. This causes an error on the server when trying to send the <code>221 Bye</code> reply.