2. cnp3-ebook
3. protocols/email
4. English
5. Zen

198 ../../protocols/email.rst:363
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — BNF specification of the SMTP responses 39/10000 · 39
199 ../../protocols/email.rst:366
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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`. 1057/10000 · 1057
200 ../../protocols/email.rst:368
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Examples of SMTP reply codes include the following : 52/10000 · 52
201 ../../protocols/email.rst:387
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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). 1043/10000 · 1043
202 ../../protocols/email.rst:389
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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). 898/10000 · 898
203 ../../protocols/email.rst:391
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A successful transfer of an email message is shown below 56/10000 · 56
204 ../../protocols/email.rst:418
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 535/10000 · 535
205 ../../protocols/email.rst:420
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 781/10000 · 781
206 ../../protocols/email.rst:423
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Open SMTP relays and spam 25/10000 · 25
207 ../../protocols/email.rst:425
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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 <http://www.templetons.com/brad/spamreact.html#msg>`_ 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 <http://www.enisa.europa.eu/act/res/other-areas/anti-spam-measures>`_ 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. 1203/10000 · 1203
208 ../../protocols/email.rst:427
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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` . 434/10000 · 434
209 ../../protocols/email.rst:433
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The Post Office Protocol 24/10000 · 24
210 ../../protocols/email.rst:435
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 1862/10000 · 1862
211 ../../protocols/email.rst:437
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 514/10000 · 514
212 ../../protocols/email.rst:439
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 386/10000 · 386
213 ../../protocols/email.rst:441
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 586/10000 · 586
214 ../../protocols/email.rst:443
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 274/10000 · 274
215 ../../protocols/email.rst:445
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The figure below provides a simple POP session. All lines prefixed with `C:` (resp. `S:`) are sent by the client (resp. server). 128/10000 · 128
216 ../../protocols/email.rst:471
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 453/10000 · 453
217 ../../protocols/email.rst:482
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Footnotes 9/10000 · 9