Courrier lectronique

1
Tanenbaum, Computer Networks (extraits) Adaptation
par J.Bétréma
Electronic Mail
2
The User Agent

• Envelopes and messages. (a) Paper mail. (b)
  Electronic mail.

3
Message Transfer

• Transferring a message from elinore_at_abc.com to
  carolyn_at_xyz.com.

4
RFC 821
Network Working Group
J. Postel Request for Comments
DRAFT
ISI Replaces RFC 788, 780, 772
August 1982
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California 90291
SIMPLE MAIL TRANSFER PROTOCOL 1.
INTRODUCTION The objective of Simple Mail
Transfer Protocol (SMTP) is to transfer mail
reliably and efficiently. SMTP is independent
of the particular transmission subsystem and
requires only a reliable ordered data stream
channel. Appendices A, B, C, and D describe
the use of SMTP with various transport services.
A Glossary provides the definitions of terms as
used in this document.
5
RFC 821 (2)
4.2. SMTP REPLIES Replies to SMTP
commands are devised to ensure the
synchronization of requests and actions in
the process of mail transfer, and to
guarantee that the sender-SMTP always knows the
state of the receiver-SMTP. Every command
must generate exactly one reply. The
details of the command-reply sequence are made
explicit in Section 5.3 on Sequencing
and Section 5.4 State Diagrams. An SMTP
reply consists of a three digit number
(transmitted as three alphanumeric
characters) followed by some text. The number
is intended for use by automata to determine
what state to enter next the text is meant
for the human user. It is intended that
the three digits contain enough encoded
information that the sender-SMTP need not
examine the text and may either discard it or
pass it on to the user, as appropriate. In
particular, the text may be
receiver-dependent and context dependent, so
there are likely to be varying texts for
each reply code. A discussion of the
theory of reply codes is given in Appendix E.
Formally, a reply is defined to be the
sequence a three-digit code, ltSPgt, one
line of text, and ltCRLFgt, or a multiline reply
(as defined in Appendix E).
6
Message Formats RFC 822

• RFC 822 header fields related to message
  transport.

7
Message Formats RFC 822 (2)

• Some fields used in the RFC 822 message header.

8
RFC 822
3.2. HEADER FIELD DEFINITIONS These
rules show a field meta-syntax, without regard
for the particular type or internal
syntax. Their purpose is to permit
detection of fields also, they present to
higher-level parsers an image of each field
as fitting on one line. field
field-name "" field-body CRLF
field-name 1ltany CHAR, excluding CTLs,
SPACE, and ""gt field-body
field-body-contents CRLF
LWSP-char field-body field-body-contents
ltthe ASCII characters making
up the field-body, as defined
in the following sections, and consisting
of combinations of atom,
quoted-string, and specials
tokens, or else consisting of textsgt
9
MIME Multipurpose Internet Mail Extensions

• Problems with international languages
• Languages with accents (French, German).
• Languages in non-Latin alphabets (Hebrew,
  Russian).
• Languages without alphabets (Chinese, Japanese).
• Messages not containing text at all (audio or
  images).

10
MIME (2)

• RFC 822 headers added by MIME.

11
MIME (3)

• The MIME types and subtypes defined in RFC 2045.

12
MIME (4)

• A multipart message containing enriched and audio
  alternatives.

13
Final Delivery
(a) Sending and reading mail when the receiver
has a permanent Internet connection and the user
agent runs on the same machine as the message
transfer agent. (b) Reading e-mail when the
receiver has a dial-up connection to an ISP.
14
POP / IMAP

• A comparison of POP3 and IMAP.