git.fiddlerwoaroof.com
Browse code

fix line endings

Kevin Layer authored on 06/03/2009 07:28:41
Showing 1 changed files
rfc1939.html
History View file @ 5206828
... ... 
@@ -1,1303 +1,1303 @@
1 
-<HEAD>
2 
-<TITLE>rfc1939</TITLE>
3 
-</HEAD>
4 
-
5 
-<H1>rfc1939</H1>
6 
-Press <A NAME=id1 HREF="http://www.cis.ohio-state.edu/hypertext/information/rfc.html">here</A>
7 
-to go to the top of the rfc 'tree'.<p>
8 
-
9 
-<PRE>
10 
-
11 
-
12 
-
13 
-
14 
-
15 
-
16 
-Network Working Group                                           J. Myers
17 
-Request for Comments: <A NAME=id18 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                               Carnegie Mellon
18 
-STD: 53                                                          M. Rose
19 
-Obsoletes: <A NAME=id22 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1725.html">1725</A>                             Dover Beach Consulting, Inc.
20 
-Category: Standards Track                                       May <A NAME=id24 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1996.html">1996</A>
21 
-
22 
-
23 
-                    Post Office Protocol - Version 3
24 
-
25 
-Status of this Memo
26 
-
27 
-   This document specifies an Internet standards track protocol for the
28 
-   Internet community, and requests discussion and suggestions for
29 
-   improvements.  Please refer to the current edition of the "Internet
30 
-   Official Protocol Standards" (STD 1) for the standardization state
31 
-   and status of this protocol.  Distribution of this memo is unlimited.
32 
-
33 
-Table of Contents
34 
-
35 
-   1. Introduction ................................................    2
36 
-   2. A Short Digression ..........................................    2
37 
-   3. Basic Operation .............................................    3
38 
-   4. The AUTHORIZATION State .....................................    4
39 
-      QUIT Command ................................................    5
40 
-   5. The TRANSACTION State .......................................    5
41 
-      STAT Command ................................................    6
42 
-      LIST Command ................................................    6
43 
-      RETR Command ................................................    8
44 
-      DELE Command ................................................    8
45 
-      NOOP Command ................................................    9
46 
-      RSET Command ................................................    9
47 
-   6. The UPDATE State ............................................   10
48 
-      QUIT Command ................................................   10
49 
-   7. Optional POP3 Commands ......................................   11
50 
-      TOP Command .................................................   11
51 
-      UIDL Command ................................................   12
52 
-      USER Command ................................................   13
53 
-      PASS Command ................................................   14
54 
-      APOP Command ................................................   15
55 
-   8. Scaling and Operational Considerations ......................   16
56 
-   9. POP3 Command Summary ........................................   18
57 
-   10. Example POP3 Session .......................................   19
58 
-   11. Message Format .............................................   19
59 
-   12. References .................................................   20
60 
-   13. Security Considerations ....................................   20
61 
-   14. Acknowledgements ...........................................   20
62 
-   15. Authors' Addresses .........................................   21
63 
-   Appendix A. Differences from RFC <A NAME=id111 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1725.html">1725</A> ..........................   22
64 
-
65 
-
66 
-
67 
-Myers &#38; Rose                Standards Track                     [Page 1]
68 
-
69 
-RFC <A NAME=id123 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
70 
-
71 
-
72 
-   Appendix B. Command Index ......................................   23
73 
-
74 
-1. Introduction
75 
-
76 
-   On certain types of smaller nodes in the Internet it is often
77 
-   impractical to maintain a message transport system (MTS).  For
78 
-   example, a workstation may not have sufficient resources (cycles,
79 
-   disk space) in order to permit a SMTP server [RFC<A NAME=id144 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc821.html">821</A>] and associated
80 
-   local mail delivery system to be kept resident and continuously
81 
-   running.  Similarly, it may be expensive (or impossible) to keep a
82 
-   personal computer interconnected to an IP-style network for long
83 
-   amounts of time (the node is lacking the resource known as
84 
-   "connectivity").
85 
-
86 
-   Despite this, it is often very useful to be able to manage mail on
87 
-   these smaller nodes, and they often support a user agent (UA) to aid
88 
-   the tasks of mail handling.  To solve this problem, a node which can
89 
-   support an MTS entity offers a maildrop service to these less endowed
90 
-   nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
91 
-   permit a workstation to dynamically access a maildrop on a server
92 
-   host in a useful fashion.  Usually, this means that the POP3 protocol
93 
-   is used to allow a workstation to retrieve mail that the server is
94 
-   holding for it.
95 
-
96 
-   POP3 is not intended to provide extensive manipulation operations of
97 
-   mail on the server; normally, mail is downloaded and then deleted.  A
98 
-   more advanced (and complex) protocol, IMAP4, is discussed in
99 
-   [RFC<A NAME=id185 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1730.html">1730</A>].
100 
-
101 
-   For the remainder of this memo, the term "client host" refers to a
102 
-   host making use of the POP3 service, while the term "server host"
103 
-   refers to a host which offers the POP3 service.
104 
-
105 
-2. A Short Digression
106 
-
107 
-   This memo does not specify how a client host enters mail into the
108 
-   transport system, although a method consistent with the philosophy of
109 
-   this memo is presented here:
110 
-
111 
-      When the user agent on a client host wishes to enter a message
112 
-      into the transport system, it establishes an SMTP connection to
113 
-      its relay host and sends all mail to it.  This relay host could
114 
-      be, but need not be, the POP3 server host for the client host.  Of
115 
-      course, the relay host must accept mail for delivery to arbitrary
116 
-      recipient addresses, that functionality is not required of all
117 
-      SMTP servers.
118 
-
119 
-
120 
-
121 
-
122 
-
123 
-Myers &#38; Rose                Standards Track                     [Page 2]
124 
-
125 
-RFC <A NAME=id237 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
126 
-
127 
-
128 
-3. Basic Operation
129 
-
130 
-   Initially, the server host starts the POP3 service by listening on
131 
-   TCP port 110.  When a client host wishes to make use of the service,
132 
-   it establishes a TCP connection with the server host.  When the
133 
-   connection is established, the POP3 server sends a greeting.  The
134 
-   client and POP3 server then exchange commands and responses
135 
-   (respectively) until the connection is closed or aborted.
136 
-
137 
-   Commands in the POP3 consist of a case-insensitive keyword, possibly
138 
-   followed by one or more arguments.  All commands are terminated by a
139 
-   CRLF pair.  Keywords and arguments consist of printable ASCII
140 
-   characters.  Keywords and arguments are each separated by a single
141 
-   SPACE character.  Keywords are three or four characters long. Each
142 
-   argument may be up to 40 characters long.
143 
-
144 
-   Responses in the POP3 consist of a status indicator and a keyword
145 
-   possibly followed by additional information.  All responses are
146 
-   terminated by a CRLF pair.  Responses may be up to 512 characters
147 
-   long, including the terminating CRLF.  There are currently two status
148 
-   indicators: positive ("+OK") and negative ("-ERR").  Servers MUST
149 
-   send the "+OK" and "-ERR" in upper case.
150 
-
151 
-   Responses to certain commands are multi-line.  In these cases, which
152 
-   are clearly indicated below, after sending the first line of the
153 
-   response and a CRLF, any additional lines are sent, each terminated
154 
-   by a CRLF pair.  When all lines of the response have been sent, a
155 
-   final line is sent, consisting of a termination octet (decimal code
156 
-   046, ".") and a CRLF pair.  If any line of the multi-line response
157 
-   begins with the termination octet, the line is "byte-stuffed" by
158 
-   pre-pending the termination octet to that line of the response.
159 
-   Hence a multi-line response is terminated with the five octets
160 
-   "CRLF.CRLF".  When examining a multi-line response, the client checks
161 
-   to see if the line begins with the termination octet.  If so and if
162 
-   octets other than CRLF follow, the first octet of the line (the
163 
-   termination octet) is stripped away.  If so and if CRLF immediately
164 
-   follows the termination character, then the response from the POP
165 
-   server is ended and the line containing ".CRLF" is not considered
166 
-   part of the multi-line response.
167 
-
168 
-   A POP3 session progresses through a number of states during its
169 
-   lifetime.  Once the TCP connection has been opened and the POP3
170 
-   server has sent the greeting, the session enters the AUTHORIZATION
171 
-   state.  In this state, the client must identify itself to the POP3
172 
-   server.  Once the client has successfully done this, the server
173 
-   acquires resources associated with the client's maildrop, and the
174 
-   session enters the TRANSACTION state.  In this state, the client
175 
-   requests actions on the part of the POP3 server.  When the client has
176 
-
177 
-
178 
-
179 
-Myers &#38; Rose                Standards Track                     [Page 3]
180 
-
181 
-RFC <A NAME=id349 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
182 
-
183 
-
184 
-   issued the QUIT command, the session enters the UPDATE state.  In
185 
-   this state, the POP3 server releases any resources acquired during
186 
-   the TRANSACTION state and says goodbye.  The TCP connection is then
187 
-   closed.
188 
-
189 
-   A server MUST respond to an unrecognized, unimplemented, or
190 
-   syntactically invalid command by responding with a negative status
191 
-   indicator.  A server MUST respond to a command issued when the
192 
-   session is in an incorrect state by responding with a negative status
193 
-   indicator.  There is no general method for a client to distinguish
194 
-   between a server which does not implement an optional command and a
195 
-   server which is unwilling or unable to process the command.
196 
-
197 
-   A POP3 server MAY have an inactivity autologout timer.  Such a timer
198 
-   MUST be of at least 10 minutes' duration.  The receipt of any command
199 
-   from the client during that interval should suffice to reset the
200 
-   autologout timer.  When the timer expires, the session does NOT enter
201 
-   the UPDATE state--the server should close the TCP connection without
202 
-   removing any messages or sending any response to the client.
203 
-
204 
-4. The AUTHORIZATION State
205 
-
206 
-   Once the TCP connection has been opened by a POP3 client, the POP3
207 
-   server issues a one line greeting.  This can be any positive
208 
-   response.  An example might be:
209 
-
210 
-      S:  +OK POP3 server ready
211 
-
212 
-   The POP3 session is now in the AUTHORIZATION state.  The client must
213 
-   now identify and authenticate itself to the POP3 server.  Two
214 
-   possible mechanisms for doing this are described in this document,
215 
-   the USER and PASS command combination and the APOP command.  Both
216 
-   mechanisms are described later in this document.  Additional
217 
-   authentication mechanisms are described in [RFC<A NAME=id422 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1734.html">1734</A>].  While there is
218 
-   no single authentication mechanism that is required of all POP3
219 
-   servers, a POP3 server must of course support at least one
220 
-   authentication mechanism.
221 
-
222 
-   Once the POP3 server has determined through the use of any
223 
-   authentication command that the client should be given access to the
224 
-   appropriate maildrop, the POP3 server then acquires an exclusive-
225 
-   access lock on the maildrop, as necessary to prevent messages from
226 
-   being modified or removed before the session enters the UPDATE state.
227 
-   If the lock is successfully acquired, the POP3 server responds with a
228 
-   positive status indicator.  The POP3 session now enters the
229 
-   TRANSACTION state, with no messages marked as deleted.  If the
230 
-   maildrop cannot be opened for some reason (for example, a lock can
231 
-   not be acquired, the client is denied access to the appropriate
232 
-
233 
-
234 
-
235 
-Myers &#38; Rose                Standards Track                     [Page 4]
236 
-
237 
-RFC <A NAME=id462 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
238 
-
239 
-
240 
-   maildrop, or the maildrop cannot be parsed), the POP3 server responds
241 
-   with a negative status indicator.  (If a lock was acquired but the
242 
-   POP3 server intends to respond with a negative status indicator, the
243 
-   POP3 server must release the lock prior to rejecting the command.)
244 
-   After returning a negative status indicator, the server may close the
245 
-   connection.  If the server does not close the connection, the client
246 
-   may either issue a new authentication command and start again, or the
247 
-   client may issue the QUIT command.
248 
-
249 
-   After the POP3 server has opened the maildrop, it assigns a message-
250 
-   number to each message, and notes the size of each message in octets.
251 
-   The first message in the maildrop is assigned a message-number of
252 
-   "1", the second is assigned "2", and so on, so that the nth message
253 
-   in a maildrop is assigned a message-number of "n".  In POP3 commands
254 
-   and responses, all message-numbers and message sizes are expressed in
255 
-   base-10 (i.e., decimal).
256 
-
257 
-   Here is the summary for the QUIT command when used in the
258 
-   AUTHORIZATION state:
259 
-
260 
-      QUIT
261 
-
262 
-         Arguments: none
263 
-
264 
-         Restrictions: none
265 
-
266 
-         Possible Responses:
267 
-             +OK
268 
-
269 
-         Examples:
270 
-             C: QUIT
271 
-             S: +OK dewey POP3 server signing off
272 
-
273 
-5. The TRANSACTION State
274 
-
275 
-   Once the client has successfully identified itself to the POP3 server
276 
-   and the POP3 server has locked and opened the appropriate maildrop,
277 
-   the POP3 session is now in the TRANSACTION state.  The client may now
278 
-   issue any of the following POP3 commands repeatedly.  After each
279 
-   command, the POP3 server issues a response.  Eventually, the client
280 
-   issues the QUIT command and the POP3 session enters the UPDATE state.
281 
-
282 
-
283 
-
284 
-
285 
-
286 
-
287 
-
288 
-
289 
-
290 
-
291 
-Myers &#38; Rose                Standards Track                     [Page 5]
292 
-
293 
-RFC <A NAME=id574 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
294 
-
295 
-
296 
-   Here are the POP3 commands valid in the TRANSACTION state:
297 
-
298 
-      STAT
299 
-
300 
-         Arguments: none
301 
-
302 
-         Restrictions:
303 
-             may only be given in the TRANSACTION state
304 
-
305 
-         Discussion:
306 
-             The POP3 server issues a positive response with a line
307 
-             containing information for the maildrop.  This line is
308 
-             called a "drop listing" for that maildrop.
309 
-
310 
-             In order to simplify parsing, all POP3 servers are
311 
-             required to use a certain format for drop listings.  The
312 
-             positive response consists of "+OK" followed by a single
313 
-             space, the number of messages in the maildrop, a single
314 
-             space, and the size of the maildrop in octets.  This memo
315 
-             makes no requirement on what follows the maildrop size.
316 
-             Minimal implementations should just end that line of the
317 
-             response with a CRLF pair.  More advanced implementations
318 
-             may include other information.
319 
-
320 
-                NOTE: This memo STRONGLY discourages implementations
321 
-                from supplying additional information in the drop
322 
-                listing.  Other, optional, facilities are discussed
323 
-                later on which permit the client to parse the messages
324 
-                in the maildrop.
325 
-
326 
-             Note that messages marked as deleted are not counted in
327 
-             either total.
328 
-
329 
-         Possible Responses:
330 
-             +OK nn mm
331 
-
332 
-         Examples:
333 
-             C: STAT
334 
-             S: +OK 2 320
335 
-
336 
-
337 
-      LIST [msg]
338 
-
339 
-         Arguments:
340 
-             a message-number (optional), which, if present, may NOT
341 
-             refer to a message marked as deleted
342 
-
343 
-
344 
-
345 
-
346 
-
347 
-Myers &#38; Rose                Standards Track                     [Page 6]
348 
-
349 
-RFC <A NAME=id686 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
350 
-
351 
-
352 
-         Restrictions:
353 
-             may only be given in the TRANSACTION state
354 
-
355 
-         Discussion:
356 
-             If an argument was given and the POP3 server issues a
357 
-             positive response with a line containing information for
358 
-             that message.  This line is called a "scan listing" for
359 
-             that message.
360 
-
361 
-             If no argument was given and the POP3 server issues a
362 
-             positive response, then the response given is multi-line.
363 
-             After the initial +OK, for each message in the maildrop,
364 
-             the POP3 server responds with a line containing
365 
-             information for that message.  This line is also called a
366 
-             "scan listing" for that message.  If there are no
367 
-             messages in the maildrop, then the POP3 server responds
368 
-             with no scan listings--it issues a positive response
369 
-             followed by a line containing a termination octet and a
370 
-             CRLF pair.
371 
-
372 
-             In order to simplify parsing, all POP3 servers are
373 
-             required to use a certain format for scan listings.  A
374 
-             scan listing consists of the message-number of the
375 
-             message, followed by a single space and the exact size of
376 
-             the message in octets.  Methods for calculating the exact
377 
-             size of the message are described in the "Message Format"
378 
-             section below.  This memo makes no requirement on what
379 
-             follows the message size in the scan listing.  Minimal
380 
-             implementations should just end that line of the response
381 
-             with a CRLF pair.  More advanced implementations may
382 
-             include other information, as parsed from the message.
383 
-
384 
-                NOTE: This memo STRONGLY discourages implementations
385 
-                from supplying additional information in the scan
386 
-                listing.  Other, optional, facilities are discussed
387 
-                later on which permit the client to parse the messages
388 
-                in the maildrop.
389 
-
390 
-             Note that messages marked as deleted are not listed.
391 
-
392 
-         Possible Responses:
393 
-             +OK scan listing follows
394 
-             -ERR no such message
395 
-
396 
-         Examples:
397 
-             C: LIST
398 
-             S: +OK 2 messages (320 octets)
399 
-             S: 1 120
400 
-
401 
-
402 
-
403 
-Myers &#38; Rose                Standards Track                     [Page 7]
404 
-
405 
-RFC <A NAME=id798 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
406 
-
407 
-
408 
-             S: 2 200
409 
-             S: .
410 
-               ...
411 
-             C: LIST 2
412 
-             S: +OK 2 200
413 
-               ...
414 
-             C: LIST 3
415 
-             S: -ERR no such message, only 2 messages in maildrop
416 
-
417 
-
418 
-      RETR msg
419 
-
420 
-         Arguments:
421 
-             a message-number (required) which may NOT refer to a
422 
-             message marked as deleted
423 
-
424 
-         Restrictions:
425 
-             may only be given in the TRANSACTION state
426 
-
427 
-         Discussion:
428 
-             If the POP3 server issues a positive response, then the
429 
-             response given is multi-line.  After the initial +OK, the
430 
-             POP3 server sends the message corresponding to the given
431 
-             message-number, being careful to byte-stuff the termination
432 
-             character (as with all multi-line responses).
433 
-
434 
-         Possible Responses:
435 
-             +OK message follows
436 
-             -ERR no such message
437 
-
438 
-         Examples:
439 
-             C: RETR 1
440 
-             S: +OK 120 octets
441 
-             S: &#60;the POP3 server sends the entire message here&#62;
442 
-             S: .
443 
-
444 
-
445 
-      DELE msg
446 
-
447 
-         Arguments:
448 
-             a message-number (required) which may NOT refer to a
449 
-             message marked as deleted
450 
-
451 
-         Restrictions:
452 
-             may only be given in the TRANSACTION state
453 
-
454 
-
455 
-
456 
-
457 
-
458 
-
459 
-Myers &#38; Rose                Standards Track                     [Page 8]
460 
-
461 
-RFC <A NAME=id910 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
462 
-
463 
-
464 
-         Discussion:
465 
-             The POP3 server marks the message as deleted.  Any future
466 
-             reference to the message-number associated with the message
467 
-             in a POP3 command generates an error.  The POP3 server does
468 
-             not actually delete the message until the POP3 session
469 
-             enters the UPDATE state.
470 
-
471 
-         Possible Responses:
472 
-             +OK message deleted
473 
-             -ERR no such message
474 
-
475 
-         Examples:
476 
-             C: DELE 1
477 
-             S: +OK message 1 deleted
478 
-                ...
479 
-             C: DELE 2
480 
-             S: -ERR message 2 already deleted
481 
-
482 
-
483 
-      NOOP
484 
-
485 
-         Arguments: none
486 
-
487 
-         Restrictions:
488 
-             may only be given in the TRANSACTION state
489 
-
490 
-         Discussion:
491 
-             The POP3 server does nothing, it merely replies with a
492 
-             positive response.
493 
-
494 
-         Possible Responses:
495 
-             +OK
496 
-
497 
-         Examples:
498 
-             C: NOOP
499 
-             S: +OK
500 
-
501 
-
502 
-      RSET
503 
-
504 
-         Arguments: none
505 
-
506 
-         Restrictions:
507 
-             may only be given in the TRANSACTION state
508 
-
509 
-         Discussion:
510 
-             If any messages have been marked as deleted by the POP3
511 
-             server, they are unmarked.  The POP3 server then replies
512 
-
513 
-
514 
-
515 
-Myers &#38; Rose                Standards Track                     [Page 9]
516 
-
517 
-RFC <A NAME=id1022 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
518 
-
519 
-
520 
-             with a positive response.
521 
-
522 
-         Possible Responses:
523 
-             +OK
524 
-
525 
-         Examples:
526 
-             C: RSET
527 
-             S: +OK maildrop has 2 messages (320 octets)
528 
-
529 
-6. The UPDATE State
530 
-
531 
-   When the client issues the QUIT command from the TRANSACTION state,
532 
-   the POP3 session enters the UPDATE state.  (Note that if the client
533 
-   issues the QUIT command from the AUTHORIZATION state, the POP3
534 
-   session terminates but does NOT enter the UPDATE state.)
535 
-
536 
-   If a session terminates for some reason other than a client-issued
537 
-   QUIT command, the POP3 session does NOT enter the UPDATE state and
538 
-   MUST not remove any messages from the maildrop.
539 
-
540 
-      QUIT
541 
-
542 
-         Arguments: none
543 
-
544 
-         Restrictions: none
545 
-
546 
-         Discussion:
547 
-             The POP3 server removes all messages marked as deleted
548 
-             from the maildrop and replies as to the status of this
549 
-             operation.  If there is an error, such as a resource
550 
-             shortage, encountered while removing messages, the
551 
-             maildrop may result in having some or none of the messages
552 
-             marked as deleted be removed.  In no case may the server
553 
-             remove any messages not marked as deleted.
554 
-
555 
-             Whether the removal was successful or not, the server
556 
-             then releases any exclusive-access lock on the maildrop
557 
-             and closes the TCP connection.
558 
-
559 
-         Possible Responses:
560 
-             +OK
561 
-             -ERR some deleted messages not removed
562 
-
563 
-         Examples:
564 
-             C: QUIT
565 
-             S: +OK dewey POP3 server signing off (maildrop empty)
566 
-                ...
567 
-             C: QUIT
568 
-
569 
-
570 
-
571 
-Myers &#38; Rose                Standards Track                    [Page 10]
572 
-
573 
-RFC <A NAME=id1134 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
574 
-
575 
-
576 
-             S: +OK dewey POP3 server signing off (2 messages left)
577 
-                ...
578 
-
579 
-7. Optional POP3 Commands
580 
-
581 
-   The POP3 commands discussed above must be supported by all minimal
582 
-   implementations of POP3 servers.
583 
-
584 
-   The optional POP3 commands described below permit a POP3 client
585 
-   greater freedom in message handling, while preserving a simple POP3
586 
-   server implementation.
587 
-
588 
-      NOTE: This memo STRONGLY encourages implementations to support
589 
-      these commands in lieu of developing augmented drop and scan
590 
-      listings.  In short, the philosophy of this memo is to put
591 
-      intelligence in the part of the POP3 client and not the POP3
592 
-      server.
593 
-
594 
-      TOP msg n
595 
-
596 
-         Arguments:
597 
-             a message-number (required) which may NOT refer to to a
598 
-             message marked as deleted, and a non-negative number
599 
-             of lines (required)
600 
-
601 
-         Restrictions:
602 
-             may only be given in the TRANSACTION state
603 
-
604 
-         Discussion:
605 
-             If the POP3 server issues a positive response, then the
606 
-             response given is multi-line.  After the initial +OK, the
607 
-             POP3 server sends the headers of the message, the blank
608 
-             line separating the headers from the body, and then the
609 
-             number of lines of the indicated message's body, being
610 
-             careful to byte-stuff the termination character (as with
611 
-             all multi-line responses).
612 
-
613 
-             Note that if the number of lines requested by the POP3
614 
-             client is greater than than the number of lines in the
615 
-             body, then the POP3 server sends the entire message.
616 
-
617 
-         Possible Responses:
618 
-             +OK top of message follows
619 
-             -ERR no such message
620 
-
621 
-         Examples:
622 
-             C: TOP 1 10
623 
-             S: +OK
624 
-
625 
-
626 
-
627 
-Myers &#38; Rose                Standards Track                    [Page 11]
628 
-
629 
-RFC <A NAME=id1246 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
630 
-
631 
-
632 
-             S: &#60;the POP3 server sends the headers of the
633 
-                message, a blank line, and the first 10 lines
634 
-                of the body of the message&#62;
635 
-             S: .
636 
-                ...
637 
-             C: TOP 100 3
638 
-             S: -ERR no such message
639 
-
640 
-
641 
-      UIDL [msg]
642 
-
643 
-      Arguments:
644 
-          a message-number (optional), which, if present, may NOT
645 
-          refer to a message marked as deleted
646 
-
647 
-      Restrictions:
648 
-          may only be given in the TRANSACTION state.
649 
-
650 
-      Discussion:
651 
-          If an argument was given and the POP3 server issues a positive
652 
-          response with a line containing information for that message.
653 
-          This line is called a "unique-id listing" for that message.
654 
-
655 
-          If no argument was given and the POP3 server issues a positive
656 
-          response, then the response given is multi-line.  After the
657 
-          initial +OK, for each message in the maildrop, the POP3 server
658 
-          responds with a line containing information for that message.
659 
-          This line is called a "unique-id listing" for that message.
660 
-
661 
-          In order to simplify parsing, all POP3 servers are required to
662 
-          use a certain format for unique-id listings.  A unique-id
663 
-          listing consists of the message-number of the message,
664 
-          followed by a single space and the unique-id of the message.
665 
-          No information follows the unique-id in the unique-id listing.
666 
-
667 
-          The unique-id of a message is an arbitrary server-determined
668 
-          string, consisting of one to 70 characters in the range 0x21
669 
-          to 0x7E, which uniquely identifies a message within a
670 
-          maildrop and which persists across sessions.  This
671 
-          persistence is required even if a session ends without
672 
-          entering the UPDATE state.  The server should never reuse an
673 
-          unique-id in a given maildrop, for as long as the entity
674 
-          using the unique-id exists.
675 
-
676 
-          Note that messages marked as deleted are not listed.
677 
-
678 
-          While it is generally preferable for server implementations
679 
-          to store arbitrarily assigned unique-ids in the maildrop,
680 
-
681 
-
682 
-
683 
-Myers &#38; Rose                Standards Track                    [Page 12]
684 
-
685 
-RFC <A NAME=id1358 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
686 
-
687 
-
688 
-          this specification is intended to permit unique-ids to be
689 
-          calculated as a hash of the message.  Clients should be able
690 
-          to handle a situation where two identical copies of a
691 
-          message in a maildrop have the same unique-id.
692 
-
693 
-      Possible Responses:
694 
-          +OK unique-id listing follows
695 
-          -ERR no such message
696 
-
697 
-      Examples:
698 
-          C: UIDL
699 
-          S: +OK
700 
-          S: 1 whqtswO00WBw418f9t5JxYwZ
701 
-          S: 2 QhdPYR:00WBw1Ph7x7
702 
-          S: .
703 
-             ...
704 
-          C: UIDL 2
705 
-          S: +OK 2 QhdPYR:00WBw1Ph7x7
706 
-             ...
707 
-          C: UIDL 3
708 
-          S: -ERR no such message, only 2 messages in maildrop
709 
-
710 
-
711 
-      USER name
712 
-
713 
-         Arguments:
714 
-             a string identifying a mailbox (required), which is of
715 
-             significance ONLY to the server
716 
-
717 
-         Restrictions:
718 
-             may only be given in the AUTHORIZATION state after the POP3
719 
-             greeting or after an unsuccessful USER or PASS command
720 
-
721 
-         Discussion:
722 
-             To authenticate using the USER and PASS command
723 
-             combination, the client must first issue the USER
724 
-             command.  If the POP3 server responds with a positive
725 
-             status indicator ("+OK"), then the client may issue
726 
-             either the PASS command to complete the authentication,
727 
-             or the QUIT command to terminate the POP3 session.  If
728 
-             the POP3 server responds with a negative status indicator
729 
-             ("-ERR") to the USER command, then the client may either
730 
-             issue a new authentication command or may issue the QUIT
731 
-             command.
732 
-
733 
-             The server may return a positive response even though no
734 
-             such mailbox exists.  The server may return a negative
735 
-             response if mailbox exists, but does not permit plaintext
736 
-
737 
-
738 
-
739 
-Myers &#38; Rose                Standards Track                    [Page 13]
740 
-
741 
-RFC <A NAME=id1470 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
742 
-
743 
-
744 
-             password authentication.
745 
-
746 
-         Possible Responses:
747 
-             +OK name is a valid mailbox
748 
-             -ERR never heard of mailbox name
749 
-
750 
-         Examples:
751 
-             C: USER frated
752 
-             S: -ERR sorry, no mailbox for frated here
753 
-                ...
754 
-             C: USER mrose
755 
-             S: +OK mrose is a real hoopy frood
756 
-
757 
-
758 
-      PASS string
759 
-
760 
-         Arguments:
761 
-             a server/mailbox-specific password (required)
762 
-
763 
-         Restrictions:
764 
-             may only be given in the AUTHORIZATION state immediately
765 
-             after a successful USER command
766 
-
767 
-         Discussion:
768 
-             When the client issues the PASS command, the POP3 server
769 
-             uses the argument pair from the USER and PASS commands to
770 
-             determine if the client should be given access to the
771 
-             appropriate maildrop.
772 
-
773 
-             Since the PASS command has exactly one argument, a POP3
774 
-             server may treat spaces in the argument as part of the
775 
-             password, instead of as argument separators.
776 
-
777 
-         Possible Responses:
778 
-             +OK maildrop locked and ready
779 
-             -ERR invalid password
780 
-             -ERR unable to lock maildrop
781 
-
782 
-         Examples:
783 
-             C: USER mrose
784 
-             S: +OK mrose is a real hoopy frood
785 
-             C: PASS secret
786 
-             S: -ERR maildrop already locked
787 
-               ...
788 
-             C: USER mrose
789 
-             S: +OK mrose is a real hoopy frood
790 
-             C: PASS secret
791 
-             S: +OK mrose's maildrop has 2 messages (320 octets)
792 
-
793 
-
794 
-
795 
-Myers &#38; Rose                Standards Track                    [Page 14]
796 
-
797 
-RFC <A NAME=id1582 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
798 
-
799 
-
800 
-      APOP name digest
801 
-
802 
-         Arguments:
803 
-             a string identifying a mailbox and a MD5 digest string
804 
-             (both required)
805 
-
806 
-         Restrictions:
807 
-             may only be given in the AUTHORIZATION state after the POP3
808 
-             greeting or after an unsuccessful USER or PASS command
809 
-
810 
-         Discussion:
811 
-             Normally, each POP3 session starts with a USER/PASS
812 
-             exchange.  This results in a server/user-id specific
813 
-             password being sent in the clear on the network.  For
814 
-             intermittent use of POP3, this may not introduce a sizable
815 
-             risk.  However, many POP3 client implementations connect to
816 
-             the POP3 server on a regular basis -- to check for new
817 
-             mail.  Further the interval of session initiation may be on
818 
-             the order of five minutes.  Hence, the risk of password
819 
-             capture is greatly enhanced.
820 
-
821 
-             An alternate method of authentication is required which
822 
-             provides for both origin authentication and replay
823 
-             protection, but which does not involve sending a password
824 
-             in the clear over the network.  The APOP command provides
825 
-             this functionality.
826 
-
827 
-             A POP3 server which implements the APOP command will
828 
-             include a timestamp in its banner greeting.  The syntax of
829 
-             the timestamp corresponds to the `msg-id' in [RFC<A NAME=id1647 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html">822</A>], and
830 
-             MUST be different each time the POP3 server issues a banner
831 
-             greeting.  For example, on a UNIX implementation in which a
832 
-             separate UNIX process is used for each instance of a POP3
833 
-             server, the syntax of the timestamp might be:
834 
-
835 
-                &#60;process-ID.clock@hostname&#62;
836 
-
837 
-             where `process-ID' is the decimal value of the process's
838 
-             PID, clock is the decimal value of the system clock, and
839 
-             hostname is the fully-qualified domain-name corresponding
840 
-             to the host where the POP3 server is running.
841 
-
842 
-             The POP3 client makes note of this timestamp, and then
843 
-             issues the APOP command.  The `name' parameter has
844 
-             identical semantics to the `name' parameter of the USER
845 
-             command. The `digest' parameter is calculated by applying
846 
-             the MD5 algorithm [RFC<A NAME=id1682 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1321.html">1321</A>] to a string consisting of the
847 
-             timestamp (including angle-brackets) followed by a shared
848 
-
849 
-
850 
-
851 
-Myers &#38; Rose                Standards Track                    [Page 15]
852 
-
853 
-RFC <A NAME=id1696 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
854 
-
855 
-
856 
-             secret.  This shared secret is a string known only to the
857 
-             POP3 client and server.  Great care should be taken to
858 
-             prevent unauthorized disclosure of the secret, as knowledge
859 
-             of the secret will allow any entity to successfully
860 
-             masquerade as the named user.  The `digest' parameter
861 
-             itself is a 16-octet value which is sent in hexadecimal
862 
-             format, using lower-case ASCII characters.
863 
-
864 
-             When the POP3 server receives the APOP command, it verifies
865 
-             the digest provided.  If the digest is correct, the POP3
866 
-             server issues a positive response, and the POP3 session
867 
-             enters the TRANSACTION state.  Otherwise, a negative
868 
-             response is issued and the POP3 session remains in the
869 
-             AUTHORIZATION state.
870 
-
871 
-             Note that as the length of the shared secret increases, so
872 
-             does the difficulty of deriving it.  As such, shared
873 
-             secrets should be long strings (considerably longer than
874 
-             the 8-character example shown below).
875 
-
876 
-         Possible Responses:
877 
-             +OK maildrop locked and ready
878 
-             -ERR permission denied
879 
-
880 
-         Examples:
881 
-             S: +OK POP3 server ready &#60;1896.697170952@dbc.mtview.ca.us&#62;
882 
-             C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
883 
-             S: +OK maildrop has 1 message (369 octets)
884 
-
885 
-             In this example, the shared  secret  is  the  string  `tan-
886 
-             staaf'.  Hence, the MD5 algorithm is applied to the string
887 
-
888 
-                &#60;1896.697170952@dbc.mtview.ca.us&#62;tanstaaf
889 
-
890 
-             which produces a digest value of
891 
-
892 
-                c4c9334bac560ecc979e58001b3e22fb
893 
-
894 
-8. Scaling and Operational Considerations
895 
-
896 
-   Since some of the optional features described above were added to the
897 
-   POP3 protocol, experience has accumulated in using them in large-
898 
-   scale commercial post office operations where most of the users are
899 
-   unrelated to each other.  In these situations and others, users and
900 
-   vendors of POP3 clients have discovered that the combination of using
901 
-   the UIDL command and not issuing the DELE command can provide a weak
902 
-   version of the "maildrop as semi-permanent repository" functionality
903 
-   normally associated with IMAP.  Of course the other capabilities of
904 
-
905 
-
906 
-
907 
-Myers &#38; Rose                Standards Track                    [Page 16]
908 
-
909 
-RFC <A NAME=id1808 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
910 
-
911 
-
912 
-   IMAP, such as polling an existing connection for newly arrived
913 
-   messages and supporting multiple folders on the server, are not
914 
-   present in POP3.
915 
-
916 
-   When these facilities are used in this way by casual users, there has
917 
-   been a tendency for already-read messages to accumulate on the server
918 
-   without bound.  This is clearly an undesirable behavior pattern from
919 
-   the standpoint of the server operator.  This situation is aggravated
920 
-   by the fact that the limited capabilities of the POP3 do not permit
921 
-   efficient handling of maildrops which have hundreds or thousands of
922 
-   messages.
923 
-
924 
-   Consequently, it is recommended that operators of large-scale multi-
925 
-   user servers, especially ones in which the user's only access to the
926 
-   maildrop is via POP3, consider such options as:
927 
-
928 
-   *  Imposing a per-user maildrop storage quota or the like.
929 
-
930 
-      A disadvantage to this option is that accumulation of messages may
931 
-      result in the user's inability to receive new ones into the
932 
-      maildrop.  Sites which choose this option should be sure to inform
933 
-      users of impending or current exhaustion of quota, perhaps by
934 
-      inserting an appropriate message into the user's maildrop.
935 
-
936 
-   *  Enforce a site policy regarding mail retention on the server.
937 
-
938 
-      Sites are free to establish local policy regarding the storage and
939 
-      retention of messages on the server, both read and unread.  For
940 
-      example, a site might delete unread messages from the server after
941 
-      60 days and delete read messages after 7 days.  Such message
942 
-      deletions are outside the scope of the POP3 protocol and are not
943 
-      considered a protocol violation.
944 
-
945 
-      Server operators enforcing message deletion policies should take
946 
-      care to make all users aware of the policies in force.
947 
-
948 
-      Clients must not assume that a site policy will automate message
949 
-      deletions, and should continue to explicitly delete messages using
950 
-      the DELE command when appropriate.
951 
-
952 
-      It should be noted that enforcing site message deletion policies
953 
-      may be confusing to the user community, since their POP3 client
954 
-      may contain configuration options to leave mail on the server
955 
-      which will not in fact be supported by the server.
956 
-
957 
-      One special case of a site policy is that messages may only be
958 
-      downloaded once from the server, and are deleted after this has
959 
-      been accomplished.  This could be implemented in POP3 server
960 
-
961 
-
962 
-
963 
-Myers &#38; Rose                Standards Track                    [Page 17]
964 
-
965 
-RFC <A NAME=id1920 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
966 
-
967 
-
968 
-      software by the following mechanism: "following a POP3 login by a
969 
-      client which was ended by a QUIT, delete all messages downloaded
970 
-      during the session with the RETR command".  It is important not to
971 
-      delete messages in the event of abnormal connection termination
972 
-      (ie, if no QUIT was received from the client) because the client
973 
-      may not have successfully received or stored the messages.
974 
-      Servers implementing a download-and-delete policy may also wish to
975 
-      disable or limit the optional TOP command, since it could be used
976 
-      as an alternate mechanism to download entire messages.
977 
-
978 
-9. POP3 Command Summary
979 
-
980 
-      Minimal POP3 Commands:
981 
-
982 
-         USER name               valid in the AUTHORIZATION state
983 
-         PASS string
984 
-         QUIT
985 
-
986 
-         STAT                    valid in the TRANSACTION state
987 
-         LIST [msg]
988 
-         RETR msg
989 
-         DELE msg
990 
-         NOOP
991 
-         RSET
992 
-         QUIT
993 
-
994 
-      Optional POP3 Commands:
995 
-
996 
-         APOP name digest        valid in the AUTHORIZATION state
997 
-
998 
-         TOP msg n               valid in the TRANSACTION state
999 
-         UIDL [msg]
1000 
-
1001 
-      POP3 Replies:
1002 
-
1003 
-         +OK
1004 
-         -ERR
1005 
-
1006 
-      Note that with the exception of the STAT, LIST, and UIDL commands,
1007 
-      the reply given by the POP3 server to any command is significant
1008 
-      only to "+OK" and "-ERR".  Any text occurring after this reply
1009 
-      may be ignored by the client.
1010 
-
1011 
-
1012 
-
1013 
-
1014 
-
1015 
-
1016 
-
1017 
-
1018 
-
1019 
-Myers &#38; Rose                Standards Track                    [Page 18]
1020 
-
1021 
-RFC <A NAME=id2032 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
1022 
-
1023 
-
1024 
-10. Example POP3 Session
1025 
-
1026 
-      S: &#60;wait for connection on TCP port 110&#62;
1027 
-      C: &#60;open connection&#62;
1028 
-      S:    +OK POP3 server ready &#60;1896.697170952@dbc.mtview.ca.us&#62;
1029 
-      C:    APOP mrose c4c9334bac560ecc979e58001b3e22fb
1030 
-      S:    +OK mrose's maildrop has 2 messages (320 octets)
1031 
-      C:    STAT
1032 
-      S:    +OK 2 320
1033 
-      C:    LIST
1034 
-      S:    +OK 2 messages (320 octets)
1035 
-      S:    1 120
1036 
-      S:    2 200
1037 
-      S:    .
1038 
-      C:    RETR 1
1039 
-      S:    +OK 120 octets
1040 
-      S:    &#60;the POP3 server sends message 1&#62;
1041 
-      S:    .
1042 
-      C:    DELE 1
1043 
-      S:    +OK message 1 deleted
1044 
-      C:    RETR 2
1045 
-      S:    +OK 200 octets
1046 
-      S:    &#60;the POP3 server sends message 2&#62;
1047 
-      S:    .
1048 
-      C:    DELE 2
1049 
-      S:    +OK message 2 deleted
1050 
-      C:    QUIT
1051 
-      S:    +OK dewey POP3 server signing off (maildrop empty)
1052 
-      C:  &#60;close connection&#62;
1053 
-      S:  &#60;wait for next connection&#62;
1054 
-
1055 
-11. Message Format
1056 
-
1057 
-   All messages transmitted during a POP3 session are assumed to conform
1058 
-   to the standard for the format of Internet text messages [RFC<A NAME=id2107 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html">822</A>].
1059 
-
1060 
-   It is important to note that the octet count for a message on the
1061 
-   server host may differ from the octet count assigned to that message
1062 
-   due to local conventions for designating end-of-line.  Usually,
1063 
-   during the AUTHORIZATION state of the POP3 session, the POP3 server
1064 
-   can calculate the size of each message in octets when it opens the
1065 
-   maildrop.  For example, if the POP3 server host internally represents
1066 
-   end-of-line as a single character, then the POP3 server simply counts
1067 
-   each occurrence of this character in a message as two octets.  Note
1068 
-   that lines in the message which start with the termination octet need
1069 
-   not (and must not) be counted twice, since the POP3 client will
1070 
-   remove all byte-stuffed termination characters when it receives a
1071 
-   multi-line response.
1072 
-
1073 
-
1074 
-
1075 
-Myers &#38; Rose                Standards Track                    [Page 19]
1076 
-
1077 
-RFC <A NAME=id2145 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
1078 
-
1079 
-
1080 
-12. References
1081 
-
1082 
-   [RFC<A NAME=id2156 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc821.html">821</A>] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
1083 
-       821, USC/Information Sciences Institute, August 1982.
1084 
-
1085 
-   [RFC<A NAME=id2163 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html">822</A>] Crocker, D., "Standard for the Format of ARPA-Internet Text
1086 
-       Messages", STD 11, RFC <A NAME=id2166 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html">822</A>, University of Delaware, August 1982.
1087 
-
1088 
-   [RFC<A NAME=id2172 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1321.html">1321</A>] Rivest, R., "The MD5 Message-Digest Algorithm", RFC <A NAME=id2171 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1321.html">1321</A>,
1089 
-       MIT Laboratory for Computer Science, April 1992.
1090 
-
1091 
-   [RFC<A NAME=id2179 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1730.html">1730</A>] Crispin, M., "Internet Message Access Protocol - Version
1092 
-       4", RFC <A NAME=id2182 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1730.html">1730</A>, University of Washington, December 1994.
1093 
-
1094 
-   [RFC<A NAME=id2188 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1734.html">1734</A>] Myers, J., "POP3 AUTHentication command", RFC <A NAME=id2187 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1734.html">1734</A>,
1095 
-       Carnegie Mellon, December 1994.
1096 
-
1097 
-13. Security Considerations
1098 
-
1099 
-   It is conjectured that use of the APOP command provides origin
1100 
-   identification and replay protection for a POP3 session.
1101 
-   Accordingly, a POP3 server which implements both the PASS and APOP
1102 
-   commands should not allow both methods of access for a given user;
1103 
-   that is, for a given mailbox name, either the USER/PASS command
1104 
-   sequence or the APOP command is allowed, but not both.
1105 
-
1106 
-   Further, note that as the length of the shared secret increases, so
1107 
-   does the difficulty of deriving it.
1108 
-
1109 
-   Servers that answer -ERR to the USER command are giving potential
1110 
-   attackers clues about which names are valid.
1111 
-
1112 
-   Use of the PASS command sends passwords in the clear over the
1113 
-   network.
1114 
-
1115 
-   Use of the RETR and TOP commands sends mail in the clear over the
1116 
-   network.
1117 
-
1118 
-   Otherwise, security issues are not discussed in this memo.
1119 
-
1120 
-14. Acknowledgements
1121 
-
1122 
-   The POP family has a long and checkered history.  Although primarily
1123 
-   a minor revision to RFC <A NAME=id2247 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1460.html">1460</A>, POP3 is based on the ideas presented in
1124 
-   RFCs 918, 937, and 1081.
1125 
-
1126 
-   In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
1127 
-   provided significant comments on the APOP command.
1128 
-
1129 
-
1130 
-
1131 
-Myers &#38; Rose                Standards Track                    [Page 20]
1132 
-
1133 
-RFC <A NAME=id2267 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
1134 
-
1135 
-
1136 
-15. Authors' Addresses
1137 
-
1138 
-   John G. Myers
1139 
-   Carnegie-Mellon University
1140 
-   5000 Forbes Ave
1141 
-   Pittsburgh, PA 15213
1142 
-
1143 
-   EMail: jgm+@cmu.edu
1144 
-
1145 
-
1146 
-   Marshall T. Rose
1147 
-   Dover Beach Consulting, Inc.
1148 
-   420 Whisman Court
1149 
-   Mountain View, CA  94043-2186
1150 
-
1151 
-   EMail: mrose@dbc.mtview.ca.us
1152 
-
1153 
-
1154 
-
1155 
-
1156 
-
1157 
-
1158 
-
1159 
-
1160 
-
1161 
-
1162 
-
1163 
-
1164 
-
1165 
-
1166 
-
1167 
-
1168 
-
1169 
-
1170 
-
1171 
-
1172 
-
1173 
-
1174 
-
1175 
-
1176 
-
1177 
-
1178 
-
1179 
-
1180 
-
1181 
-
1182 
-
1183 
-
1184 
-
1185 
-
1186 
-
1187 
-Myers &#38; Rose                Standards Track                    [Page 21]
1188 
-
1189 
-RFC <A NAME=id2379 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
1190 
-
1191 
-
1192 
-Appendix A. Differences from RFC <A NAME=id2386 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1725.html">1725</A>
1193 
-
1194 
-   This memo is a revision to RFC <A NAME=id2391 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1725.html">1725</A>, a Draft Standard.  It makes the
1195 
-   following changes from that document:
1196 
-
1197 
-      - clarifies that command keywords are case insensitive.
1198 
-
1199 
-      - specifies that servers must send "+OK" and "-ERR" in
1200 
-        upper case.
1201 
-
1202 
-      - specifies that the initial greeting is a positive response,
1203 
-        instead of any string which should be a positive response.
1204 
-
1205 
-      - clarifies behavior for unimplemented commands.
1206 
-
1207 
-      - makes the USER and PASS commands optional.
1208 
-
1209 
-      - clarified the set of possible responses to the USER command.
1210 
-
1211 
-      - reverses the order of the examples in the USER and PASS
1212 
-        commands, to reduce confusion.
1213 
-
1214 
-      - clarifies that the PASS command may only be given immediately
1215 
-        after a successful USER command.
1216 
-
1217 
-      - clarified the persistence requirements of UIDs and added some
1218 
-        implementation notes.
1219 
-
1220 
-      - specifies a UID length limitation of one to 70 octets.
1221 
-
1222 
-      - specifies a status indicator length limitation
1223 
-        of 512 octets, including the CRLF.
1224 
-
1225 
-      - clarifies that LIST with no arguments on an empty mailbox
1226 
-        returns success.
1227 
-
1228 
-      - adds a reference from the LIST command to the Message Format
1229 
-        section
1230 
-
1231 
-      - clarifies the behavior of QUIT upon failure
1232 
-
1233 
-      - clarifies the security section to not imply the use of the
1234 
-        USER command with the APOP command.
1235 
-
1236 
-      - adds references to RFCs 1730 and 1734
1237 
-
1238 
-      - clarifies the method by which a UA may enter mail into the
1239 
-        transport system.
1240 
-
1241 
-
1242 
-
1243 
-Myers &#38; Rose                Standards Track                    [Page 22]
1244 
-
1245 
-RFC <A NAME=id2493 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
1246 
-
1247 
-
1248 
-      - clarifies that the second argument to the TOP command is a
1249 
-        number of lines.
1250 
-
1251 
-      - changes the suggestion in the Security Considerations section
1252 
-        for a server to not accept both PASS and APOP for a given user
1253 
-        from a "must" to a "should".
1254 
-
1255 
-      - adds a section on scaling and operational considerations
1256 
-
1257 
-Appendix B. Command Index
1258 
-
1259 
-       APOP .......................................................   15
1260 
-       DELE .......................................................    8
1261 
-       LIST .......................................................    6
1262 
-       NOOP .......................................................    9
1263 
-       PASS .......................................................   14
1264 
-       QUIT .......................................................    5
1265 
-       QUIT .......................................................   10
1266 
-       RETR .......................................................    8
1267 
-       RSET .......................................................    9
1268 
-       STAT .......................................................    6
1269 
-       TOP ........................................................   11
1270 
-       UIDL .......................................................   12
1271 
-       USER .......................................................   13
1272 
-
1273 
-
1274 
-
1275 
-
1276 
-
1277 
-
1278 
-
1279 
-
1280 
-
1281 
-
1282 
-
1283 
-
1284 
-
1285 
-
1286 
-
1287 
-
1288 
-
1289 
-
1290 
-
1291 
-
1292 
-
1293 
-
1294 
-
1295 
-
1296 
-
1297 
-
1298 
-
1299 
-Myers &#38; Rose                Standards Track                    [Page 23]
1300 
-
1301 
-</PRE>
1302 
-</BODY>
1303 
-</HTML>
1 
+<HEAD>
2 
+<TITLE>rfc1939</TITLE>
3 
+</HEAD>
4 
+
5 
+<H1>rfc1939</H1>
6 
+Press <A NAME=id1 HREF="http://www.cis.ohio-state.edu/hypertext/information/rfc.html">here</A>
7 
+to go to the top of the rfc 'tree'.<p>
8 
+
9 
+<PRE>
10 
+
11 
+
12 
+
13 
+
14 
+
15 
+
16 
+Network Working Group                                           J. Myers
17 
+Request for Comments: <A NAME=id18 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                               Carnegie Mellon
18 
+STD: 53                                                          M. Rose
19 
+Obsoletes: <A NAME=id22 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1725.html">1725</A>                             Dover Beach Consulting, Inc.
20 
+Category: Standards Track                                       May <A NAME=id24 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1996.html">1996</A>
21 
+
22 
+
23 
+                    Post Office Protocol - Version 3
24 
+
25 
+Status of this Memo
26 
+
27 
+   This document specifies an Internet standards track protocol for the
28 
+   Internet community, and requests discussion and suggestions for
29 
+   improvements.  Please refer to the current edition of the "Internet
30 
+   Official Protocol Standards" (STD 1) for the standardization state
31 
+   and status of this protocol.  Distribution of this memo is unlimited.
32 
+
33 
+Table of Contents
34 
+
35 
+   1. Introduction ................................................    2
36 
+   2. A Short Digression ..........................................    2
37 
+   3. Basic Operation .............................................    3
38 
+   4. The AUTHORIZATION State .....................................    4
39 
+      QUIT Command ................................................    5
40 
+   5. The TRANSACTION State .......................................    5
41 
+      STAT Command ................................................    6
42 
+      LIST Command ................................................    6
43 
+      RETR Command ................................................    8
44 
+      DELE Command ................................................    8
45 
+      NOOP Command ................................................    9
46 
+      RSET Command ................................................    9
47 
+   6. The UPDATE State ............................................   10
48 
+      QUIT Command ................................................   10
49 
+   7. Optional POP3 Commands ......................................   11
50 
+      TOP Command .................................................   11
51 
+      UIDL Command ................................................   12
52 
+      USER Command ................................................   13
53 
+      PASS Command ................................................   14
54 
+      APOP Command ................................................   15
55 
+   8. Scaling and Operational Considerations ......................   16
56 
+   9. POP3 Command Summary ........................................   18
57 
+   10. Example POP3 Session .......................................   19
58 
+   11. Message Format .............................................   19
59 
+   12. References .................................................   20
60 
+   13. Security Considerations ....................................   20
61 
+   14. Acknowledgements ...........................................   20
62 
+   15. Authors' Addresses .........................................   21
63 
+   Appendix A. Differences from RFC <A NAME=id111 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1725.html">1725</A> ..........................   22
64 
+
65 
+
66 
+
67 
+Myers &#38; Rose                Standards Track                     [Page 1]
68 
+
69 
+RFC <A NAME=id123 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
70 
+
71 
+
72 
+   Appendix B. Command Index ......................................   23
73 
+
74 
+1. Introduction
75 
+
76 
+   On certain types of smaller nodes in the Internet it is often
77 
+   impractical to maintain a message transport system (MTS).  For
78 
+   example, a workstation may not have sufficient resources (cycles,
79 
+   disk space) in order to permit a SMTP server [RFC<A NAME=id144 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc821.html">821</A>] and associated
80 
+   local mail delivery system to be kept resident and continuously
81 
+   running.  Similarly, it may be expensive (or impossible) to keep a
82 
+   personal computer interconnected to an IP-style network for long
83 
+   amounts of time (the node is lacking the resource known as
84 
+   "connectivity").
85 
+
86 
+   Despite this, it is often very useful to be able to manage mail on
87 
+   these smaller nodes, and they often support a user agent (UA) to aid
88 
+   the tasks of mail handling.  To solve this problem, a node which can
89 
+   support an MTS entity offers a maildrop service to these less endowed
90 
+   nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
91 
+   permit a workstation to dynamically access a maildrop on a server
92 
+   host in a useful fashion.  Usually, this means that the POP3 protocol
93 
+   is used to allow a workstation to retrieve mail that the server is
94 
+   holding for it.
95 
+
96 
+   POP3 is not intended to provide extensive manipulation operations of
97 
+   mail on the server; normally, mail is downloaded and then deleted.  A
98 
+   more advanced (and complex) protocol, IMAP4, is discussed in
99 
+   [RFC<A NAME=id185 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1730.html">1730</A>].
100 
+
101 
+   For the remainder of this memo, the term "client host" refers to a
102 
+   host making use of the POP3 service, while the term "server host"
103 
+   refers to a host which offers the POP3 service.
104 
+
105 
+2. A Short Digression
106 
+
107 
+   This memo does not specify how a client host enters mail into the
108 
+   transport system, although a method consistent with the philosophy of
109 
+   this memo is presented here:
110 
+
111 
+      When the user agent on a client host wishes to enter a message
112 
+      into the transport system, it establishes an SMTP connection to
113 
+      its relay host and sends all mail to it.  This relay host could
114 
+      be, but need not be, the POP3 server host for the client host.  Of
115 
+      course, the relay host must accept mail for delivery to arbitrary
116 
+      recipient addresses, that functionality is not required of all
117 
+      SMTP servers.
118 
+
119 
+
120 
+
121 
+
122 
+
123 
+Myers &#38; Rose                Standards Track                     [Page 2]
124 
+
125 
+RFC <A NAME=id237 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
126 
+
127 
+
128 
+3. Basic Operation
129 
+
130 
+   Initially, the server host starts the POP3 service by listening on
131 
+   TCP port 110.  When a client host wishes to make use of the service,
132 
+   it establishes a TCP connection with the server host.  When the
133 
+   connection is established, the POP3 server sends a greeting.  The
134 
+   client and POP3 server then exchange commands and responses
135 
+   (respectively) until the connection is closed or aborted.
136 
+
137 
+   Commands in the POP3 consist of a case-insensitive keyword, possibly
138 
+   followed by one or more arguments.  All commands are terminated by a
139 
+   CRLF pair.  Keywords and arguments consist of printable ASCII
140 
+   characters.  Keywords and arguments are each separated by a single
141 
+   SPACE character.  Keywords are three or four characters long. Each
142 
+   argument may be up to 40 characters long.
143 
+
144 
+   Responses in the POP3 consist of a status indicator and a keyword
145 
+   possibly followed by additional information.  All responses are
146 
+   terminated by a CRLF pair.  Responses may be up to 512 characters
147 
+   long, including the terminating CRLF.  There are currently two status
148 
+   indicators: positive ("+OK") and negative ("-ERR").  Servers MUST
149 
+   send the "+OK" and "-ERR" in upper case.
150 
+
151 
+   Responses to certain commands are multi-line.  In these cases, which
152 
+   are clearly indicated below, after sending the first line of the
153 
+   response and a CRLF, any additional lines are sent, each terminated
154 
+   by a CRLF pair.  When all lines of the response have been sent, a
155 
+   final line is sent, consisting of a termination octet (decimal code
156 
+   046, ".") and a CRLF pair.  If any line of the multi-line response
157 
+   begins with the termination octet, the line is "byte-stuffed" by
158 
+   pre-pending the termination octet to that line of the response.
159 
+   Hence a multi-line response is terminated with the five octets
160 
+   "CRLF.CRLF".  When examining a multi-line response, the client checks
161 
+   to see if the line begins with the termination octet.  If so and if
162 
+   octets other than CRLF follow, the first octet of the line (the
163 
+   termination octet) is stripped away.  If so and if CRLF immediately
164 
+   follows the termination character, then the response from the POP
165 
+   server is ended and the line containing ".CRLF" is not considered
166 
+   part of the multi-line response.
167 
+
168 
+   A POP3 session progresses through a number of states during its
169 
+   lifetime.  Once the TCP connection has been opened and the POP3
170 
+   server has sent the greeting, the session enters the AUTHORIZATION
171 
+   state.  In this state, the client must identify itself to the POP3
172 
+   server.  Once the client has successfully done this, the server
173 
+   acquires resources associated with the client's maildrop, and the
174 
+   session enters the TRANSACTION state.  In this state, the client
175 
+   requests actions on the part of the POP3 server.  When the client has
176 
+
177 
+
178 
+
179 
+Myers &#38; Rose                Standards Track                     [Page 3]
180 
+
181 
+RFC <A NAME=id349 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
182 
+
183 
+
184 
+   issued the QUIT command, the session enters the UPDATE state.  In
185 
+   this state, the POP3 server releases any resources acquired during
186 
+   the TRANSACTION state and says goodbye.  The TCP connection is then
187 
+   closed.
188 
+
189 
+   A server MUST respond to an unrecognized, unimplemented, or
190 
+   syntactically invalid command by responding with a negative status
191 
+   indicator.  A server MUST respond to a command issued when the
192 
+   session is in an incorrect state by responding with a negative status
193 
+   indicator.  There is no general method for a client to distinguish
194 
+   between a server which does not implement an optional command and a
195 
+   server which is unwilling or unable to process the command.
196 
+
197 
+   A POP3 server MAY have an inactivity autologout timer.  Such a timer
198 
+   MUST be of at least 10 minutes' duration.  The receipt of any command
199 
+   from the client during that interval should suffice to reset the
200 
+   autologout timer.  When the timer expires, the session does NOT enter
201 
+   the UPDATE state--the server should close the TCP connection without
202 
+   removing any messages or sending any response to the client.
203 
+
204 
+4. The AUTHORIZATION State
205 
+
206 
+   Once the TCP connection has been opened by a POP3 client, the POP3
207 
+   server issues a one line greeting.  This can be any positive
208 
+   response.  An example might be:
209 
+
210 
+      S:  +OK POP3 server ready
211 
+
212 
+   The POP3 session is now in the AUTHORIZATION state.  The client must
213 
+   now identify and authenticate itself to the POP3 server.  Two
214 
+   possible mechanisms for doing this are described in this document,
215 
+   the USER and PASS command combination and the APOP command.  Both
216 
+   mechanisms are described later in this document.  Additional
217 
+   authentication mechanisms are described in [RFC<A NAME=id422 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1734.html">1734</A>].  While there is
218 
+   no single authentication mechanism that is required of all POP3
219 
+   servers, a POP3 server must of course support at least one
220 
+   authentication mechanism.
221 
+
222 
+   Once the POP3 server has determined through the use of any
223 
+   authentication command that the client should be given access to the
224 
+   appropriate maildrop, the POP3 server then acquires an exclusive-
225 
+   access lock on the maildrop, as necessary to prevent messages from
226 
+   being modified or removed before the session enters the UPDATE state.
227 
+   If the lock is successfully acquired, the POP3 server responds with a
228 
+   positive status indicator.  The POP3 session now enters the
229 
+   TRANSACTION state, with no messages marked as deleted.  If the
230 
+   maildrop cannot be opened for some reason (for example, a lock can
231 
+   not be acquired, the client is denied access to the appropriate
232 
+
233 
+
234 
+
235 
+Myers &#38; Rose                Standards Track                     [Page 4]
236 
+
237 
+RFC <A NAME=id462 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
238 
+
239 
+
240 
+   maildrop, or the maildrop cannot be parsed), the POP3 server responds
241 
+   with a negative status indicator.  (If a lock was acquired but the
242 
+   POP3 server intends to respond with a negative status indicator, the
243 
+   POP3 server must release the lock prior to rejecting the command.)
244 
+   After returning a negative status indicator, the server may close the
245 
+   connection.  If the server does not close the connection, the client
246 
+   may either issue a new authentication command and start again, or the
247 
+   client may issue the QUIT command.
248 
+
249 
+   After the POP3 server has opened the maildrop, it assigns a message-
250 
+   number to each message, and notes the size of each message in octets.
251 
+   The first message in the maildrop is assigned a message-number of
252 
+   "1", the second is assigned "2", and so on, so that the nth message
253 
+   in a maildrop is assigned a message-number of "n".  In POP3 commands
254 
+   and responses, all message-numbers and message sizes are expressed in
255 
+   base-10 (i.e., decimal).
256 
+
257 
+   Here is the summary for the QUIT command when used in the
258 
+   AUTHORIZATION state:
259 
+
260 
+      QUIT
261 
+
262 
+         Arguments: none
263 
+
264 
+         Restrictions: none
265 
+
266 
+         Possible Responses:
267 
+             +OK
268 
+
269 
+         Examples:
270 
+             C: QUIT
271 
+             S: +OK dewey POP3 server signing off
272 
+
273 
+5. The TRANSACTION State
274 
+
275 
+   Once the client has successfully identified itself to the POP3 server
276 
+   and the POP3 server has locked and opened the appropriate maildrop,
277 
+   the POP3 session is now in the TRANSACTION state.  The client may now
278 
+   issue any of the following POP3 commands repeatedly.  After each
279 
+   command, the POP3 server issues a response.  Eventually, the client
280 
+   issues the QUIT command and the POP3 session enters the UPDATE state.
281 
+
282 
+
283 
+
284 
+
285 
+
286 
+
287 
+
288 
+
289 
+
290 
+
291 
+Myers &#38; Rose                Standards Track                     [Page 5]
292 
+
293 
+RFC <A NAME=id574 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
294 
+
295 
+
296 
+   Here are the POP3 commands valid in the TRANSACTION state:
297 
+
298 
+      STAT
299 
+
300 
+         Arguments: none
301 
+
302 
+         Restrictions:
303 
+             may only be given in the TRANSACTION state
304 
+
305 
+         Discussion:
306 
+             The POP3 server issues a positive response with a line
307 
+             containing information for the maildrop.  This line is
308 
+             called a "drop listing" for that maildrop.
309 
+
310 
+             In order to simplify parsing, all POP3 servers are
311 
+             required to use a certain format for drop listings.  The
312 
+             positive response consists of "+OK" followed by a single
313 
+             space, the number of messages in the maildrop, a single
314 
+             space, and the size of the maildrop in octets.  This memo
315 
+             makes no requirement on what follows the maildrop size.
316 
+             Minimal implementations should just end that line of the
317 
+             response with a CRLF pair.  More advanced implementations
318 
+             may include other information.
319 
+
320 
+                NOTE: This memo STRONGLY discourages implementations
321 
+                from supplying additional information in the drop
322 
+                listing.  Other, optional, facilities are discussed
323 
+                later on which permit the client to parse the messages
324 
+                in the maildrop.
325 
+
326 
+             Note that messages marked as deleted are not counted in
327 
+             either total.
328 
+
329 
+         Possible Responses:
330 
+             +OK nn mm
331 
+
332 
+         Examples:
333 
+             C: STAT
334 
+             S: +OK 2 320
335 
+
336 
+
337 
+      LIST [msg]
338 
+
339 
+         Arguments:
340 
+             a message-number (optional), which, if present, may NOT
341 
+             refer to a message marked as deleted
342 
+
343 
+
344 
+
345 
+
346 
+
347 
+Myers &#38; Rose                Standards Track                     [Page 6]
348 
+
349 
+RFC <A NAME=id686 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
350 
+
351 
+
352 
+         Restrictions:
353 
+             may only be given in the TRANSACTION state
354 
+
355 
+         Discussion:
356 
+             If an argument was given and the POP3 server issues a
357 
+             positive response with a line containing information for
358 
+             that message.  This line is called a "scan listing" for
359 
+             that message.
360 
+
361 
+             If no argument was given and the POP3 server issues a
362 
+             positive response, then the response given is multi-line.
363 
+             After the initial +OK, for each message in the maildrop,
364 
+             the POP3 server responds with a line containing
365 
+             information for that message.  This line is also called a
366 
+             "scan listing" for that message.  If there are no
367 
+             messages in the maildrop, then the POP3 server responds
368 
+             with no scan listings--it issues a positive response
369 
+             followed by a line containing a termination octet and a
370 
+             CRLF pair.
371 
+
372 
+             In order to simplify parsing, all POP3 servers are
373 
+             required to use a certain format for scan listings.  A
374 
+             scan listing consists of the message-number of the
375 
+             message, followed by a single space and the exact size of
376 
+             the message in octets.  Methods for calculating the exact
377 
+             size of the message are described in the "Message Format"
378 
+             section below.  This memo makes no requirement on what
379 
+             follows the message size in the scan listing.  Minimal
380 
+             implementations should just end that line of the response
381 
+             with a CRLF pair.  More advanced implementations may
382 
+             include other information, as parsed from the message.
383 
+
384 
+                NOTE: This memo STRONGLY discourages implementations
385 
+                from supplying additional information in the scan
386 
+                listing.  Other, optional, facilities are discussed
387 
+                later on which permit the client to parse the messages
388 
+                in the maildrop.
389 
+
390 
+             Note that messages marked as deleted are not listed.
391 
+
392 
+         Possible Responses:
393 
+             +OK scan listing follows
394 
+             -ERR no such message
395 
+
396 
+         Examples:
397 
+             C: LIST
398 
+             S: +OK 2 messages (320 octets)
399 
+             S: 1 120
400 
+
401 
+
402 
+
403 
+Myers &#38; Rose                Standards Track                     [Page 7]
404 
+
405 
+RFC <A NAME=id798 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
406 
+
407 
+
408 
+             S: 2 200
409 
+             S: .
410 
+               ...
411 
+             C: LIST 2
412 
+             S: +OK 2 200
413 
+               ...
414 
+             C: LIST 3
415 
+             S: -ERR no such message, only 2 messages in maildrop
416 
+
417 
+
418 
+      RETR msg
419 
+
420 
+         Arguments:
421 
+             a message-number (required) which may NOT refer to a
422 
+             message marked as deleted
423 
+
424 
+         Restrictions:
425 
+             may only be given in the TRANSACTION state
426 
+
427 
+         Discussion:
428 
+             If the POP3 server issues a positive response, then the
429 
+             response given is multi-line.  After the initial +OK, the
430 
+             POP3 server sends the message corresponding to the given
431 
+             message-number, being careful to byte-stuff the termination
432 
+             character (as with all multi-line responses).
433 
+
434 
+         Possible Responses:
435 
+             +OK message follows
436 
+             -ERR no such message
437 
+
438 
+         Examples:
439 
+             C: RETR 1
440 
+             S: +OK 120 octets
441 
+             S: &#60;the POP3 server sends the entire message here&#62;
442 
+             S: .
443 
+
444 
+
445 
+      DELE msg
446 
+
447 
+         Arguments:
448 
+             a message-number (required) which may NOT refer to a
449 
+             message marked as deleted
450 
+
451 
+         Restrictions:
452 
+             may only be given in the TRANSACTION state
453 
+
454 
+
455 
+
456 
+
457 
+
458 
+
459 
+Myers &#38; Rose                Standards Track                     [Page 8]
460 
+
461 
+RFC <A NAME=id910 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
462 
+
463 
+
464 
+         Discussion:
465 
+             The POP3 server marks the message as deleted.  Any future
466 
+             reference to the message-number associated with the message
467 
+             in a POP3 command generates an error.  The POP3 server does
468 
+             not actually delete the message until the POP3 session
469 
+             enters the UPDATE state.
470 
+
471 
+         Possible Responses:
472 
+             +OK message deleted
473 
+             -ERR no such message
474 
+
475 
+         Examples:
476 
+             C: DELE 1
477 
+             S: +OK message 1 deleted
478 
+                ...
479 
+             C: DELE 2
480 
+             S: -ERR message 2 already deleted
481 
+
482 
+
483 
+      NOOP
484 
+
485 
+         Arguments: none
486 
+
487 
+         Restrictions:
488 
+             may only be given in the TRANSACTION state
489 
+
490 
+         Discussion:
491 
+             The POP3 server does nothing, it merely replies with a
492 
+             positive response.
493 
+
494 
+         Possible Responses:
495 
+             +OK
496 
+
497 
+         Examples:
498 
+             C: NOOP
499 
+             S: +OK
500 
+
501 
+
502 
+      RSET
503 
+
504 
+         Arguments: none
505 
+
506 
+         Restrictions:
507 
+             may only be given in the TRANSACTION state
508 
+
509 
+         Discussion:
510 
+             If any messages have been marked as deleted by the POP3
511 
+             server, they are unmarked.  The POP3 server then replies
512 
+
513 
+
514 
+
515 
+Myers &#38; Rose                Standards Track                     [Page 9]
516 
+
517 
+RFC <A NAME=id1022 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
518 
+
519 
+
520 
+             with a positive response.
521 
+
522 
+         Possible Responses:
523 
+             +OK
524 
+
525 
+         Examples:
526 
+             C: RSET
527 
+             S: +OK maildrop has 2 messages (320 octets)
528 
+
529 
+6. The UPDATE State
530 
+
531 
+   When the client issues the QUIT command from the TRANSACTION state,
532 
+   the POP3 session enters the UPDATE state.  (Note that if the client
533 
+   issues the QUIT command from the AUTHORIZATION state, the POP3
534 
+   session terminates but does NOT enter the UPDATE state.)
535 
+
536 
+   If a session terminates for some reason other than a client-issued
537 
+   QUIT command, the POP3 session does NOT enter the UPDATE state and
538 
+   MUST not remove any messages from the maildrop.
539 
+
540 
+      QUIT
541 
+
542 
+         Arguments: none
543 
+
544 
+         Restrictions: none
545 
+
546 
+         Discussion:
547 
+             The POP3 server removes all messages marked as deleted
548 
+             from the maildrop and replies as to the status of this
549 
+             operation.  If there is an error, such as a resource
550 
+             shortage, encountered while removing messages, the
551 
+             maildrop may result in having some or none of the messages
552 
+             marked as deleted be removed.  In no case may the server
553 
+             remove any messages not marked as deleted.
554 
+
555 
+             Whether the removal was successful or not, the server
556 
+             then releases any exclusive-access lock on the maildrop
557 
+             and closes the TCP connection.
558 
+
559 
+         Possible Responses:
560 
+             +OK
561 
+             -ERR some deleted messages not removed
562 
+
563 
+         Examples:
564 
+             C: QUIT
565 
+             S: +OK dewey POP3 server signing off (maildrop empty)
566 
+                ...
567 
+             C: QUIT
568 
+
569 
+
570 
+
571 
+Myers &#38; Rose                Standards Track                    [Page 10]
572 
+
573 
+RFC <A NAME=id1134 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
574 
+
575 
+
576 
+             S: +OK dewey POP3 server signing off (2 messages left)
577 
+                ...
578 
+
579 
+7. Optional POP3 Commands
580 
+
581 
+   The POP3 commands discussed above must be supported by all minimal
582 
+   implementations of POP3 servers.
583 
+
584 
+   The optional POP3 commands described below permit a POP3 client
585 
+   greater freedom in message handling, while preserving a simple POP3
586 
+   server implementation.
587 
+
588 
+      NOTE: This memo STRONGLY encourages implementations to support
589 
+      these commands in lieu of developing augmented drop and scan
590 
+      listings.  In short, the philosophy of this memo is to put
591 
+      intelligence in the part of the POP3 client and not the POP3
592 
+      server.
593 
+
594 
+      TOP msg n
595 
+
596 
+         Arguments:
597 
+             a message-number (required) which may NOT refer to to a
598 
+             message marked as deleted, and a non-negative number
599 
+             of lines (required)
600 
+
601 
+         Restrictions:
602 
+             may only be given in the TRANSACTION state
603 
+
604 
+         Discussion:
605 
+             If the POP3 server issues a positive response, then the
606 
+             response given is multi-line.  After the initial +OK, the
607 
+             POP3 server sends the headers of the message, the blank
608 
+             line separating the headers from the body, and then the
609 
+             number of lines of the indicated message's body, being
610 
+             careful to byte-stuff the termination character (as with
611 
+             all multi-line responses).
612 
+
613 
+             Note that if the number of lines requested by the POP3
614 
+             client is greater than than the number of lines in the
615 
+             body, then the POP3 server sends the entire message.
616 
+
617 
+         Possible Responses:
618 
+             +OK top of message follows
619 
+             -ERR no such message
620 
+
621 
+         Examples:
622 
+             C: TOP 1 10
623 
+             S: +OK
624 
+
625 
+
626 
+
627 
+Myers &#38; Rose                Standards Track                    [Page 11]
628 
+
629 
+RFC <A NAME=id1246 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
630 
+
631 
+
632 
+             S: &#60;the POP3 server sends the headers of the
633 
+                message, a blank line, and the first 10 lines
634 
+                of the body of the message&#62;
635 
+             S: .
636 
+                ...
637 
+             C: TOP 100 3
638 
+             S: -ERR no such message
639 
+
640 
+
641 
+      UIDL [msg]
642 
+
643 
+      Arguments:
644 
+          a message-number (optional), which, if present, may NOT
645 
+          refer to a message marked as deleted
646 
+
647 
+      Restrictions:
648 
+          may only be given in the TRANSACTION state.
649 
+
650 
+      Discussion:
651 
+          If an argument was given and the POP3 server issues a positive
652 
+          response with a line containing information for that message.
653 
+          This line is called a "unique-id listing" for that message.
654 
+
655 
+          If no argument was given and the POP3 server issues a positive
656 
+          response, then the response given is multi-line.  After the
657 
+          initial +OK, for each message in the maildrop, the POP3 server
658 
+          responds with a line containing information for that message.
659 
+          This line is called a "unique-id listing" for that message.
660 
+
661 
+          In order to simplify parsing, all POP3 servers are required to
662 
+          use a certain format for unique-id listings.  A unique-id
663 
+          listing consists of the message-number of the message,
664 
+          followed by a single space and the unique-id of the message.
665 
+          No information follows the unique-id in the unique-id listing.
666 
+
667 
+          The unique-id of a message is an arbitrary server-determined
668 
+          string, consisting of one to 70 characters in the range 0x21
669 
+          to 0x7E, which uniquely identifies a message within a
670 
+          maildrop and which persists across sessions.  This
671 
+          persistence is required even if a session ends without
672 
+          entering the UPDATE state.  The server should never reuse an
673 
+          unique-id in a given maildrop, for as long as the entity
674 
+          using the unique-id exists.
675 
+
676 
+          Note that messages marked as deleted are not listed.
677 
+
678 
+          While it is generally preferable for server implementations
679 
+          to store arbitrarily assigned unique-ids in the maildrop,
680 
+
681 
+
682 
+
683 
+Myers &#38; Rose                Standards Track                    [Page 12]
684 
+
685 
+RFC <A NAME=id1358 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
686 
+
687 
+
688 
+          this specification is intended to permit unique-ids to be
689 
+          calculated as a hash of the message.  Clients should be able
690 
+          to handle a situation where two identical copies of a
691 
+          message in a maildrop have the same unique-id.
692 
+
693 
+      Possible Responses:
694 
+          +OK unique-id listing follows
695 
+          -ERR no such message
696 
+
697 
+      Examples:
698 
+          C: UIDL
699 
+          S: +OK
700 
+          S: 1 whqtswO00WBw418f9t5JxYwZ
701 
+          S: 2 QhdPYR:00WBw1Ph7x7
702 
+          S: .
703 
+             ...
704 
+          C: UIDL 2
705 
+          S: +OK 2 QhdPYR:00WBw1Ph7x7
706 
+             ...
707 
+          C: UIDL 3
708 
+          S: -ERR no such message, only 2 messages in maildrop
709 
+
710 
+
711 
+      USER name
712 
+
713 
+         Arguments:
714 
+             a string identifying a mailbox (required), which is of
715 
+             significance ONLY to the server
716 
+
717 
+         Restrictions:
718 
+             may only be given in the AUTHORIZATION state after the POP3
719 
+             greeting or after an unsuccessful USER or PASS command
720 
+
721 
+         Discussion:
722 
+             To authenticate using the USER and PASS command
723 
+             combination, the client must first issue the USER
724 
+             command.  If the POP3 server responds with a positive
725 
+             status indicator ("+OK"), then the client may issue
726 
+             either the PASS command to complete the authentication,
727 
+             or the QUIT command to terminate the POP3 session.  If
728 
+             the POP3 server responds with a negative status indicator
729 
+             ("-ERR") to the USER command, then the client may either
730 
+             issue a new authentication command or may issue the QUIT
731 
+             command.
732 
+
733 
+             The server may return a positive response even though no
734 
+             such mailbox exists.  The server may return a negative
735 
+             response if mailbox exists, but does not permit plaintext
736 
+
737 
+
738 
+
739 
+Myers &#38; Rose                Standards Track                    [Page 13]
740 
+
741 
+RFC <A NAME=id1470 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
742 
+
743 
+
744 
+             password authentication.
745 
+
746 
+         Possible Responses:
747 
+             +OK name is a valid mailbox
748 
+             -ERR never heard of mailbox name
749 
+
750 
+         Examples:
751 
+             C: USER frated
752 
+             S: -ERR sorry, no mailbox for frated here
753 
+                ...
754 
+             C: USER mrose
755 
+             S: +OK mrose is a real hoopy frood
756 
+
757 
+
758 
+      PASS string
759 
+
760 
+         Arguments:
761 
+             a server/mailbox-specific password (required)
762 
+
763 
+         Restrictions:
764 
+             may only be given in the AUTHORIZATION state immediately
765 
+             after a successful USER command
766 
+
767 
+         Discussion:
768 
+             When the client issues the PASS command, the POP3 server
769 
+             uses the argument pair from the USER and PASS commands to
770 
+             determine if the client should be given access to the
771 
+             appropriate maildrop.
772 
+
773 
+             Since the PASS command has exactly one argument, a POP3
774 
+             server may treat spaces in the argument as part of the
775 
+             password, instead of as argument separators.
776 
+
777 
+         Possible Responses:
778 
+             +OK maildrop locked and ready
779 
+             -ERR invalid password
780 
+             -ERR unable to lock maildrop
781 
+
782 
+         Examples:
783 
+             C: USER mrose
784 
+             S: +OK mrose is a real hoopy frood
785 
+             C: PASS secret
786 
+             S: -ERR maildrop already locked
787 
+               ...
788 
+             C: USER mrose
789 
+             S: +OK mrose is a real hoopy frood
790 
+             C: PASS secret
791 
+             S: +OK mrose's maildrop has 2 messages (320 octets)
792 
+
793 
+
794 
+
795 
+Myers &#38; Rose                Standards Track                    [Page 14]
796 
+
797 
+RFC <A NAME=id1582 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
798 
+
799 
+
800 
+      APOP name digest
801 
+
802 
+         Arguments:
803 
+             a string identifying a mailbox and a MD5 digest string
804 
+             (both required)
805 
+
806 
+         Restrictions:
807 
+             may only be given in the AUTHORIZATION state after the POP3
808 
+             greeting or after an unsuccessful USER or PASS command
809 
+
810 
+         Discussion:
811 
+             Normally, each POP3 session starts with a USER/PASS
812 
+             exchange.  This results in a server/user-id specific
813 
+             password being sent in the clear on the network.  For
814 
+             intermittent use of POP3, this may not introduce a sizable
815 
+             risk.  However, many POP3 client implementations connect to
816 
+             the POP3 server on a regular basis -- to check for new
817 
+             mail.  Further the interval of session initiation may be on
818 
+             the order of five minutes.  Hence, the risk of password
819 
+             capture is greatly enhanced.
820 
+
821 
+             An alternate method of authentication is required which
822 
+             provides for both origin authentication and replay
823 
+             protection, but which does not involve sending a password
824 
+             in the clear over the network.  The APOP command provides
825 
+             this functionality.
826 
+
827 
+             A POP3 server which implements the APOP command will
828 
+             include a timestamp in its banner greeting.  The syntax of
829 
+             the timestamp corresponds to the `msg-id' in [RFC<A NAME=id1647 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html">822</A>], and
830 
+             MUST be different each time the POP3 server issues a banner
831 
+             greeting.  For example, on a UNIX implementation in which a
832 
+             separate UNIX process is used for each instance of a POP3
833 
+             server, the syntax of the timestamp might be:
834 
+
835 
+                &#60;process-ID.clock@hostname&#62;
836 
+
837 
+             where `process-ID' is the decimal value of the process's
838 
+             PID, clock is the decimal value of the system clock, and
839 
+             hostname is the fully-qualified domain-name corresponding
840 
+             to the host where the POP3 server is running.
841 
+
842 
+             The POP3 client makes note of this timestamp, and then
843 
+             issues the APOP command.  The `name' parameter has
844 
+             identical semantics to the `name' parameter of the USER
845 
+             command. The `digest' parameter is calculated by applying
846 
+             the MD5 algorithm [RFC<A NAME=id1682 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1321.html">1321</A>] to a string consisting of the
847 
+             timestamp (including angle-brackets) followed by a shared
848 
+
849 
+
850 
+
851 
+Myers &#38; Rose                Standards Track                    [Page 15]
852 
+
853 
+RFC <A NAME=id1696 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
854 
+
855 
+
856 
+             secret.  This shared secret is a string known only to the
857 
+             POP3 client and server.  Great care should be taken to
858 
+             prevent unauthorized disclosure of the secret, as knowledge
859 
+             of the secret will allow any entity to successfully
860 
+             masquerade as the named user.  The `digest' parameter
861 
+             itself is a 16-octet value which is sent in hexadecimal
862 
+             format, using lower-case ASCII characters.
863 
+
864 
+             When the POP3 server receives the APOP command, it verifies
865 
+             the digest provided.  If the digest is correct, the POP3
866 
+             server issues a positive response, and the POP3 session
867 
+             enters the TRANSACTION state.  Otherwise, a negative
868 
+             response is issued and the POP3 session remains in the
869 
+             AUTHORIZATION state.
870 
+
871 
+             Note that as the length of the shared secret increases, so
872 
+             does the difficulty of deriving it.  As such, shared
873 
+             secrets should be long strings (considerably longer than
874 
+             the 8-character example shown below).
875 
+
876 
+         Possible Responses:
877 
+             +OK maildrop locked and ready
878 
+             -ERR permission denied
879 
+
880 
+         Examples:
881 
+             S: +OK POP3 server ready &#60;1896.697170952@dbc.mtview.ca.us&#62;
882 
+             C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
883 
+             S: +OK maildrop has 1 message (369 octets)
884 
+
885 
+             In this example, the shared  secret  is  the  string  `tan-
886 
+             staaf'.  Hence, the MD5 algorithm is applied to the string
887 
+
888 
+                &#60;1896.697170952@dbc.mtview.ca.us&#62;tanstaaf
889 
+
890 
+             which produces a digest value of
891 
+
892 
+                c4c9334bac560ecc979e58001b3e22fb
893 
+
894 
+8. Scaling and Operational Considerations
895 
+
896 
+   Since some of the optional features described above were added to the
897 
+   POP3 protocol, experience has accumulated in using them in large-
898 
+   scale commercial post office operations where most of the users are
899 
+   unrelated to each other.  In these situations and others, users and
900 
+   vendors of POP3 clients have discovered that the combination of using
901 
+   the UIDL command and not issuing the DELE command can provide a weak
902 
+   version of the "maildrop as semi-permanent repository" functionality
903 
+   normally associated with IMAP.  Of course the other capabilities of
904 
+
905 
+
906 
+
907 
+Myers &#38; Rose                Standards Track                    [Page 16]
908 
+
909 
+RFC <A NAME=id1808 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
910 
+
911 
+
912 
+   IMAP, such as polling an existing connection for newly arrived
913 
+   messages and supporting multiple folders on the server, are not
914 
+   present in POP3.
915 
+
916 
+   When these facilities are used in this way by casual users, there has
917 
+   been a tendency for already-read messages to accumulate on the server
918 
+   without bound.  This is clearly an undesirable behavior pattern from
919 
+   the standpoint of the server operator.  This situation is aggravated
920 
+   by the fact that the limited capabilities of the POP3 do not permit
921 
+   efficient handling of maildrops which have hundreds or thousands of
922 
+   messages.
923 
+
924 
+   Consequently, it is recommended that operators of large-scale multi-
925 
+   user servers, especially ones in which the user's only access to the
926 
+   maildrop is via POP3, consider such options as:
927 
+
928 
+   *  Imposing a per-user maildrop storage quota or the like.
929 
+
930 
+      A disadvantage to this option is that accumulation of messages may
931 
+      result in the user's inability to receive new ones into the
932 
+      maildrop.  Sites which choose this option should be sure to inform
933 
+      users of impending or current exhaustion of quota, perhaps by
934 
+      inserting an appropriate message into the user's maildrop.
935 
+
936 
+   *  Enforce a site policy regarding mail retention on the server.
937 
+
938 
+      Sites are free to establish local policy regarding the storage and
939 
+      retention of messages on the server, both read and unread.  For
940 
+      example, a site might delete unread messages from the server after
941 
+      60 days and delete read messages after 7 days.  Such message
942 
+      deletions are outside the scope of the POP3 protocol and are not
943 
+      considered a protocol violation.
944 
+
945 
+      Server operators enforcing message deletion policies should take
946 
+      care to make all users aware of the policies in force.
947 
+
948 
+      Clients must not assume that a site policy will automate message
949 
+      deletions, and should continue to explicitly delete messages using
950 
+      the DELE command when appropriate.
951 
+
952 
+      It should be noted that enforcing site message deletion policies
953 
+      may be confusing to the user community, since their POP3 client
954 
+      may contain configuration options to leave mail on the server
955 
+      which will not in fact be supported by the server.
956 
+
957 
+      One special case of a site policy is that messages may only be
958 
+      downloaded once from the server, and are deleted after this has
959 
+      been accomplished.  This could be implemented in POP3 server
960 
+
961 
+
962 
+
963 
+Myers &#38; Rose                Standards Track                    [Page 17]
964 
+
965 
+RFC <A NAME=id1920 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
966 
+
967 
+
968 
+      software by the following mechanism: "following a POP3 login by a
969 
+      client which was ended by a QUIT, delete all messages downloaded
970 
+      during the session with the RETR command".  It is important not to
971 
+      delete messages in the event of abnormal connection termination
972 
+      (ie, if no QUIT was received from the client) because the client
973 
+      may not have successfully received or stored the messages.
974 
+      Servers implementing a download-and-delete policy may also wish to
975 
+      disable or limit the optional TOP command, since it could be used
976 
+      as an alternate mechanism to download entire messages.
977 
+
978 
+9. POP3 Command Summary
979 
+
980 
+      Minimal POP3 Commands:
981 
+
982 
+         USER name               valid in the AUTHORIZATION state
983 
+         PASS string
984 
+         QUIT
985 
+
986 
+         STAT                    valid in the TRANSACTION state
987 
+         LIST [msg]
988 
+         RETR msg
989 
+         DELE msg
990 
+         NOOP
991 
+         RSET
992 
+         QUIT
993 
+
994 
+      Optional POP3 Commands:
995 
+
996 
+         APOP name digest        valid in the AUTHORIZATION state
997 
+
998 
+         TOP msg n               valid in the TRANSACTION state
999 
+         UIDL [msg]
1000 
+
1001 
+      POP3 Replies:
1002 
+
1003 
+         +OK
1004 
+         -ERR
1005 
+
1006 
+      Note that with the exception of the STAT, LIST, and UIDL commands,
1007 
+      the reply given by the POP3 server to any command is significant
1008 
+      only to "+OK" and "-ERR".  Any text occurring after this reply
1009 
+      may be ignored by the client.
1010 
+
1011 
+
1012 
+
1013 
+
1014 
+
1015 
+
1016 
+
1017 
+
1018 
+
1019 
+Myers &#38; Rose                Standards Track                    [Page 18]
1020 
+
1021 
+RFC <A NAME=id2032 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
1022 
+
1023 
+
1024 
+10. Example POP3 Session
1025 
+
1026 
+      S: &#60;wait for connection on TCP port 110&#62;
1027 
+      C: &#60;open connection&#62;
1028 
+      S:    +OK POP3 server ready &#60;1896.697170952@dbc.mtview.ca.us&#62;
1029 
+      C:    APOP mrose c4c9334bac560ecc979e58001b3e22fb
1030 
+      S:    +OK mrose's maildrop has 2 messages (320 octets)
1031 
+      C:    STAT
1032 
+      S:    +OK 2 320
1033 
+      C:    LIST
1034 
+      S:    +OK 2 messages (320 octets)
1035 
+      S:    1 120
1036 
+      S:    2 200
1037 
+      S:    .
1038 
+      C:    RETR 1
1039 
+      S:    +OK 120 octets
1040 
+      S:    &#60;the POP3 server sends message 1&#62;
1041 
+      S:    .
1042 
+      C:    DELE 1
1043 
+      S:    +OK message 1 deleted
1044 
+      C:    RETR 2
1045 
+      S:    +OK 200 octets
1046 
+      S:    &#60;the POP3 server sends message 2&#62;
1047 
+      S:    .
1048 
+      C:    DELE 2
1049 
+      S:    +OK message 2 deleted
1050 
+      C:    QUIT
1051 
+      S:    +OK dewey POP3 server signing off (maildrop empty)
1052 
+      C:  &#60;close connection&#62;
1053 
+      S:  &#60;wait for next connection&#62;
1054 
+
1055 
+11. Message Format
1056 
+
1057 
+   All messages transmitted during a POP3 session are assumed to conform
1058 
+   to the standard for the format of Internet text messages [RFC<A NAME=id2107 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html">822</A>].
1059 
+
1060 
+   It is important to note that the octet count for a message on the
1061 
+   server host may differ from the octet count assigned to that message
1062 
+   due to local conventions for designating end-of-line.  Usually,
1063 
+   during the AUTHORIZATION state of the POP3 session, the POP3 server
1064 
+   can calculate the size of each message in octets when it opens the
1065 
+   maildrop.  For example, if the POP3 server host internally represents
1066 
+   end-of-line as a single character, then the POP3 server simply counts
1067 
+   each occurrence of this character in a message as two octets.  Note
1068 
+   that lines in the message which start with the termination octet need
1069 
+   not (and must not) be counted twice, since the POP3 client will
1070 
+   remove all byte-stuffed termination characters when it receives a
1071 
+   multi-line response.
1072 
+
1073 
+
1074 
+
1075 
+Myers &#38; Rose                Standards Track                    [Page 19]
1076 
+
1077 
+RFC <A NAME=id2145 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
1078 
+
1079 
+
1080 
+12. References
1081 
+
1082 
+   [RFC<A NAME=id2156 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc821.html">821</A>] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
1083 
+       821, USC/Information Sciences Institute, August 1982.
1084 
+
1085 
+   [RFC<A NAME=id2163 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html">822</A>] Crocker, D., "Standard for the Format of ARPA-Internet Text
1086 
+       Messages", STD 11, RFC <A NAME=id2166 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html">822</A>, University of Delaware, August 1982.
1087 
+
1088 
+   [RFC<A NAME=id2172 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1321.html">1321</A>] Rivest, R., "The MD5 Message-Digest Algorithm", RFC <A NAME=id2171 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1321.html">1321</A>,
1089 
+       MIT Laboratory for Computer Science, April 1992.
1090 
+
1091 
+   [RFC<A NAME=id2179 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1730.html">1730</A>] Crispin, M., "Internet Message Access Protocol - Version
1092 
+       4", RFC <A NAME=id2182 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1730.html">1730</A>, University of Washington, December 1994.
1093 
+
1094 
+   [RFC<A NAME=id2188 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1734.html">1734</A>] Myers, J., "POP3 AUTHentication command", RFC <A NAME=id2187 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1734.html">1734</A>,
1095 
+       Carnegie Mellon, December 1994.
1096 
+
1097 
+13. Security Considerations
1098 
+
1099 
+   It is conjectured that use of the APOP command provides origin
1100 
+   identification and replay protection for a POP3 session.
1101 
+   Accordingly, a POP3 server which implements both the PASS and APOP
1102 
+   commands should not allow both methods of access for a given user;
1103 
+   that is, for a given mailbox name, either the USER/PASS command
1104 
+   sequence or the APOP command is allowed, but not both.
1105 
+
1106 
+   Further, note that as the length of the shared secret increases, so
1107 
+   does the difficulty of deriving it.
1108 
+
1109 
+   Servers that answer -ERR to the USER command are giving potential
1110 
+   attackers clues about which names are valid.
1111 
+
1112 
+   Use of the PASS command sends passwords in the clear over the
1113 
+   network.
1114 
+
1115 
+   Use of the RETR and TOP commands sends mail in the clear over the
1116 
+   network.
1117 
+
1118 
+   Otherwise, security issues are not discussed in this memo.
1119 
+
1120 
+14. Acknowledgements
1121 
+
1122 
+   The POP family has a long and checkered history.  Although primarily
1123 
+   a minor revision to RFC <A NAME=id2247 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1460.html">1460</A>, POP3 is based on the ideas presented in
1124 
+   RFCs 918, 937, and 1081.
1125 
+
1126 
+   In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
1127 
+   provided significant comments on the APOP command.
1128 
+
1129 
+
1130 
+
1131 
+Myers &#38; Rose                Standards Track                    [Page 20]
1132 
+
1133 
+RFC <A NAME=id2267 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
1134 
+
1135 
+
1136 
+15. Authors' Addresses
1137 
+
1138 
+   John G. Myers
1139 
+   Carnegie-Mellon University
1140 
+   5000 Forbes Ave
1141 
+   Pittsburgh, PA 15213
1142 
+
1143 
+   EMail: jgm+@cmu.edu
1144 
+
1145 
+
1146 
+   Marshall T. Rose
1147 
+   Dover Beach Consulting, Inc.
1148 
+   420 Whisman Court
1149 
+   Mountain View, CA  94043-2186
1150 
+
1151 
+   EMail: mrose@dbc.mtview.ca.us
1152 
+
1153 
+
1154 
+
1155 
+
1156 
+
1157 
+
1158 
+
1159 
+
1160 
+
1161 
+
1162 
+
1163 
+
1164 
+
1165 
+
1166 
+
1167 
+
1168 
+
1169 
+
1170 
+
1171 
+
1172 
+
1173 
+
1174 
+
1175 
+
1176 
+
1177 
+
1178 
+
1179 
+
1180 
+
1181 
+
1182 
+
1183 
+
1184 
+
1185 
+
1186 
+
1187 
+Myers &#38; Rose                Standards Track                    [Page 21]
1188 
+
1189 
+RFC <A NAME=id2379 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
1190 
+
1191 
+
1192 
+Appendix A. Differences from RFC <A NAME=id2386 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1725.html">1725</A>
1193 
+
1194 
+   This memo is a revision to RFC <A NAME=id2391 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1725.html">1725</A>, a Draft Standard.  It makes the
1195 
+   following changes from that document:
1196 
+
1197 
+      - clarifies that command keywords are case insensitive.
1198 
+
1199 
+      - specifies that servers must send "+OK" and "-ERR" in
1200 
+        upper case.
1201 
+
1202 
+      - specifies that the initial greeting is a positive response,
1203 
+        instead of any string which should be a positive response.
1204 
+
1205 
+      - clarifies behavior for unimplemented commands.
1206 
+
1207 
+      - makes the USER and PASS commands optional.
1208 
+
1209 
+      - clarified the set of possible responses to the USER command.
1210 
+
1211 
+      - reverses the order of the examples in the USER and PASS
1212 
+        commands, to reduce confusion.
1213 
+
1214 
+      - clarifies that the PASS command may only be given immediately
1215 
+        after a successful USER command.
1216 
+
1217 
+      - clarified the persistence requirements of UIDs and added some
1218 
+        implementation notes.
1219 
+
1220 
+      - specifies a UID length limitation of one to 70 octets.
1221 
+
1222 
+      - specifies a status indicator length limitation
1223 
+        of 512 octets, including the CRLF.
1224 
+
1225 
+      - clarifies that LIST with no arguments on an empty mailbox
1226 
+        returns success.
1227 
+
1228 
+      - adds a reference from the LIST command to the Message Format
1229 
+        section
1230 
+
1231 
+      - clarifies the behavior of QUIT upon failure
1232 
+
1233 
+      - clarifies the security section to not imply the use of the
1234 
+        USER command with the APOP command.
1235 
+
1236 
+      - adds references to RFCs 1730 and 1734
1237 
+
1238 
+      - clarifies the method by which a UA may enter mail into the
1239 
+        transport system.
1240 
+
1241 
+
1242 
+
1243 
+Myers &#38; Rose                Standards Track                    [Page 22]
1244 
+
1245 
+RFC <A NAME=id2493 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
1246 
+
1247 
+
1248 
+      - clarifies that the second argument to the TOP command is a
1249 
+        number of lines.
1250 
+
1251 
+      - changes the suggestion in the Security Considerations section
1252 
+        for a server to not accept both PASS and APOP for a given user
1253 
+        from a "must" to a "should".
1254 
+
1255 
+      - adds a section on scaling and operational considerations
1256 
+
1257 
+Appendix B. Command Index
1258 
+
1259 
+       APOP .......................................................   15
1260 
+       DELE .......................................................    8
1261 
+       LIST .......................................................    6
1262 
+       NOOP .......................................................    9
1263 
+       PASS .......................................................   14
1264 
+       QUIT .......................................................    5
1265 
+       QUIT .......................................................   10
1266 
+       RETR .......................................................    8
1267 
+       RSET .......................................................    9
1268 
+       STAT .......................................................    6
1269 
+       TOP ........................................................   11
1270 
+       UIDL .......................................................   12
1271 
+       USER .......................................................   13
1272 
+
1273 
+
1274 
+
1275 
+
1276 
+
1277 
+
1278 
+
1279 
+
1280 
+
1281 
+
1282 
+
1283 
+
1284 
+
1285 
+
1286 
+
1287 
+
1288 
+
1289 
+
1290 
+
1291 
+
1292 
+
1293 
+
1294 
+
1295 
+
1296 
+
1297 
+
1298 
+
1299 
+Myers &#38; Rose                Standards Track                    [Page 23]
1300 
+
1301 
+</PRE>
1302 
+</BODY>
1303 
+</HTML>