msgid "" msgstr "" "Project-Id-Version: French (cnp3-ebook)\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2026-04-19 02:14+0200\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: French \n" "Language: fr\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=n > 1;\n" "X-Generator: Weblate 5.14.3\n" #: ../../protocols/email.rst:13 msgid "" "Before looking at the details of Internet email, let us consider a simple " "scenario illustrated in the figure below, where Alice sends an email to Bob. " "Alice prepares her email by using an `email clients`_ and sends it to her " "email server. Alice's `email server `_ extracts Bob's address from the email and " "delivers the message to Bob's server. Bob retrieves Alice's message on his " "server and reads it by using his favorite email client or through his " "webmail interface." msgstr "" #: ../../protocols/email.rst:47 msgid "" "The email system that we consider in this book is composed of four " "components :" msgstr "" #: ../../protocols/email.rst:49 msgid "a message format, that defines how valid email messages are encoded" msgstr "" #: ../../protocols/email.rst:50 msgid "protocols, that allow hosts and servers to exchange email messages" msgstr "" #: ../../protocols/email.rst:51 msgid "" "client software, that allows users to easily create and read email messages" msgstr "" #: ../../protocols/email.rst:52 msgid "software, that allows servers to efficiently exchange email messages" msgstr "" #: ../../protocols/email.rst:54 msgid "" "We will first discuss the format of email messages followed by the protocols " "that are used on today's Internet to exchange and retrieve emails. Other " "email systems have been developed in the past [Bush1993]_ [Genilloud1990]_ " "[GC2000]_, but today most email solutions have migrated to the Internet " "email. Information about the software that is used to compose and deliver " "emails may be found on wikipedia_ among others, for both `email clients`_ " "and `email servers `" "_. More detailed information about the full Internet Mail Architecture may " "be found in :rfc:`5598`." msgstr "" #: ../../protocols/email.rst:58 msgid "Email messages, like postal mail, are composed of two parts :" msgstr "" #: ../../protocols/email.rst:60 msgid "" "a `header` that plays the same role as the letterhead in regular mail. It " "contains metadata about the message." msgstr "" #: ../../protocols/email.rst:61 msgid "the `body` that contains the message itself." msgstr "" #: ../../protocols/email.rst:63 msgid "" "Email messages are entirely composed of lines of ASCII characters. Each line " "can contain up to 998 characters and is terminated by the `CR` and `LF` " "control characters :rfc:`5322`. The lines that compose the `header` appear " "before the message `body`. An empty line, containing only the `CR` and `LF` " "characters, marks the end of the `header`. This is illustrated in the figure " "below." msgstr "" #: ../../protocols/email.rst:98 msgid "" "The email header contains several lines that all begin with a keyword " "followed by a colon and additional information. The format of email messages " "and the different types of header lines are defined in :rfc:`5322`. Two of " "these header lines are mandatory and must appear in all email messages :" msgstr "" #: ../../protocols/email.rst:100 msgid "" "The sender address. This header line starts with `From:`. This contains the " "(optional) name of the sender followed by its email address between `<` and " "`>`. Email addresses are always composed of a username followed by the `@` " "sign and a domain name." msgstr "" #: ../../protocols/email.rst:101 msgid "" "The date. This header line starts with `Date:`. :rfc:`5322` precisely " "defines the format used to encode a date." msgstr "" #: ../../protocols/email.rst:103 msgid "" "Other header lines appear in most email messages. The `Subject:` header line " "allows the sender to indicate the topic discussed in the email. Three types " "of header lines can be used to specify the recipients of a message :" msgstr "" #: ../../protocols/email.rst:105 msgid "" "the `To:` header line contains the email addresses of the primary recipients " "of the message [#fto]_. Several addresses can be separated by using commas." msgstr "" #: ../../protocols/email.rst:106 msgid "" "the `cc:` header line is used by the sender to provide a list of email " "addresses that must receive a carbon copy of the message. Several addresses " "can be listed in this header line, separated by commas. All recipients of " "the email message receive the `To:` and `cc:` header lines." msgstr "" #: ../../protocols/email.rst:107 msgid "" "the `bcc:` header line is used by the sender to provide a list of comma " "separated email addresses that must receive a blind carbon copy of the " "message. The `bcc:` header line is not delivered to the recipients of the " "email message." msgstr "" #: ../../protocols/email.rst:109 msgid "" "A simple email message containing the `From:`, `To:`, `Subject:` and `Date:` " "header lines and two lines of body is shown below." msgstr "" #: ../../protocols/email.rst:122 msgid "" "Note the empty line after the `Date:` header line; this empty line contains " "only the `CR` and `LF` characters, and marks the boundary between the header " "and the body of the message." msgstr "" #: ../../protocols/email.rst:124 msgid "" "Several other optional header lines are defined in :rfc:`5322` and elsewhere " "[#femailheaders]_. Furthermore, many email clients and servers define their " "own header lines starting from `X-`. Several of the optional header lines " "defined in :rfc:`5322` are worth being discussed here :" msgstr "" #: ../../protocols/email.rst:126 msgid "" "the `Message-Id:` header line is used to associate a \"unique\" identifier " "to each email. Email identifiers are usually structured like `string@domain` " "where `string` is a unique character string or sequence number chosen by the " "sender of the email and `domain` the domain name of the sender. Since domain " "names are unique, a host can generate globally unique message identifiers " "concatenating a locally unique identifier with its domain name." msgstr "" #: ../../protocols/email.rst:127 msgid "" "the `In-reply-to:` header line is used when a message was created in reply " "to a previous message. In this case, the end of the `In-reply-to:` line " "contains the identifier of the original message." msgstr "" #: ../../protocols/email.rst:128 msgid "" "the `Received:` header line is used when an email message is processed by " "several servers before reaching its destination. Each intermediate email " "server adds a `Received:` header line. These header lines are useful to " "debug problems in delivering email messages." msgstr "" #: ../../protocols/email.rst:130 msgid "" "The figure below shows the header lines of one email message. The message " "originated at a host named `wira.firstpr.com.au` and was received by " "`smtp3.sgsi.ucl.ac.be`. The `Received:` lines have been wrapped for " "readability." msgstr "" #: ../../protocols/email.rst:166 msgid "" "Initially, email was used to exchange small messages of ASCII text between " "computer scientists. However, with the growth of the Internet, supporting " "only ASCII text became a severe limitation for two reasons. First of all, " "non-English speakers wanted to write emails in their native language that " "often required more characters than those of the ASCII character table. " "Second, many users wanted to send other content than just ASCII text by " "email such as binary files, images or sound." msgstr "" #: ../../protocols/email.rst:170 msgid "" "To solve this problem, the IETF_ developed the Multipurpose Internet Mail " "Extensions (:term:`MIME`). These extensions were carefully designed to allow " "Internet email to carry non-ASCII characters and binary files without " "breaking the email servers that were deployed at that time. This requirement " "for backward compatibility forced the MIME designers to develop extensions " "to the existing email message format :rfc:`822` instead of defining a " "completely new format that would have been better suited to support the new " "types of emails." msgstr "" #: ../../protocols/email.rst:172 msgid ":rfc:`2045` defines three new types of header lines to support MIME :" msgstr "" #: ../../protocols/email.rst:174 msgid "" "The `MIME-Version:` header line indicates the version of the MIME " "specification that was used to encode the email message. The current version " "of MIME is 1.0. Other versions of MIME may be defined in the future. Thanks " "to this header line, the software that processes email messages will be able " "to adapt to the MIME version used to encode the message. Messages that do " "not contain this header are supposed to be formatted according to the " "original :rfc:`822` specification." msgstr "" #: ../../protocols/email.rst:175 msgid "" "The `Content-Type:` header line indicates the type of data that is carried " "inside the message (see below)." msgstr "" #: ../../protocols/email.rst:176 msgid "" "The `Content-Transfer-Encoding:` header line is used to specify how the " "message has been encoded. When MIME was designed, some email servers were " "only able to process messages containing characters encoded using the 7 bits " "ASCII character set. MIME allows the utilization of other character " "encodings." msgstr "" #: ../../protocols/email.rst:178 msgid "" "Inside the email header, the `Content-Type:` header line indicates how the " "MIME email message is structured. :rfc:`2046` defines the utilization of " "this header line. The two most common structures for MIME messages are :" msgstr "" #: ../../protocols/email.rst:180 msgid "" "`Content-Type: multipart/mixed`. This header line indicates that the MIME " "message contains several independent parts. For example, such a message may " "contain a part in plain text and a binary file." msgstr "" #: ../../protocols/email.rst:181 msgid "" "`Content-Type: multipart/alternative`. This header line indicates that the " "MIME message contains several representations of the same information. For " "example, a `multipart/alternative` message may contain both a plain text and " "an HTML version of the same text." msgstr "" #: ../../protocols/email.rst:183 msgid "" "To support these two types of MIME messages, the recipient of a message must " "be able to extract the different parts from the message. In :rfc:`822`, an " "empty line was used to separate the header lines from the body. Using an " "empty line to separate the different parts of an email body would be " "difficult as the body of email messages often contains one or more empty " "lines. Another possible option would be to define a special line, e.g. " "`*-LAST_LINE-*` to mark the boundary between two parts of a MIME message. " "Unfortunately, this is not possible as some emails may contain this string " "in their body " "(e.g. emails sent to students to explain the format of MIME messages). To " "solve this problem, the `Content-Type:` header line contains a second " "parameter that specifies the string that has been used by the sender of the " "MIME message to delineate the different parts. In practice, this string is " "often chosen randomly by the mail client." msgstr "" #: ../../protocols/email.rst:186 msgid "" "The email message below, copied from :rfc:`2046` shows a MIME message " "containing two parts that are both in plain text and encoded using the ASCII " "character set. The string `simple boundary` is defined in the `Content-Type:`" " header as the marker for the boundary between two successive parts. Another " "example of MIME messages may be found in :rfc:`2046`." msgstr "" #: ../../protocols/email.rst:210 msgid "" "The `Content-Type:` header can also be used inside a MIME part. In this " "case, it indicates the type of data placed in this part. Each data type is " "specified as a type followed by a subtype. A detailed description may be " "found in :rfc:`2046`. Some of the most popular `Content-Type:` header lines " "are :" msgstr "" #: ../../protocols/email.rst:212 msgid "" "`text`. The message part contains information in textual format. There are " "several subtypes : `text/plain` for regular ASCII text, `text/html` defined " "in :rfc:`2854` for documents in :term:`HTML` format or the `text/enriched` " "format defined in :rfc:`1896`. The `Content-Type:` header line may contain a " "second parameter that specifies the character set used to encode the text. " "`charset=us-ascii` is the standard ASCII character table. Other frequent " "character sets include `charset=UTF8` or `charset=iso-8859-1`. The `list of " "standard character sets `_ " "is maintained by :term:`IANA`." msgstr "" #: ../../protocols/email.rst:213 msgid "" "`image`. The message part contains a binary representation of an image. The " "subtype indicates the format of the image such as `gif `_, `jpg `_ or `png `_." msgstr "" #: ../../protocols/email.rst:214 msgid "" "`audio`. The message part contains an audio clip. The subtype indicates the " "format of the audio clip like `wav `_ or `" "mp3 `_." msgstr "" #: ../../protocols/email.rst:215 msgid "" "`video`. The message part contains a video clip. The subtype indicates the " "format of the video clip like `avi `_ or `mp4 `_." msgstr "" #: ../../protocols/email.rst:216 msgid "" "`application`. The message part contains binary information that was " "produced by the particular application listed as the subtype. Email clients " "use the subtype to launch the application that is able to decode the " "received binary information." msgstr "" #: ../../protocols/email.rst:218 msgid "From ASCII to Unicode" msgstr "" #: ../../protocols/email.rst:220 msgid "" "The first computers used different techniques to represent characters in " "memory and on disk. During the 1960s, computers began to exchange " "information via tape or telephone lines. Unfortunately, each vendor had its " "own proprietary character set and exchanging data between computers from " "different vendors was often difficult. The 7 bits ASCII character table " ":rfc:`20` was adopted by several vendors and by many Internet protocols. " "However, ASCII became a problem with the internationalization of the " "Internet and the desire of more and more users to use character sets that " "support their own written language. A first attempt at solving this problem " "was the definition of the ISO-8859_ character sets by :term:`ISO`. This " "family of standards specified various character sets that allowed the " "representation of many European written languages by using 8 bits " "characters. Unfortunately, an 8-bits character set is not sufficient to " "support some widely used languages, such as those used in Asian countries. " "Fortunately, at the end of the 1980s, several computer scientists proposed " "to develop a standard that supports all written languages used on Earth " "today. The Unicode standard [Unicode]_ has now been adopted by most computer " "and software vendors. For example, Java always uses Unicode to manipulate " "characters, Python can handle both ASCII and Unicode characters. Internet " "applications are slowly moving towards complete support for the Unicode " "character sets, but moving from ASCII to Unicode is an important change that " "can have a huge impact on current deployed implementations. See, for " "example, the work to completely internationalize email :rfc:`4952` and " "domain names :rfc:`5890`." msgstr "" #: ../../protocols/email.rst:222 msgid "" "The last MIME header line is `Content-Transfer-Encoding:`. This header line " "is used after the `Content-Type:` header line, within a message part, and " "specifies how the message part has been encoded. The default encoding is to " "use 7 bits ASCII. The most frequent encodings are `quoted-printable` and " "`Base64`. Both support encoding a sequence of bytes into a set of ASCII " "lines that can be safely transmitted by email servers. `quoted-printable` is " "defined in :rfc:`2045`. We briefly describe `base64` which is defined in " ":rfc:`2045` and :rfc:`4648`." msgstr "" #: ../../protocols/email.rst:227 msgid "" "`Base64` divides the sequence of bytes to be encoded into groups of three " "bytes (with the last group possibly being partially filled). Each group of " "three bytes is then divided into four six-bit fields and each six bit field " "is encoded as a character from the table below." msgstr "" #: ../../protocols/email.rst:230 #: ../../protocols/email.rst:230 #: ../../protocols/email.rst:230 #: ../../protocols/email.rst:230 msgid "Value" msgstr "" #: ../../protocols/email.rst:230 #: ../../protocols/email.rst:230 #: ../../protocols/email.rst:230 #: ../../protocols/email.rst:230 #: ../../protocols/email.rst:278 #: ../../protocols/email.rst:297 #: ../../protocols/email.rst:311 msgid "Encoding" msgstr "" #: ../../protocols/email.rst:232 #: ../../protocols/email.rst:234 msgid "0" msgstr "" #: ../../protocols/email.rst:232 msgid "A" msgstr "" #: ../../protocols/email.rst:232 msgid "17" msgstr "" #: ../../protocols/email.rst:232 msgid "R" msgstr "" #: ../../protocols/email.rst:232 msgid "34" msgstr "" #: ../../protocols/email.rst:232 msgid "i" msgstr "" #: ../../protocols/email.rst:232 msgid "51" msgstr "" #: ../../protocols/email.rst:232 msgid "z" msgstr "" #: ../../protocols/email.rst:234 #: ../../protocols/email.rst:236 msgid "1" msgstr "" #: ../../protocols/email.rst:234 msgid "B" msgstr "" #: ../../protocols/email.rst:234 msgid "18" msgstr "" #: ../../protocols/email.rst:234 msgid "S" msgstr "" #: ../../protocols/email.rst:234 msgid "35" msgstr "" #: ../../protocols/email.rst:234 msgid "j" msgstr "" #: ../../protocols/email.rst:234 msgid "52" msgstr "" #: ../../protocols/email.rst:236 #: ../../protocols/email.rst:238 msgid "2" msgstr "" #: ../../protocols/email.rst:236 msgid "C" msgstr "" #: ../../protocols/email.rst:236 msgid "19" msgstr "" #: ../../protocols/email.rst:236 msgid "T" msgstr "" #: ../../protocols/email.rst:236 msgid "36" msgstr "" #: ../../protocols/email.rst:236 msgid "k" msgstr "" #: ../../protocols/email.rst:236 msgid "53" msgstr "" #: ../../protocols/email.rst:238 #: ../../protocols/email.rst:240 msgid "3" msgstr "" #: ../../protocols/email.rst:238 msgid "D" msgstr "" #: ../../protocols/email.rst:238 msgid "20" msgstr "" #: ../../protocols/email.rst:238 msgid "U" msgstr "" #: ../../protocols/email.rst:238 msgid "37" msgstr "" #: ../../protocols/email.rst:238 msgid "l" msgstr "" #: ../../protocols/email.rst:238 msgid "54" msgstr "" #: ../../protocols/email.rst:240 #: ../../protocols/email.rst:242 msgid "4" msgstr "" #: ../../protocols/email.rst:240 msgid "E" msgstr "" #: ../../protocols/email.rst:240 msgid "21" msgstr "" #: ../../protocols/email.rst:240 msgid "V" msgstr "" #: ../../protocols/email.rst:240 msgid "38" msgstr "" #: ../../protocols/email.rst:240 msgid "m" msgstr "" #: ../../protocols/email.rst:240 msgid "55" msgstr "" #: ../../protocols/email.rst:242 #: ../../protocols/email.rst:244 msgid "5" msgstr "" #: ../../protocols/email.rst:242 msgid "F" msgstr "" #: ../../protocols/email.rst:242 msgid "22" msgstr "" #: ../../protocols/email.rst:242 msgid "W" msgstr "" #: ../../protocols/email.rst:242 msgid "39" msgstr "" #: ../../protocols/email.rst:242 msgid "n" msgstr "" #: ../../protocols/email.rst:242 msgid "56" msgstr "" #: ../../protocols/email.rst:244 #: ../../protocols/email.rst:246 msgid "6" msgstr "" #: ../../protocols/email.rst:244 msgid "G" msgstr "" #: ../../protocols/email.rst:244 msgid "23" msgstr "" #: ../../protocols/email.rst:244 msgid "X" msgstr "" #: ../../protocols/email.rst:244 msgid "40" msgstr "" #: ../../protocols/email.rst:244 msgid "o" msgstr "" #: ../../protocols/email.rst:244 msgid "57" msgstr "" #: ../../protocols/email.rst:246 #: ../../protocols/email.rst:248 msgid "7" msgstr "" #: ../../protocols/email.rst:246 msgid "H" msgstr "" #: ../../protocols/email.rst:246 msgid "24" msgstr "" #: ../../protocols/email.rst:246 msgid "Y" msgstr "" #: ../../protocols/email.rst:246 msgid "41" msgstr "" #: ../../protocols/email.rst:246 msgid "p" msgstr "" #: ../../protocols/email.rst:246 msgid "58" msgstr "" #: ../../protocols/email.rst:248 #: ../../protocols/email.rst:250 msgid "8" msgstr "" #: ../../protocols/email.rst:248 msgid "I" msgstr "" #: ../../protocols/email.rst:248 msgid "25" msgstr "" #: ../../protocols/email.rst:248 msgid "Z" msgstr "" #: ../../protocols/email.rst:248 msgid "42" msgstr "" #: ../../protocols/email.rst:248 msgid "q" msgstr "" #: ../../protocols/email.rst:248 msgid "59" msgstr "" #: ../../protocols/email.rst:250 #: ../../protocols/email.rst:252 msgid "9" msgstr "" #: ../../protocols/email.rst:250 msgid "J" msgstr "" #: ../../protocols/email.rst:250 msgid "26" msgstr "" #: ../../protocols/email.rst:250 msgid "a" msgstr "" #: ../../protocols/email.rst:250 msgid "43" msgstr "" #: ../../protocols/email.rst:250 msgid "r" msgstr "" #: ../../protocols/email.rst:250 msgid "60" msgstr "" #: ../../protocols/email.rst:252 msgid "10" msgstr "" #: ../../protocols/email.rst:252 msgid "K" msgstr "" #: ../../protocols/email.rst:252 msgid "27" msgstr "" #: ../../protocols/email.rst:252 msgid "b" msgstr "" #: ../../protocols/email.rst:252 msgid "44" msgstr "" #: ../../protocols/email.rst:252 msgid "s" msgstr "" #: ../../protocols/email.rst:252 msgid "61" msgstr "" #: ../../protocols/email.rst:254 msgid "11" msgstr "" #: ../../protocols/email.rst:254 msgid "L" msgstr "" #: ../../protocols/email.rst:254 msgid "28" msgstr "" #: ../../protocols/email.rst:254 msgid "c" msgstr "" #: ../../protocols/email.rst:254 msgid "45" msgstr "" #: ../../protocols/email.rst:254 msgid "t" msgstr "" #: ../../protocols/email.rst:254 msgid "62" msgstr "" #: ../../protocols/email.rst:254 msgid "\\+" msgstr "" #: ../../protocols/email.rst:256 msgid "12" msgstr "" #: ../../protocols/email.rst:256 msgid "M" msgstr "" #: ../../protocols/email.rst:256 msgid "29" msgstr "" #: ../../protocols/email.rst:256 msgid "d" msgstr "" #: ../../protocols/email.rst:256 msgid "46" msgstr "" #: ../../protocols/email.rst:256 msgid "u" msgstr "" #: ../../protocols/email.rst:256 msgid "63" msgstr "" #: ../../protocols/email.rst:256 msgid "/" msgstr "" #: ../../protocols/email.rst:258 msgid "13" msgstr "" #: ../../protocols/email.rst:258 msgid "N" msgstr "" #: ../../protocols/email.rst:258 msgid "30" msgstr "" #: ../../protocols/email.rst:258 msgid "e" msgstr "" #: ../../protocols/email.rst:258 msgid "47" msgstr "" #: ../../protocols/email.rst:258 msgid "v" msgstr "" #: ../../protocols/email.rst:260 msgid "14" msgstr "" #: ../../protocols/email.rst:260 msgid "O" msgstr "" #: ../../protocols/email.rst:260 msgid "31" msgstr "" #: ../../protocols/email.rst:260 msgid "f" msgstr "" #: ../../protocols/email.rst:260 msgid "48" msgstr "" #: ../../protocols/email.rst:260 msgid "w" msgstr "" #: ../../protocols/email.rst:262 msgid "15" msgstr "" #: ../../protocols/email.rst:262 msgid "P" msgstr "" #: ../../protocols/email.rst:262 msgid "32" msgstr "" #: ../../protocols/email.rst:262 msgid "g" msgstr "" #: ../../protocols/email.rst:262 msgid "49" msgstr "" #: ../../protocols/email.rst:262 msgid "x" msgstr "" #: ../../protocols/email.rst:264 msgid "16" msgstr "" #: ../../protocols/email.rst:264 msgid "Q" msgstr "" #: ../../protocols/email.rst:264 msgid "33" msgstr "" #: ../../protocols/email.rst:264 msgid "h" msgstr "" #: ../../protocols/email.rst:264 msgid "50" msgstr "" #: ../../protocols/email.rst:264 msgid "y" msgstr "" #: ../../protocols/email.rst:267 msgid "The example below, from :rfc:`4648`, illustrates the `Base64` encoding." msgstr "" #: ../../protocols/email.rst:270 #: ../../protocols/email.rst:289 #: ../../protocols/email.rst:303 msgid "Input data" msgstr "" #: ../../protocols/email.rst:270 msgid "`0x14fb9c03d97e`" msgstr "" #: ../../protocols/email.rst:272 #: ../../protocols/email.rst:291 #: ../../protocols/email.rst:305 msgid "8-bit" msgstr "" #: ../../protocols/email.rst:272 msgid "00010100 11111011 10011100 00000011 11011001 01111110" msgstr "" #: ../../protocols/email.rst:274 #: ../../protocols/email.rst:293 #: ../../protocols/email.rst:307 msgid "6-bit" msgstr "" #: ../../protocols/email.rst:274 msgid "000101 001111 101110 011100 000000 111101 100101 111110" msgstr "" #: ../../protocols/email.rst:276 #: ../../protocols/email.rst:295 #: ../../protocols/email.rst:309 msgid "Decimal" msgstr "" #: ../../protocols/email.rst:276 msgid "5 15 46 28 0 61 37 62" msgstr "" #: ../../protocols/email.rst:278 msgid "F P u c A 9 l \\+" msgstr "" #: ../../protocols/email.rst:286 msgid "" "The last point to be discussed about `base64` is what happens when the " "length of the sequence of bytes to be encoded is not a multiple of three. In " "this case, the last group of bytes may contain one or two bytes instead of " "three. `Base64` reserves the `=` character as a padding character. This " "character is used once when the last group contains two bytes and twice when " "it contains one byte as illustrated by the two examples below." msgstr "" #: ../../protocols/email.rst:289 msgid "0x14" msgstr "" #: ../../protocols/email.rst:291 msgid "00010100" msgstr "" #: ../../protocols/email.rst:293 msgid "000101 000000" msgstr "" #: ../../protocols/email.rst:295 msgid "5 0" msgstr "" #: ../../protocols/email.rst:297 msgid "F A \\= \\=" msgstr "" #: ../../protocols/email.rst:303 msgid "0x14b9" msgstr "" #: ../../protocols/email.rst:305 msgid "00010100 11111011" msgstr "" #: ../../protocols/email.rst:307 msgid "000101 001111 101100" msgstr "" #: ../../protocols/email.rst:309 msgid "5 15 44" msgstr "" #: ../../protocols/email.rst:311 msgid "F P s \\=" msgstr "" #: ../../protocols/email.rst:318 msgid "" "Now that we have explained the format of the email messages, we can discuss " "how these messages can be exchanged through the Internet. The figure below " "illustrates the protocols that are used when `Alice` sends an email message " "to `Bob`. `Alice` prepares her email with an email client or on a webmail " "interface. To send her email to `Bob`, `Alice`'s client will use the Simple " "Mail Transfer Protocol (:term:`SMTP`) to deliver her message to her SMTP " "server. `Alice`'s email client is configured with the name of the default " "SMTP server for her domain. There is usually at least one SMTP server per " "domain. To deliver the message, `Alice`'s SMTP server must find the SMTP " "server that contains `Bob`'s mailbox. This can be done by using the Mail " "eXchange (MX) records of the DNS. A set of MX records can be associated to " "each domain. Each MX record contains a numerical preference and the fully " "qualified domain name of a SMTP server that is able to deliver email " "messages destined to all valid email addresses of this domain. The DNS can " "return several MX records for a given domain. In this case, the server with " "the lowest numerical preference is used first :rfc:`2821`. If this server is " "not reachable, the second most preferred server is used etc. `Bob`'s SMTP " "server will store the message sent by `Alice` until `Bob` retrieves it using " "a webmail interface or protocols such as the Post Office Protocol " "(:term:`POP`) or the Internet Message Access Protocol (:term:`IMAP`)." msgstr "" #: ../../protocols/email.rst:342 msgid "The Simple Mail Transfer Protocol" msgstr "" #: ../../protocols/email.rst:344 msgid "" "The Simple Mail Transfer Protocol (:term:`SMTP`) defined in :rfc:`5321` is a " "client-server protocol. The SMTP specification distinguishes between five " "types of processes involved in the delivery of email messages. Email " "messages are composed on a Mail User Agent (MUA). The MUA is usually either " "an email client or a webmail. The MUA sends the email message to a Mail " "Submission Agent (MSA). The MSA processes the received email and forwards it " "to the Mail Transmission Agent (MTA). The MTA is responsible for the " "transmission of the email, directly or via intermediate MTAs to the MTA of " "the destination domain. This destination MTA will then forward the message " "to the Mail Delivery Agent (MDA) where it will be accessed by the " "recipient's MUA. SMTP is used for the interactions between MUA and MSA " "[#fsmtpauth]_, MSA-MTA and MTA-MTA." msgstr "" #: ../../protocols/email.rst:346 msgid "" "SMTP is a text-based protocol like many other application-layer protocols on " "the Internet. It relies on the byte-stream service. Servers listen on port " "`25`. Clients send commands that are each composed of one line of ASCII text " "terminated by `CR+LF`. Servers reply by sending ASCII lines that contain a " "three digit numerical error/success code and optional comments." msgstr "" #: ../../protocols/email.rst:348 msgid "" "The SMTP protocol, like most text-based protocols, is specified as a " ":term:`BNF`. The full BNF is defined in :rfc:`5321`. The main SMTP commands " "are defined by the BNF rules shown in the figure below." msgstr "" #: ../../protocols/email.rst:354 msgid "BNF specification of the SMTP commands" msgstr "" #: ../../protocols/email.rst:356 msgid "" "In this BNF, `atext` corresponds to printable ASCII characters. This BNF " "rule is defined in :rfc:`5322`. The five main commands are `EHLO` [#fehlo]_, " "`MAIL FROM:`, `RCPT TO:`, `DATA` and `QUIT`. `Postmaster` is the alias of " "the system administrator who is responsible for a given domain or SMTP " "server. All domains must have a `Postmaster` alias." msgstr "" #: ../../protocols/email.rst:358 msgid "The SMTP responses are defined by the BNF shown in the figure below." msgstr "" #: ../../protocols/email.rst:363 msgid "BNF specification of the SMTP responses" msgstr "" #: ../../protocols/email.rst:366 msgid "" "SMTP servers use structured reply codes containing three digits and an " "optional comment. The first digit of the reply code indicates whether the " "command was successful or not. A reply code of `2xy` indicates that the " "command has been accepted. A reply code of `3xy` indicates that the command " "has been accepted, but additional information from the client is expected. A " "reply code of `4xy` indicates a transient negative reply. This means that " "for some reason, which is indicated by either the other digits or the " "comment, the command cannot be processed immediately, but there is some hope " "that the problem will only be transient. This is basically telling the " "client to try the same command again later. In contrast, a reply code of " "`5xy` indicates a permanent failure or error. In this case, it is useless " "for the client to retry the same command later. Other application layer " "protocols such as FTP :rfc:`959` or HTTP :rfc:`2616` use a similar " "structure for their reply codes. Additional details about the other reply " "codes may be found in :rfc:`5321`." msgstr "" #: ../../protocols/email.rst:368 msgid "Examples of SMTP reply codes include the following :" msgstr "" #: ../../protocols/email.rst:387 msgid "" "Reply code `220` is used by the server as the first message when it agrees " "to interact with the client. Reply code `221` is sent by the server before " "closing the underlying transport connection. Reply code `250` is the " "standard positive reply that indicates the success of the previous command. " "Reply code `354` indicates that the client can start transmitting its email " "message. Reply code `421` is returned when there is a problem " "(e.g. lack of memory/disk resources) that prevents the server from accepting " "the transport connection. Reply codes `450` and `452` indicate that the " "destination mailbox is temporarily unavailable, for various reasons, while " "reply code `550` indicates that the mailbox does not exist or cannot be used " "for policy reasons. The `500` to `503` reply codes correspond to errors in " "the commands sent by the client. The `503` reply code would be sent by the " "server when the client sends commands in an incorrect order (e.g. the client " "tries to send an email before providing the destination address of the " "message)." msgstr "" #: ../../protocols/email.rst:389 msgid "" "The transfer of an email message is performed in three phases. During the " "first phase, the client opens a transport connection with the server. Once " "the connection has been established, the client and the server exchange " "greetings messages (`EHLO` command). Most servers insist on receiving valid " "greeting messages and some of them drop the underlying transport connection " "if they do not receive a valid greeting. Once the greetings have been " "exchanged, the email transfer phase can start. During this phase, the client " "transfers one or more email messages by indicating the email address of the " "sender (`MAIL FROM:` command), the email address of the recipient " "(`RCPT TO:` command) followed by the headers and the body of the email " "message (`DATA` command). Once the client has finished sending all its " "queued email messages to the SMTP server, it terminates the SMTP association " "(`QUIT` command)." msgstr "" #: ../../protocols/email.rst:391 msgid "A successful transfer of an email message is shown below" msgstr "" #: ../../protocols/email.rst:418 msgid "" "In the example above, the MTA running on `mta.example.org` opens a TCP " "connection to the SMTP server on host `smtp.example.com`. The lines prefixed " "with `S:` (resp. `C:`) are the responses sent by the server " "(resp. the commands sent by the client). The server sends its greetings as " "soon as the TCP connection has been established. The client then sends the " "`EHLO` command with its fully qualified domain name. The server replies with " "reply-code `250` and sends its greetings. The SMTP association can now be " "used to exchange an email." msgstr "" #: ../../protocols/email.rst:420 msgid "" "To send an email, the client must first provide the address of the recipient " "with `RCPT TO:`. Then it uses the `MAIL FROM:` with the address of the " "sender. Both the recipient and the sender are accepted by the server. The " "client can now issue the `DATA` command to start the transfer of the email " "message. After having received the `354` reply code, the client sends the " "headers and the body of its email message. The client indicates the end of " "the message by sending a line containing only the `.` (dot) character [#fdot]" "_. The server confirms that the email message has been queued for delivery " "or transmission with a reply code of `250`. The client issues the `QUIT` " "command to close the session and the server confirms with reply-code `221`, " "before closing the TCP connection." msgstr "" #: ../../protocols/email.rst:423 msgid "Open SMTP relays and spam" msgstr "" #: ../../protocols/email.rst:425 msgid "" "Since its creation in 1971, email has been a very useful tool that is used " "by many users to exchange lots of information. In the early days, all SMTP " "servers were open and anyone could use them to forward emails towards their " "final destination. Unfortunately, over the years, some unscrupulous users " "have found ways to use email for marketing purposes or to send malware. The " "first documented abuse of email for marketing purposes occurred in 1978 when " "a marketer who worked for a computer vendor sent a `marketing email `_ to many ARPANET users. At that " "time, the ARPANET could only be used for research purposes and this was an " "abuse of the acceptable use policy. Unfortunately, given the extremely low " "cost of sending emails, the problem of unsolicited emails has not stopped. " "Unsolicited emails are now called spam and a `study `_ carried out by " "ENISA_ in 2009 reveals that 95% of email was spam and this number seems to " "continue to grow. This places a burden on the email infrastructure of " "Internet Service Providers and large companies that need to process many " "useless messages." msgstr "" #: ../../protocols/email.rst:427 msgid "" "Given the amount of spam messages, SMTP servers are no longer open " ":rfc:`5068`. Several extensions to SMTP have been developed in recent years " "to deal with this problem. For example, the SMTP authentication scheme " "defined in :rfc:`4954` can be used by an SMTP server to authenticate a " "client. Several techniques have also been proposed to allow SMTP servers to " "`authenticate` the messages sent by their users :rfc:`4870` :rfc:`4871` ." msgstr "" #: ../../protocols/email.rst:433 msgid "The Post Office Protocol" msgstr "" #: ../../protocols/email.rst:435 msgid "" "When the first versions of SMTP were designed, the Internet was composed of " "minicomputers that were used by an entire university department or research " "lab. These minicomputers were used by many users at the same time. Email was " "mainly used to send messages from a user on a given host to another user on " "a remote host. At that time, SMTP was the only protocol involved in the " "delivery of the emails as all hosts attached to the network were running an " "SMTP server. On such hosts, an email destined to local users was delivered " "by placing the email in a special directory or file owned by the user. " "However, the introduction of personal computers in the 1980s changed this " "environment. Initially, users of these personal computers used applications " "such as :term:`telnet` to open a remote session on the local " ":term:`minicomputer` to read their email. This was not user-friendly. A " "better solution appeared with the development of user friendly email client " "applications on personal computers. Several protocols were designed to allow " "these client applications to retrieve the email messages destined to a user " "from his/her server. Two of these protocols became popular and are still " "used today. The Post Office Protocol (POP), defined in :rfc:`1939`, is the " "simplest one. It allows a client to download all the messages destined to a " "given user from his/her email server. We describe POP briefly in this " "section. The second protocol is the Internet Message Access Protocol (IMAP), " "defined in :rfc:`3501`. IMAP is more powerful, but also more complex than " "POP. IMAP was designed to allow client applications to efficiently access, " "in real-time, to messages stored in various folders on servers. IMAP assumes " "that all the messages of a given user are stored on a server and provides " "the functions that are necessary to search, download, delete or filter " "messages." msgstr "" #: ../../protocols/email.rst:437 msgid "" "POP is another example of a simple line-based protocol. POP runs above the " "bytestream service. A POP server usually listens to port 110. A POP session " "is composed of three parts : an `authorisation` phase during which the " "server verifies the client's credential, a `transaction` phase during which " "the client downloads messages and an `update` phase that concludes the " "session. The client sends commands and the server replies are prefixed by " "`+OK` to indicate a successful command or by `-ERR` to indicate errors." msgstr "" #: ../../protocols/email.rst:439 msgid "" "When a client opens a transport connection with the POP server, the latter " "sends as banner an ASCII-line starting with `+OK`. The POP session is at " "that time in the `authorisation` phase. In this phase, the client can send " "its username (resp. password) with the `USER` (resp. `PASS`) command. The " "server replies with `+OK` if the username (resp. password) is valid and " "`-ERR` otherwise." msgstr "" #: ../../protocols/email.rst:441 msgid "" "Once the username and password have been validated, the POP session enters " "in the `transaction` phase. In this phase, the client can issue several " "commands. The `STAT` command is used to retrieve the status of the server. " "Upon reception of this command, the server replies with a line that contains " "`+OK` followed by the number of messages in the mailbox and the total size " "of the mailbox in bytes. The `RETR` command, followed by a space and an " "integer, is used to retrieve the nth message of the mailbox. The `DELE` " "command is used to mark for deletion the nth message of the mailbox." msgstr "" #: ../../protocols/email.rst:443 msgid "" "Once the client has retrieved and possibly deleted the emails contained in " "the mailbox, it must issue the `QUIT` command. This command terminates the " "POP session and allows the server to delete all the messages that have been " "marked for deletion by using the `DELE` command." msgstr "" #: ../../protocols/email.rst:445 msgid "" "The figure below provides a simple POP session. All lines prefixed with `C:` " "(resp. `S:`) are sent by the client (resp. server)." msgstr "" #: ../../protocols/email.rst:471 msgid "" "In this example, a POP client contacts a POP server on behalf of the user " "named `alice`. Note that in this example, Alice's password is sent in clear " "by the client. This implies that if someone is able to capture the packets " "sent by Alice, he will know Alice's password [#fapop]_. Then Alice's client " "issues the `STAT` command to know the number of messages that are stored in " "her mailbox. It then retrieves and deletes the first message of the mailbox." msgstr "" #: ../../protocols/email.rst:482 msgid "Footnotes" msgstr "" #: ../../protocols/email.rst:483 msgid "" "It could be surprising that the `To:` is not mandatory inside an email " "message. While most email messages will contain this header line an email " "that does not contain a `To:` header line and that relies on the `bcc:` to " "specify the recipient is valid as well." msgstr "" #: ../../protocols/email.rst:485 msgid "" "The list of all standard email header lines may be found at http://" "www.iana.org/assignments/message-headers/message-header-index.html" msgstr "" #: ../../protocols/email.rst:487 msgid "" "During the last years, many Internet Service Providers, campus and " "enterprise networks have deployed SMTP extensions :rfc:`4954` on their MSAs. " "These extensions force the MUAs to be authenticated before the MSA accepts " "an email message from the MUA." msgstr "" #: ../../protocols/email.rst:489 msgid "" "The first versions of SMTP used `HELO` as the first command sent by a client " "to a SMTP server. When SMTP was extended to support newer features such as 8 " "bits characters, it was necessary to allow a server to recognize whether it " "was interacting with a client that supported the extensions or not. `EHLO` " "became mandatory with the publication of :rfc:`2821`." msgstr "" #: ../../protocols/email.rst:491 msgid "" "This implies that a valid email message cannot contain a line with one dot " "followed by `CR` and `LF`. If a user types such a line in an email, his " "email client will automatically add a space character before or after the " "dot when sending the message over SMTP." msgstr "" #: ../../protocols/email.rst:493 msgid "" ":rfc:`1939` defines the APOP authentication scheme that is not vulnerable to " "such attacks." msgstr ""