SMTP
SMTP: SMTP is the most common protocol for sending emails.
SMTP has a client side that executes on the sender’s mail server, and a server side that executes on the recipient’s mail server. Both the client and server side of SMTP run on every mail server.
SMTP is governed by simple commands and parameter values sent from the client, followed by a response code from the server.
How SMTP transfers a message:
1. The client side of SMTP has TCP establish a connection to port 25 at the server side of SMTP.
(If the server is down, the client tries again later.)
2. The server and client perform some initial SMTP handshaking, introducing themselves to each other.
3. The client sends the message into the TCP connection, and the server receives the message.
(The client repeats this process if it has other message to send to the server, else instructs TCP to close the connection.) – SMTP uses persistent connection.
e.g. packets in transmitting an email (SMTP part)
The initial SMTP communication allows the recipient server to transmit its supported feature set to the sender, thus sender can adjust SMTP commands to transmit the message effectively.
e.g. a) e.g. packets on sender client – sender’s user client -> sender side’s local SMTP server
1~3: TCP handshake;
4: email server sends a service banner, indicating it is ready to receive a command. //it identifies itself as a Postfix server running on Ubuntu Linux OS, capable of receiving ESMTP commands;
* ESMTP: Extended SMTP, an extension to SMTP specification that allows for additional commands to be used during mail transmission.
5: email client sends EHLO command (: “Hello”, used to identify the sending host when ESMTP is supported.), identifying itself with its IP address (a DNS name can be used as well). // If ESMTP is not available, client will use HELO command instead;
7: email server sends a list that reflects commands supported by the SMTP server, so that client can know what commands is allowed to use. This negotiation occurs at the beginning of every SMTP transaction before a message is sent.
8: client issues MAIL command with parameter FROM:<sanders@skynet.local> SIZE=556 (//sender’s email address, size of the message);
9: server responds with code 250 (: requested mail action okay, completed) and parameter 2.1.0 OK;
10: client issues RCPT command with parameter TO:<sanders@cyberdyne.local>;
11: server responds with code 250 2.1.5 OK;
12: client issues DATA command to initiate message transmitting;
13: server responds with code 354 with a message, which indicates: the server has created a buffer for the message, tells the client to begin transmitting and to send a dot (<CR><LF>.<CR><LF>) to mark the end of the transmission;
14~15: message text with additional information (e.g. date, content type, encoding, user agent);
17: response, indicates successful transmission;
18: client issues QUIT command;
19: server response 221 (: <domain> service closing transmission channel) and parameter 2.0.0 Bye;
20~23: tear down TCP connection;
* available SMTP commands and parameters refer to: www.iana.org/assignments/mail-parameters/mail -parameters.xhtml
* available SMTP response codes refers to: www.iana.org/assignments/smtp-enhanced-status-codes/ smtp-enhanced-status-codes.xml
An email message consists of a header and a message body (in ASCII), separated by a blank line (by CRLF).
Header: a series of header lines, containing peripheral information. Each header line contains readable text, consisting of a keyword followed by a colon followed by a value.
Every header must have a From: header line and a To: header line; Some header lines are optional.
“From:” or “to:” header lines are different from the SMTP commands “FROM” “TO”. the header lines are part of the mail message, the commands are part of the SMTP handshaking protocol.
Upon receiving a message, the SMTP receiving server appends a Received: header line to the message, specifying the name of the SMTP server that sent the message (from), the name of the SMTP server that received the message (by), and the time at which the receiving server received the message.
Sometimes a single message may has multiple Received: header line and a more complex Return-Path: header line, because a message may be forwarded to more than one SMTP server in the path between sender and recipient.
e.g.
Received: from crepes.fr by hamburger.edu; 12 Oct 98
15:27:39 GMT
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
(base 64 encoded data …… base 64 encoded data)
e.g. b) e.g. packets on local email server –sender side’s local SMTP server -> receiver side’s remote SMTP server
// this traffic exists if the receiver’s mailbox is not in the same domain as the sender’s mailbox.
* mail exchange (MX): a special DNS record type, used by an email server to locate another server in real-world scenario. // Such traffic is omitted here because IP address of email server was preconfigured on local server in the lab.
… (same packets in (a) from another source)
22~24: TCP handshake;
27: remote server sends a service banner //identifies itself as mail02, …etc;
29: local server sends EHLO, identifying itself as mail01;
31: remote server shares a list of support commands;
32: local server transfers the text message with additional data from the previous transaction (prepended above the To: line);
…
sending attachment via SMTP
The multipurpose Internet Mail Extensions (MIME) defines extra headers that allow a user agent to send content other than ASCII text.
The Content—Transfer-Encoding: header alerts the receiving user agent that the message body has been ASCII-encoded and indicates the type of encoding used. (When a user agent receives a message, it uses this header to convert the message body back to its original non-ASCII form.)
The Content-Type: header allows the receiving user agent to take an appropriate action on the message. (After converting the message body back to original form, uses this header to determine what action to take on the message body.)
e.g. c) packets in sending mail with attachment
// the client sends plaintext message together with binary data of image file
sender client identifies Content-Type as multipart/mixed (: multiple types of data are being transmitted, each with their own MIME type and encoding), with boundary ------------050407080301000500070000 (each type of data will be separated by the specified boundary value);
e.g. mail text is identified by content-type: text/plain, content-transfer-encoding: 7bit; image file is identified by content-type: image/jpeg, content-transfer-encoding: base64;
The differences between SMTP and HTTP
1) SMTP is a push protocol, HTTP is a pull protocol.
In SMTP, the TCP connection is initiated by the machine that wants to send the file;
In HTTP, the TCP connection is initiated by the machine that wants to receive the file.
2) SMTP requires each message to be in 7-bit ASCII format.
In SMTP, if the message contains characters that are not 7-bit ASCII or contains binary data, the message has to be encoded into 7-bit ASCII.
HTTP data does not impose this restriction.
3) How a document consisting of text, images or other media types is handled.
HTTP encapsulates each object in its HTTP response message.
SMTP places all of the message’s object into one message.
IMAP
An IMAP server associates each message with a folder. The IMAP protocol provides commands to allow users to create folders, move messages from one folder to another, search remote folders for messages matching specific criteria.
IMAP provides commands to allow users to obtain components of messages.
e.g. packets in transmitting an email (IMAP part)
The most prevalent protocols for retrieving email from a mailbox on a server are POP3 and IMAP.
e.g. d) packets in receiver retrieving email from SMTP server –receiver side’s SMTP server -> receiver’s user client
decode IMAP packages with TLS:
… (same packets in (b) from another source)
21: receiver client sends STARTTLS command, informing that the client would like to retrieve message securely using TLS encryption;
24~27: receiver client and server negotiates a secure channel;
28+: messages are transmitted securely via TLS protocol;