Skip to content

Appunti - Email

Functionality

Mail client e mail server

The email system consists of many thousands of mail transfer agents (MTA) distributed across the world that interact among themselves. MTAs are informally called mail servers and in this document they will be referred to as such. Users interact with the email system through programs called mail user agents (MUA).

MUAs may take several forms:

  1. The MUA is a program, called mail client, running on the user device. Users interact with the mail client directly.

  2. The MUA is a web application that provides a graphical interface to a mail client accessed by the web server. Users interact with the mail client indirectly, through a browser running on the user device.

  3. Apps running on smartphones or tablets are equivalent to the browser of case 2. In the rest of this document we will refer to case 1.

Mailbox

A mailbox is a container of email messages (briefly, emails). It is located on a mail server and has a globally unique identifier called email address. An email address has the form mailboxName@emailDomainName. An email domain is the set of all mailboxes with identical emailDomainName. All mailboxes of the same email domain are located on the same mail server. A mail server may be responsible for more than one email domain. Of course, the mailboxName must be unique within each email domain.

An email has a sender email address and a destination email address. The email is prepared on a mail client and then it is given to a mail server. This mail server will interact with other mail servers for delivering the email, i.e., for depositing the email in the mailbox identified by the destination email address. The user that can access this mailbox may then retrieve the email with a mail client. The sending mailbox (the one identified by the sender email address) does not contain anything about emails sent from that email address, in particular, it does not contain emails sent from that email address.

A mail client is associated with a mailbox (it may be associated with more mailboxes but this fact does not alter the following discussion). It stores locally a copy of all emails sent from and received by the corresponding email address. When a mail client has retrieved an email from the mail server, it may or may not delete the email from the mailbox on the mail server. A mail client also provides functionalities for editing, searching, archiving and so on.

In principle, a mail client could send an email by contacting directly the mail server where the destination mailbox is located. In practice, a mail client always sends all emails by contacting “its own” mail server, i.e., the one associated with the sender email address.

Email format

The email format is specified by a dedicated protocol (RFC 822). An email is composed of two parts separated by an empty line.

The first part (header) of an email is a set of lines (email headers) of the form name:value. The allowed names and values, along with their meaning, is specified in the protocol. Email headers are inserted by the sending mail client, by mail servers, by the receiving mail client. Some email headers are used by mail clients while other email headers are used only for debugging, administrative or forensic reasons.

The second part (body) of an email is a sequence of bytes that represent the main part of the message, i.e., text, images and any other information that composes the message.

RFC 822 specifies that emails can only contain ASCII characters and that mail servers must clear to zero the most significant bit of every byte. This specification implies that emails cannot transport non-ASCII characters or non textual information (images, audio, video and so on), because common representations for such kinds of information use all bits and mail servers modify those bits. In order to transport such information in the body of an email, a dedicated protocol has been developed that is not part of this course. In brief, the information must first be converted into a format RFC 822 compliant and a description of the conversion applied must be inserted into the header. Such a conversion guarantees that mail servers will not modify the email content. The recipient of the email will analyze the header and apply the inverse conversion before presenting the body to the user. These operations are executed by mail clients. Mail servers need not be aware of these conversions.

RFC 822 does not have any notion of email attachment. In order to implement email attachments a dedicated protocol (MIME) has been developed that is not part of this course. In brief, attachments are converted into a sequence of bytes RFC 822 compliant and inserted into the email body; a dedicated header describes the presence of attachments in the body; the body is represented in a way that makes it possible to split the sequence in its composing parts, along with a description of the conversion applied to each part and the corresponding filename. The recipient of the email will analyze the header and apply the corresponding separations and conversions, as appropriate. These operations are executed by mail clients. Mail servers need not be aware of MIME.

Implementation

Mail servers: SMTP and POP

The DNS must contain a RR of type MX that translates the name of an email domain to the name of a mail server. This mail server stores all the mailboxes for that email domain. The DNS does not contain any information about mailbox names.

Let MS be a mail server and let MD be the corresponding email domain (MS may be the mail server for more than one mail domain, but this fact is irrelevant to this discussion). We say that a mailbox is local to MS if the email address of that mailbox belongs to MD.

The sending of an email occurs by connecting with a mail server and interacting with that mail server by means of the SMTP protocol. If the email is local to the mail server, then the mail server will deliver the email; otherwise, the mail server will relay the email to the mail server where the destination mailbox is stored (the behavior of a mail server for emails addressed at mailboxes that are not local is actually more complex, as clarified below). To this end, the mail server executes the following steps:

  1. Obtain the name of the destination email domain from the destination email address.
  2. Obtain the name of the destination mail server with a DNS request of type MX.
  3. Obtain the IP address of the destination mail server with a DNS of type A.
  4. Connect with the destination mail server and execute an SMTP interaction for sending the email.

Note that, at step 4, the sending mail server operates as a client.

A mailbox may receive emails from any sender in the world. A mail server will thus accept any SMTP request for depositing an email into a local mailbox. In other words, when a mail server receives an SMTP request for depositing an email into a local mailbox, the mail server will always execute that request. In particular, the mail server will not check the identity of the entity at the other end of the connection.

Reading access to the content of a mailbox occurs by connecting to the mail server where that mailbox is located and interacting with that mail server by means of the POP protocol (the IMAP protocol, not part of this course, can also be used for this purpose). A POP mail server allows access to a given mailbox only if the entity at the other end of the connection sends the password associated with that mailbox. The allowed operations are listing the content of the mailbox, retrieving (reading) emails, deleting emails.

Mail client: configuration and behavior

A mail client must be configured with:

  1. email address;
  2. username and password;
  3. name of the mail server that manages the mail domain of the mailbox.

The username is, in practice, the mailbox name, i.e., the part of the email address that precedes the ‘@’ character. The name of the mail server is often redundant as it can be obtained from the mail address (it is mandatory only in certain cases, not considered in this course).

Mail clients implemented as programs running on user devices must be configured by users, while those implemented as a web application are configured by the administrator of the web application itself.

Let MD be the mail domain of the mailbox of a mail client. A mail client sends all the emails to the mail server specified in configuration: those addressed at mailboxes in MD and those addressed at mailboxes in other mail domains. The mail server will deliver emails addressed at mailboxes in MD and relay the emails addressed at mailboxes in other mail domains. This structuring allows organizations to centralize the monitoring of all mail traffic of the organization and simplifies the implementation of mail clients. Note that with this common scenario, thus, a mail client always connect with a single mail server.

Mail server: common configuration

A common configuration for organizations that have a mail server M is as follows:

  1. Any SMTP outbound traffic not originated by M is blocked at the organization boundary.
  2. Any SMTP inbound traffic not directed to M is blocked at the organization boundary.
  3. M relays emails only for mail clients of its organization.

Rules 1 and 2 are implemented at the IP networking layer. Rule 3 is necessary for saving computation, storage and networking costs.

Implementation of rule 3 requires the ability for an SMTP mail server to determine whether the process at the other end of the connection is a mail client of its organization or not. This can be done as follows: The SMTP mail server uses an extended version of the SMTP protocol in which the other end of the connection may authenticate itself by means of a password (SMTP with authentication). This password is, in practice, the same password used for accessing to the mailbox with the POP protocol. The details of this extension are not part of this course.