Understanding How an Email System Works

E-mail has become an extremely popular communication tool. A solid understanding of email system concept helps system administrators to investigate various kinds of issues with the email system.

1. How does an email travel

The diagram below shows a typical sequence of events that takes place when Alice composes a message using her mail user agent (MUA). She types in or selects from an address book, the e-mail address of her correspondent. Then she sends the email.

  1. Alice’s MUA formats the message in Internet e-mail format and uses the Simple Mail Transfer Protocol (SMTP) to send the message to the local mail transfer agent (MTA), in this case, smtp.a.org, run by Alice’s Internet Service Provider (ISP).
  2. The MTA looks at the destination address provided in the SMTP protocol (not from the message header), in this case bob@b.org. An Internet e-mail address is a string of the form localpart@exampledomain.com, which is known as a Fully Qualified Domain Address (FQDA). The part before the @ sign is the local part of the address, often the username of the recipient, and the part after the @ sign is a domain name. The MTA looks up this domain name in the Domain Name System to find the mail exchange servers accepting messages for that domain.
  3. The DNS server for the b.org domain, ns.b.org, responds with an MX record listing the mail exchange servers for that domain, in this case mx.b.org, a server run by Bob’s ISP.
  4. smtp.a.org sends the message to mx.b.org using SMTP, which delivers it to the mailbox of the user bob.
  5. Bob presses the “get mail” button in his MUA, which picks up the message using the Post Office Protocol (POP3) or using Internet Message Access Protocol(IMAP).

2. Standard format of Email

A message consists of header fields and, optionally, a body.Each header field can be viewed as a single, logical line of ASCII characters, comprising a field-name and a field-body.The field-body portion can be split into multiple lines .The structure of header fields may be viewed as being composed of a field-name followed by a colon (“:“), followed by a field-body, and terminated by a carriage-return/line-feed.

The field-name must be composed of printable ASCII characters(i.e., characters that have values between 33. and 126.,decimal, except colon). The field-body may contain any ASCII character, except CR or LF. (While CR and/or LF may be present in the actual text, they are removed by the action of unfolding the field.)

Minimum required

Date: 26 Aug 76 1429 EDT       Date: 26 Aug 76 1429 EDT
From: Jones@Registry.Org    or   From: Jones@Registry.Org
Bcc:                             To: Smith@Registry.Org

Note that the “Bcc” field may be empty, while the “To” field is required to have at least one address.

Some common fields

1. Received

It is a trace field. It is useful for developers and support. A copy of this field is added by each transport service that relays the message. The information in the field can be quite useful for tracing transport problems.

Received: from agminet03.b.org (agminet03.b.org [192.168.10.1])
 by gw2.b.org(Switch-3.2.0/Switch-3.2.0) with ESMTP id m3A7ZtIj030617
 for [bob@b.org]; Thu, 10 Apr 2008 01:35:55 -0600

2. From

“From” is the originator field. This field contains the identity of the person(s) who want this message to be sent. The message-creation process should default this field to be a single, authenticated machine address, indicating the AGENT (person, system or process) entering the message. If this is not done, the “Sender” field MUST be present. If the “From” field IS defaulted this way, the “Sender” field is optional and is redundant with the “From” field. In all cases, addresses in the “From” field must be machine-usable (addr-specs) and may not contain named lists (groups).

From: Alice [alice@a.org]

3. To

“To” is a receiver field. This field contains the identity of the primary recipients of the message.

To: [bob@b.org]

4. Message-ID

“MESSAGE-ID ” is a reference field. This field contains a unique identifier (the local-part address unit) which refers to THIS version of THIS message. The uniqueness of the message identifier is guaranteed by the host which generates it. This identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one instantiation of a particular message; subsequent revisions to the message should each receive new message identifiers.

Message-ID: [BLU116-W138C07D0513573D21265F7A7EC0@phx.gbl]

5. Subject

This is intended to provide a summary, or indicate the nature, of the message.

Subject: Hello

Body

A Content-Type header field can be used to specify the type and subtype of data in the body of a message and to fully specify the native representation (encoding) of such data.

1. Text

The body is simply a sequence of lines containing ASCII characters. It is separated from the headers by a null line (i.e., a line with nothing preceding the CRLF).

Content-Type: text/plain

2. MIME – Multipurpose Internet Mail Extensions

MIME has been carefully designed as an extensible mechanism. It describes MIME-Version header field, Content-Type header field, Content-Transfer-Encoding header field. For example:

Content-Type: multipart/mixed;
boundary="------------040406000905020906030306"
--_77c1a01c-9699-4678-a620-eccfaf27c4c8_
Content-Type: text/plain
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="file.txt"

3. SMTP – Simple Mail Transfer Protocol

Simple Mail Transfer Protocol (SMTP), a protocol used for exchanging e-mail between points on the Internet. The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently.

he SMTP model

The SMTP design is based on the following model of communication: as the result of a user mail request, the sender-SMTP establishes a two-way transmission channel to a receiver-SMTP. The receiver-SMTP may be either the ultimate destination or an intermediate. SMTP commands are generated by the sender-SMTP and sent to the receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the sender-SMTP in response to the commands.

SMTP mail transaction example

There are three steps to SMTP mail transactions. The transaction is started with a MAIL command which gives the sender identification. A series of one or more RCPT commands follows giving the receiver information. Then a DATA command gives the mail data. And finally, the end of mail data indicator confirms the transaction.

C: #telnet smtp.a.org 25
C: Trying 192.168.**.**...
C: Connected to bigip-adc-mail-10g.a.org (192.168.**.**).
Escape character is '^]'.
C: 220 server ready. Unauthorized Access Prohibited.
S: EHLO test1.a.org
S: 250-bigip-adc-mail-10g.a.org Hello test1.a.org, pleased to meet you
S: 250-8BITMIME
S: 250-SIZE 15728640
S: 250-DSN
S: 250-ENHANCEDSTATUSCODES
S: 250-STARTTLS
S: 250-XAUTH
S: 250 HELP
C: MAIL FROM:
S: 250 2.1.0 Sender OK
C: RCPT TO:
S: 250 2.1.5 Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Subject: email title ..content
C: ....
C: . 

S: 250 2.6.0 Message accepted for delivery
C: quit
S: 221 2.0.0  bigip-adc-mail-10g.a.org Closing connection
S: Connection closed by foreign host.

4. POP3 – Post Office Protocol version 3

POP3 is used to read e-mail. With POP3, your mail is saved for you in a single mailbox on the server. When you read your mail, it is immediately downloaded to your computer and, except when previously arranged, no longer maintained on the server.

Initially, the server host starts the POP3 service by listening on TCP port 110. When a client wishes to make use of the service, it establishes a TCP connection with the server. When the connection is established, the POP3 server sends a greeting. The client and POP3 server then exchange commands and responses (respectively) until the connection is closed or aborted.

The POP3 protocol is used to allow a workstation to retrieve mail that the server is holding for it.

POP3 Session Example

S: [wait for connection on TCP port 110]
C: [open connection]
S:    +OK POP3 server ready [1896.697170952@dbc.mtview.ca.us]
C: USER Alice
S: +OK Alice is a real hoopy frood
C: PASS secret
S: +OK Alice's maildrop has 2 messages (320 octets)
C:    STAT
S:    +OK 2 320
C:    LIST
S:    +OK 2 messages (320 octets)
S:    1 120
S:    2 200
S:    .
C:    RETR 1
S:    +OK 120 octets
S:    [the POP3 server sends message 1]
S:    .
C:    DELE 1
S:    +OK message 1 deleted
C:    RETR 2
S:    +OK 200 octets
S:    [the POP3 server sends message 2]
S:    .
C:    DELE 2
S:    +OK message 2 deleted
C:    QUIT
S:    +OK dewey POP3 server signing off (maildrop empty)
C:  [close connection]
S:  [wait for next connection]

5. IMAP – Internet Message Access Protocol

IMAP (Internet Message Access Protocol) is a standard protocol for accessing e-mail from your local server. IMAP is a client/server protocol in which e-mail is received and held for you by your Internet server. You (or your e-mail client) can view just the heading and the sender of the letter and then decide whether to download the mail. You can also create and manipulate multiple folders or mailboxes on the server, delete messages, or search for certain parts or an entire note. IMAP requires continual access to the server during the time that you are working with your mail.

IMAP can be thought of as a remote file server. POP3 can be thought of as a “store-and-forward” service.

a brief comparison of POP3 and IMAP

POP3 protocol advantages

  • Simpler protocol; easier to implement.
  • More client software currently available.

IMAP protocol advantages

  • Can manipulate persistent message status flags.
  • Can store messages as well as fetch them.
  • Can access and manage multiple mailboxes.
  • Can support concurrent updates and access to shared mailboxes.
  • Suitable for accessing non-email data; e.g., NetNews, documents.
  • Can also use off-line paradigm, for minimum connect time and disk use.
  • Companion protocol defined for user configuration management (IMSP).
  • Constructs to permit online performance optimization, especially over low-speed links.

Sample IMAP4 connection

The following is a transcript of an IMAP4rev1 connection. A long line in this sample is broken for editorial clarity.

C: telnet imap.a.org 143
S: Trying 192.168.***.***...
S: Connected to imap.a.org (192.168.***.***).
Escape character is '^]'.
S:   * OK IMAP4rev1 Service Ready
C:   a001 login mrc secret
S:   a001 OK LOGIN completed
C:   a002 select inbox
S:   * 18 EXISTS
S:   * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S:   * 2 RECENT
S:   * OK [UNSEEN 17] Message 17 is the first unseen message
S:   * OK [UIDVALIDITY 3857529045] UIDs valid

S:   a002 OK [READ-WRITE] SELECT completed
C:   a003 fetch 12 full
S:   * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
      RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
      "IMAP4rev1 WG mtg summary and minutes"
      (("Terry Gray" NIL "gray" "cac.washington.edu"))
      (("Terry Gray" NIL "gray" "cac.washington.edu"))
      (("Terry Gray" NIL "gray" "cac.washington.edu"))
      ((NIL NIL "imap" "cac.washington.edu"))
      ((NIL NIL "minutes" "CNRI.Reston.VA.US")
      ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL
      "[B27397-0100000@cac.washington.edu]")
       BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))
S:    a003 OK FETCH completed
C:    a004 fetch 12 body[header]
S:    * 12 FETCH (BODY[HEADER] {350}
S:    Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S:    From: Terry Gray [gray@cac.washington.edu]
S:    Subject: IMAP4rev1 WG mtg summary and minutes
S:    To: imap@cac.washington.edu
S:    cc: minutes@CNRI.Reston.VA.US, John Klensin [KLENSIN@INFOODS.MIT.EDU]
S:    Message-Id: [B27397-0100000@cac.washington.edu]
S:    MIME-Version: 1.0
S:    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S:    )
S:    a004 OK FETCH completed
C:    a005 store 12 +flags \deleted
S:    * 12 FETCH (FLAGS (\Seen \Deleted))
S:    a005 OK +FLAGS completed
C:    a006 logout
S:    * BYE IMAP4rev1 server terminating connection
S:    a006 OK LOGOUT completed
Related Post