Skip to content

John McEleney / mailutils

Go to a project
Toggle navigation
Toggle navigation pinning
Commit 98aaefb7 98aaefb7ae3d117ec50d14a5fe517852e8ae80b5 by Jeff Bailey
Options

Add rfcs to doc directory

1 parent 5f3d0446
Inline Side-by-side
Showing 6 changed files with 2760 additions and 0 deletions
1 1999-11-21 Jeff Bailey <jbailey@nisa.net>
2
3 * doc/rfc*: Add. Standards followed should be included here.
4
1 1999-11-23 Jakob 'sparky' Kaivo <jkaivo@elijah.nodomainname.net> 5 1999-11-23 Jakob 'sparky' Kaivo <jkaivo@elijah.nodomainname.net>
2 6
3 * TODO: Mention Maildir 7 * TODO: Mention Maildir
......
1
2
3
4
5
6
7 Network Working Group J. Myers
8 Request for Comments: 1734 Carnegie Mellon
9 Category: Standards Track December 1994
10
11
12 POP3 AUTHentication command
13
14 Status of this Memo
15
16 This document specifies an Internet standards track protocol for the
17 Internet community, and requests discussion and suggestions for
18 improvements. Please refer to the current edition of the "Internet
19 Official Protocol Standards" (STD 1) for the standardization state
20 and status of this protocol. Distribution of this memo is unlimited.
21
22
23 1. Introduction
24
25 This document describes the optional AUTH command, for indicating an
26 authentication mechanism to the server, performing an authentication
27 protocol exchange, and optionally negotiating a protection mechanism
28 for subsequent protocol interactions. The authentication and
29 protection mechanisms used by the POP3 AUTH command are those used by
30 IMAP4.
31
32
33 2. The AUTH command
34
35 AUTH mechanism
36
37 Arguments:
38 a string identifying an IMAP4 authentication mechanism,
39 such as defined by [IMAP4-AUTH]. Any use of the string
40 "imap" used in a server authentication identity in the
41 definition of an authentication mechanism is replaced with
42 the string "pop".
43
44 Restrictions:
45 may only be given in the AUTHORIZATION state
46
47 Discussion:
48 The AUTH command indicates an authentication mechanism to
49 the server. If the server supports the requested
50 authentication mechanism, it performs an authentication
51 protocol exchange to authenticate and identify the user.
52 Optionally, it also negotiates a protection mechanism for
53 subsequent protocol interactions. If the requested
54 authentication mechanism is not supported, the server
55
56
57
58 Myers [Page 1]
59
60 RFC 1734 POP3 AUTH December 1994
61
62
63 should reject the AUTH command by sending a negative
64 response.
65
66 The authentication protocol exchange consists of a series
67 of server challenges and client answers that are specific
68 to the authentication mechanism. A server challenge,
69 otherwise known as a ready response, is a line consisting
70 of a "+" character followed by a single space and a BASE64
71 encoded string. The client answer consists of a line
72 containing a BASE64 encoded string. If the client wishes
73 to cancel an authentication exchange, it should issue a
74 line with a single "*". If the server receives such an
75 answer, it must reject the AUTH command by sending a
76 negative response.
77
78 A protection mechanism provides integrity and privacy
79 protection to the protocol session. If a protection
80 mechanism is negotiated, it is applied to all subsequent
81 data sent over the connection. The protection mechanism
82 takes effect immediately following the CRLF that concludes
83 the authentication exchange for the client, and the CRLF of
84 the positive response for the server. Once the protection
85 mechanism is in effect, the stream of command and response
86 octets is processed into buffers of ciphertext. Each
87 buffer is transferred over the connection as a stream of
88 octets prepended with a four octet field in network byte
89 order that represents the length of the following data.
90 The maximum ciphertext buffer length is defined by the
91 protection mechanism.
92
93 The server is not required to support any particular
94 authentication mechanism, nor are authentication mechanisms
95 required to support any protection mechanisms. If an AUTH
96 command fails with a negative response, the session remains
97 in the AUTHORIZATION state and client may try another
98 authentication mechanism by issuing another AUTH command,
99 or may attempt to authenticate by using the USER/PASS or
100 APOP commands. In other words, the client may request
101 authentication types in decreasing order of preference,
102 with the USER/PASS or APOP command as a last resort.
103
104 Should the client successfully complete the authentication
105 exchange, the POP3 server issues a positive response and
106 the POP3 session enters the TRANSACTION state.
107
108 Possible Responses:
109 +OK maildrop locked and ready
110 -ERR authentication exchange failed
111
112
113
114 Myers [Page 2]
115
116 RFC 1734 POP3 AUTH December 1994
117
118
119
120 Examples:
121 S: +OK POP3 server ready
122 C: AUTH KERBEROS_V4
123 S: + AmFYig==
124 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
125 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
126 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
127 S: + or//EoAADZI=
128 C: DiAF5A4gA+oOIALuBkAAmw==
129 S: +OK Kerberos V4 authentication successful
130 ...
131 C: AUTH FOOBAR
132 S: -ERR Unrecognized authentication type
133
134 Note: the line breaks in the first client answer are
135 for editorial clarity and are not in real authentica-
136 tors.
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170 Myers [Page 3]
171
172 RFC 1734 POP3 AUTH December 1994
173
174
175 3. Formal Syntax
176
177 The following syntax specification uses the augmented Backus-Naur
178 Form (BNF) notation as specified in RFC 822.
179
180 Except as noted otherwise, all alphabetic characters are case-
181 insensitive. The use of upper or lower case characters to define
182 token strings is for editorial clarity only. Implementations MUST
183 accept these strings in a case-insensitive fashion.
184
185 ATOM_CHAR ::= <any CHAR except atom_specials>
186
187 atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / "%" / "*" /
188 <"> / "\"
189
190 auth ::= "AUTH" 1*(SPACE / TAB) auth_type *(CRLF base64)
191 CRLF
192
193 auth_type ::= 1*ATOM_CHAR
194
195 base64 ::= *(4base64_CHAR) [base64_terminal]
196
197 base64_char ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
198 "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
199 "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
200 "Y" / "Z" /
201 "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
202 "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
203 "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
204 "y" / "z" /
205 "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
206 "8" / "9" / "+" / "/"
207 ;; Case-sensitive
208
209 base64_terminal ::= (2base64_char "==") / (3base64_char "=")
210
211 CHAR ::= <any 7-bit US-ASCII character except NUL,
212 0x01 - 0x7f>
213
214 continue_req ::= "+" SPACE base64 CRLF
215
216 CR ::= <ASCII CR, carriage return, 0x0C>
217
218 CRLF ::= CR LF
219
220 CTL ::= <any ASCII control character and DEL,
221 0x00 - 0x1f, 0x7f>
222
223
224
225
226 Myers [Page 4]
227
228 RFC 1734 POP3 AUTH December 1994
229
230
231 LF ::= <ASCII LF, line feed, 0x0A>
232
233 SPACE ::= <ASCII SP, space, 0x20>
234
235 TAB ::= <ASCII HT, tab, 0x09>
236
237
238
239 4. References
240
241 [IMAP4-AUTH] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
242 Carnegie Mellon, December 1994.
243
244
245
246 5. Security Considerations
247
248 Security issues are discussed throughout this memo.
249
250
251
252 6. Author's Address
253
254 John G. Myers
255 Carnegie-Mellon University
256 5000 Forbes Ave
257 Pittsburgh, PA 15213
258
259 EMail: jgm+@cmu.edu
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282 Myers [Page 5]
283
1
2
3
4
5
6
7 Network Working Group J. Myers
8 Request for Comments: 1939 Carnegie Mellon
9 STD: 53 M. Rose
10 Obsoletes: 1725 Dover Beach Consulting, Inc.
11 Category: Standards Track May 1996
12
13
14 Post Office Protocol - Version 3
15
16 Status of this Memo
17
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
23
24 Table of Contents
25
26 1. Introduction ................................................ 2
27 2. A Short Digression .......................................... 2
28 3. Basic Operation ............................................. 3
29 4. The AUTHORIZATION State ..................................... 4
30 QUIT Command ................................................ 5
31 5. The TRANSACTION State ....................................... 5
32 STAT Command ................................................ 6
33 LIST Command ................................................ 6
34 RETR Command ................................................ 8
35 DELE Command ................................................ 8
36 NOOP Command ................................................ 9
37 RSET Command ................................................ 9
38 6. The UPDATE State ............................................ 10
39 QUIT Command ................................................ 10
40 7. Optional POP3 Commands ...................................... 11
41 TOP Command ................................................. 11
42 UIDL Command ................................................ 12
43 USER Command ................................................ 13
44 PASS Command ................................................ 14
45 APOP Command ................................................ 15
46 8. Scaling and Operational Considerations ...................... 16
47 9. POP3 Command Summary ........................................ 18
48 10. Example POP3 Session ....................................... 19
49 11. Message Format ............................................. 19
50 12. References ................................................. 20
51 13. Security Considerations .................................... 20
52 14. Acknowledgements ........................................... 20
53 15. Authors' Addresses ......................................... 21
54 Appendix A. Differences from RFC 1725 .......................... 22
55
56
57
58 Myers & Rose Standards Track [Page 1]
59
60 RFC 1939 POP3 May 1996
61
62
63 Appendix B. Command Index ...................................... 23
64
65 1. Introduction
66
67 On certain types of smaller nodes in the Internet it is often
68 impractical to maintain a message transport system (MTS). For
69 example, a workstation may not have sufficient resources (cycles,
70 disk space) in order to permit a SMTP server [RFC821] and associated
71 local mail delivery system to be kept resident and continuously
72 running. Similarly, it may be expensive (or impossible) to keep a
73 personal computer interconnected to an IP-style network for long
74 amounts of time (the node is lacking the resource known as
75 "connectivity").
76
77 Despite this, it is often very useful to be able to manage mail on
78 these smaller nodes, and they often support a user agent (UA) to aid
79 the tasks of mail handling. To solve this problem, a node which can
80 support an MTS entity offers a maildrop service to these less endowed
81 nodes. The Post Office Protocol - Version 3 (POP3) is intended to
82 permit a workstation to dynamically access a maildrop on a server
83 host in a useful fashion. Usually, this means that the POP3 protocol
84 is used to allow a workstation to retrieve mail that the server is
85 holding for it.
86
87 POP3 is not intended to provide extensive manipulation operations of
88 mail on the server; normally, mail is downloaded and then deleted. A
89 more advanced (and complex) protocol, IMAP4, is discussed in
90 [RFC1730].
91
92 For the remainder of this memo, the term "client host" refers to a
93 host making use of the POP3 service, while the term "server host"
94 refers to a host which offers the POP3 service.
95
96 2. A Short Digression
97
98 This memo does not specify how a client host enters mail into the
99 transport system, although a method consistent with the philosophy of
100 this memo is presented here:
101
102 When the user agent on a client host wishes to enter a message
103 into the transport system, it establishes an SMTP connection to
104 its relay host and sends all mail to it. This relay host could
105 be, but need not be, the POP3 server host for the client host. Of
106 course, the relay host must accept mail for delivery to arbitrary
107 recipient addresses, that functionality is not required of all
108 SMTP servers.
109
110
111
112
113
114 Myers & Rose Standards Track [Page 2]
115
116 RFC 1939 POP3 May 1996
117
118
119 3. Basic Operation
120
121 Initially, the server host starts the POP3 service by listening on
122 TCP port 110. When a client host wishes to make use of the service,
123 it establishes a TCP connection with the server host. When the
124 connection is established, the POP3 server sends a greeting. The
125 client and POP3 server then exchange commands and responses
126 (respectively) until the connection is closed or aborted.
127
128 Commands in the POP3 consist of a case-insensitive keyword, possibly
129 followed by one or more arguments. All commands are terminated by a
130 CRLF pair. Keywords and arguments consist of printable ASCII
131 characters. Keywords and arguments are each separated by a single
132 SPACE character. Keywords are three or four characters long. Each
133 argument may be up to 40 characters long.
134
135 Responses in the POP3 consist of a status indicator and a keyword
136 possibly followed by additional information. All responses are
137 terminated by a CRLF pair. Responses may be up to 512 characters
138 long, including the terminating CRLF. There are currently two status
139 indicators: positive ("+OK") and negative ("-ERR"). Servers MUST
140 send the "+OK" and "-ERR" in upper case.
141
142 Responses to certain commands are multi-line. In these cases, which
143 are clearly indicated below, after sending the first line of the
144 response and a CRLF, any additional lines are sent, each terminated
145 by a CRLF pair. When all lines of the response have been sent, a
146 final line is sent, consisting of a termination octet (decimal code
147 046, ".") and a CRLF pair. If any line of the multi-line response
148 begins with the termination octet, the line is "byte-stuffed" by
149 pre-pending the termination octet to that line of the response.
150 Hence a multi-line response is terminated with the five octets
151 "CRLF.CRLF". When examining a multi-line response, the client checks
152 to see if the line begins with the termination octet. If so and if
153 octets other than CRLF follow, the first octet of the line (the
154 termination octet) is stripped away. If so and if CRLF immediately
155 follows the termination character, then the response from the POP
156 server is ended and the line containing ".CRLF" is not considered
157 part of the multi-line response.
158
159 A POP3 session progresses through a number of states during its
160 lifetime. Once the TCP connection has been opened and the POP3
161 server has sent the greeting, the session enters the AUTHORIZATION
162 state. In this state, the client must identify itself to the POP3
163 server. Once the client has successfully done this, the server
164 acquires resources associated with the client's maildrop, and the
165 session enters the TRANSACTION state. In this state, the client
166 requests actions on the part of the POP3 server. When the client has
167
168
169
170 Myers & Rose Standards Track [Page 3]
171
172 RFC 1939 POP3 May 1996
173
174
175 issued the QUIT command, the session enters the UPDATE state. In
176 this state, the POP3 server releases any resources acquired during
177 the TRANSACTION state and says goodbye. The TCP connection is then
178 closed.
179
180 A server MUST respond to an unrecognized, unimplemented, or
181 syntactically invalid command by responding with a negative status
182 indicator. A server MUST respond to a command issued when the
183 session is in an incorrect state by responding with a negative status
184 indicator. There is no general method for a client to distinguish
185 between a server which does not implement an optional command and a
186 server which is unwilling or unable to process the command.
187
188 A POP3 server MAY have an inactivity autologout timer. Such a timer
189 MUST be of at least 10 minutes' duration. The receipt of any command
190 from the client during that interval should suffice to reset the
191 autologout timer. When the timer expires, the session does NOT enter
192 the UPDATE state--the server should close the TCP connection without
193 removing any messages or sending any response to the client.
194
195 4. The AUTHORIZATION State
196
197 Once the TCP connection has been opened by a POP3 client, the POP3
198 server issues a one line greeting. This can be any positive
199 response. An example might be:
200
201 S: +OK POP3 server ready
202
203 The POP3 session is now in the AUTHORIZATION state. The client must
204 now identify and authenticate itself to the POP3 server. Two
205 possible mechanisms for doing this are described in this document,
206 the USER and PASS command combination and the APOP command. Both
207 mechanisms are described later in this document. Additional
208 authentication mechanisms are described in [RFC1734]. While there is
209 no single authentication mechanism that is required of all POP3
210 servers, a POP3 server must of course support at least one
211 authentication mechanism.
212
213 Once the POP3 server has determined through the use of any
214 authentication command that the client should be given access to the
215 appropriate maildrop, the POP3 server then acquires an exclusive-
216 access lock on the maildrop, as necessary to prevent messages from
217 being modified or removed before the session enters the UPDATE state.
218 If the lock is successfully acquired, the POP3 server responds with a
219 positive status indicator. The POP3 session now enters the
220 TRANSACTION state, with no messages marked as deleted. If the
221 maildrop cannot be opened for some reason (for example, a lock can
222 not be acquired, the client is denied access to the appropriate
223
224
225
226 Myers & Rose Standards Track [Page 4]
227
228 RFC 1939 POP3 May 1996
229
230
231 maildrop, or the maildrop cannot be parsed), the POP3 server responds
232 with a negative status indicator. (If a lock was acquired but the
233 POP3 server intends to respond with a negative status indicator, the
234 POP3 server must release the lock prior to rejecting the command.)
235 After returning a negative status indicator, the server may close the
236 connection. If the server does not close the connection, the client
237 may either issue a new authentication command and start again, or the
238 client may issue the QUIT command.
239
240 After the POP3 server has opened the maildrop, it assigns a message-
241 number to each message, and notes the size of each message in octets.
242 The first message in the maildrop is assigned a message-number of
243 "1", the second is assigned "2", and so on, so that the nth message
244 in a maildrop is assigned a message-number of "n". In POP3 commands
245 and responses, all message-numbers and message sizes are expressed in
246 base-10 (i.e., decimal).
247
248 Here is the summary for the QUIT command when used in the
249 AUTHORIZATION state:
250
251 QUIT
252
253 Arguments: none
254
255 Restrictions: none
256
257 Possible Responses:
258 +OK
259
260 Examples:
261 C: QUIT
262 S: +OK dewey POP3 server signing off
263
264 5. The TRANSACTION State
265
266 Once the client has successfully identified itself to the POP3 server
267 and the POP3 server has locked and opened the appropriate maildrop,
268 the POP3 session is now in the TRANSACTION state. The client may now
269 issue any of the following POP3 commands repeatedly. After each
270 command, the POP3 server issues a response. Eventually, the client
271 issues the QUIT command and the POP3 session enters the UPDATE state.
272
273
274
275
276
277
278
279
280
281
282 Myers & Rose Standards Track [Page 5]
283
284 RFC 1939 POP3 May 1996
285
286
287 Here are the POP3 commands valid in the TRANSACTION state:
288
289 STAT
290
291 Arguments: none
292
293 Restrictions:
294 may only be given in the TRANSACTION state
295
296 Discussion:
297 The POP3 server issues a positive response with a line
298 containing information for the maildrop. This line is
299 called a "drop listing" for that maildrop.
300
301 In order to simplify parsing, all POP3 servers are
302 required to use a certain format for drop listings. The
303 positive response consists of "+OK" followed by a single
304 space, the number of messages in the maildrop, a single
305 space, and the size of the maildrop in octets. This memo
306 makes no requirement on what follows the maildrop size.
307 Minimal implementations should just end that line of the
308 response with a CRLF pair. More advanced implementations
309 may include other information.
310
311 NOTE: This memo STRONGLY discourages implementations
312 from supplying additional information in the drop
313 listing. Other, optional, facilities are discussed
314 later on which permit the client to parse the messages
315 in the maildrop.
316
317 Note that messages marked as deleted are not counted in
318 either total.
319
320 Possible Responses:
321 +OK nn mm
322
323 Examples:
324 C: STAT
325 S: +OK 2 320
326
327
328 LIST [msg]
329
330 Arguments:
331 a message-number (optional), which, if present, may NOT
332 refer to a message marked as deleted
333
334
335
336
337
338 Myers & Rose Standards Track [Page 6]
339
340 RFC 1939 POP3 May 1996
341
342
343 Restrictions:
344 may only be given in the TRANSACTION state
345
346 Discussion:
347 If an argument was given and the POP3 server issues a
348 positive response with a line containing information for
349 that message. This line is called a "scan listing" for
350 that message.
351
352 If no argument was given and the POP3 server issues a
353 positive response, then the response given is multi-line.
354 After the initial +OK, for each message in the maildrop,
355 the POP3 server responds with a line containing
356 information for that message. This line is also called a
357 "scan listing" for that message. If there are no
358 messages in the maildrop, then the POP3 server responds
359 with no scan listings--it issues a positive response
360 followed by a line containing a termination octet and a
361 CRLF pair.
362
363 In order to simplify parsing, all POP3 servers are
364 required to use a certain format for scan listings. A
365 scan listing consists of the message-number of the
366 message, followed by a single space and the exact size of
367 the message in octets. Methods for calculating the exact
368 size of the message are described in the "Message Format"
369 section below. This memo makes no requirement on what
370 follows the message size in the scan listing. Minimal
371 implementations should just end that line of the response
372 with a CRLF pair. More advanced implementations may
373 include other information, as parsed from the message.
374
375 NOTE: This memo STRONGLY discourages implementations
376 from supplying additional information in the scan
377 listing. Other, optional, facilities are discussed
378 later on which permit the client to parse the messages
379 in the maildrop.
380
381 Note that messages marked as deleted are not listed.
382
383 Possible Responses:
384 +OK scan listing follows
385 -ERR no such message
386
387 Examples:
388 C: LIST
389 S: +OK 2 messages (320 octets)
390 S: 1 120
391
392
393
394 Myers & Rose Standards Track [Page 7]
395
396 RFC 1939 POP3 May 1996
397
398
399 S: 2 200
400 S: .
401 ...
402 C: LIST 2
403 S: +OK 2 200
404 ...
405 C: LIST 3
406 S: -ERR no such message, only 2 messages in maildrop
407
408
409 RETR msg
410
411 Arguments:
412 a message-number (required) which may NOT refer to a
413 message marked as deleted
414
415 Restrictions:
416 may only be given in the TRANSACTION state
417
418 Discussion:
419 If the POP3 server issues a positive response, then the
420 response given is multi-line. After the initial +OK, the
421 POP3 server sends the message corresponding to the given
422 message-number, being careful to byte-stuff the termination
423 character (as with all multi-line responses).
424
425 Possible Responses:
426 +OK message follows
427 -ERR no such message
428
429 Examples:
430 C: RETR 1
431 S: +OK 120 octets
432 S: <the POP3 server sends the entire message here>
433 S: .
434
435
436 DELE msg
437
438 Arguments:
439 a message-number (required) which may NOT refer to a
440 message marked as deleted
441
442 Restrictions:
443 may only be given in the TRANSACTION state
444
445
446
447
448
449
450 Myers & Rose Standards Track [Page 8]
451
452 RFC 1939 POP3 May 1996
453
454
455 Discussion:
456 The POP3 server marks the message as deleted. Any future
457 reference to the message-number associated with the message
458 in a POP3 command generates an error. The POP3 server does
459 not actually delete the message until the POP3 session
460 enters the UPDATE state.
461
462 Possible Responses:
463 +OK message deleted
464 -ERR no such message
465
466 Examples:
467 C: DELE 1
468 S: +OK message 1 deleted
469 ...
470 C: DELE 2
471 S: -ERR message 2 already deleted
472
473
474 NOOP
475
476 Arguments: none
477
478 Restrictions:
479 may only be given in the TRANSACTION state
480
481 Discussion:
482 The POP3 server does nothing, it merely replies with a
483 positive response.
484
485 Possible Responses:
486 +OK
487
488 Examples:
489 C: NOOP
490 S: +OK
491
492
493 RSET
494
495 Arguments: none
496
497 Restrictions:
498 may only be given in the TRANSACTION state
499
500 Discussion:
501 If any messages have been marked as deleted by the POP3
502 server, they are unmarked. The POP3 server then replies
503
504
505
506 Myers & Rose Standards Track [Page 9]
507
508 RFC 1939 POP3 May 1996
509
510
511 with a positive response.
512
513 Possible Responses:
514 +OK
515
516 Examples:
517 C: RSET
518 S: +OK maildrop has 2 messages (320 octets)
519
520 6. The UPDATE State
521
522 When the client issues the QUIT command from the TRANSACTION state,
523 the POP3 session enters the UPDATE state. (Note that if the client
524 issues the QUIT command from the AUTHORIZATION state, the POP3
525 session terminates but does NOT enter the UPDATE state.)
526
527 If a session terminates for some reason other than a client-issued
528 QUIT command, the POP3 session does NOT enter the UPDATE state and
529 MUST not remove any messages from the maildrop.
530
531 QUIT
532
533 Arguments: none
534
535 Restrictions: none
536
537 Discussion:
538 The POP3 server removes all messages marked as deleted
539 from the maildrop and replies as to the status of this
540 operation. If there is an error, such as a resource
541 shortage, encountered while removing messages, the
542 maildrop may result in having some or none of the messages
543 marked as deleted be removed. In no case may the server
544 remove any messages not marked as deleted.
545
546 Whether the removal was successful or not, the server
547 then releases any exclusive-access lock on the maildrop
548 and closes the TCP connection.
549
550 Possible Responses:
551 +OK
552 -ERR some deleted messages not removed
553
554 Examples:
555 C: QUIT
556 S: +OK dewey POP3 server signing off (maildrop empty)
557 ...
558 C: QUIT
559
560
561
562 Myers & Rose Standards Track [Page 10]
563
564 RFC 1939 POP3 May 1996
565
566
567 S: +OK dewey POP3 server signing off (2 messages left)
568 ...
569
570 7. Optional POP3 Commands
571
572 The POP3 commands discussed above must be supported by all minimal
573 implementations of POP3 servers.
574
575 The optional POP3 commands described below permit a POP3 client
576 greater freedom in message handling, while preserving a simple POP3
577 server implementation.
578
579 NOTE: This memo STRONGLY encourages implementations to support
580 these commands in lieu of developing augmented drop and scan
581 listings. In short, the philosophy of this memo is to put
582 intelligence in the part of the POP3 client and not the POP3
583 server.
584
585 TOP msg n
586
587 Arguments:
588 a message-number (required) which may NOT refer to to a
589 message marked as deleted, and a non-negative number
590 of lines (required)
591
592 Restrictions:
593 may only be given in the TRANSACTION state
594
595 Discussion:
596 If the POP3 server issues a positive response, then the
597 response given is multi-line. After the initial +OK, the
598 POP3 server sends the headers of the message, the blank
599 line separating the headers from the body, and then the
600 number of lines of the indicated message's body, being
601 careful to byte-stuff the termination character (as with
602 all multi-line responses).
603
604 Note that if the number of lines requested by the POP3
605 client is greater than than the number of lines in the
606 body, then the POP3 server sends the entire message.
607
608 Possible Responses:
609 +OK top of message follows
610 -ERR no such message
611
612 Examples:
613 C: TOP 1 10
614 S: +OK
615
616
617
618 Myers & Rose Standards Track [Page 11]
619
620 RFC 1939 POP3 May 1996
621
622
623 S: <the POP3 server sends the headers of the
624 message, a blank line, and the first 10 lines
625 of the body of the message>
626 S: .
627 ...
628 C: TOP 100 3
629 S: -ERR no such message
630
631
632 UIDL [msg]
633
634 Arguments:
635 a message-number (optional), which, if present, may NOT
636 refer to a message marked as deleted
637
638 Restrictions:
639 may only be given in the TRANSACTION state.
640
641 Discussion:
642 If an argument was given and the POP3 server issues a positive
643 response with a line containing information for that message.
644 This line is called a "unique-id listing" for that message.
645
646 If no argument was given and the POP3 server issues a positive
647 response, then the response given is multi-line. After the
648 initial +OK, for each message in the maildrop, the POP3 server
649 responds with a line containing information for that message.
650 This line is called a "unique-id listing" for that message.
651
652 In order to simplify parsing, all POP3 servers are required to
653 use a certain format for unique-id listings. A unique-id
654 listing consists of the message-number of the message,
655 followed by a single space and the unique-id of the message.
656 No information follows the unique-id in the unique-id listing.
657
658 The unique-id of a message is an arbitrary server-determined
659 string, consisting of one to 70 characters in the range 0x21
660 to 0x7E, which uniquely identifies a message within a
661 maildrop and which persists across sessions. This
662 persistence is required even if a session ends without
663 entering the UPDATE state. The server should never reuse an
664 unique-id in a given maildrop, for as long as the entity
665 using the unique-id exists.
666
667 Note that messages marked as deleted are not listed.
668
669 While it is generally preferable for server implementations
670 to store arbitrarily assigned unique-ids in the maildrop,
671
672
673
674 Myers & Rose Standards Track [Page 12]
675
676 RFC 1939 POP3 May 1996
677
678
679 this specification is intended to permit unique-ids to be
680 calculated as a hash of the message. Clients should be able
681 to handle a situation where two identical copies of a
682 message in a maildrop have the same unique-id.
683
684 Possible Responses:
685 +OK unique-id listing follows
686 -ERR no such message
687
688 Examples:
689 C: UIDL
690 S: +OK
691 S: 1 whqtswO00WBw418f9t5JxYwZ
692 S: 2 QhdPYR:00WBw1Ph7x7
693 S: .
694 ...
695 C: UIDL 2
696 S: +OK 2 QhdPYR:00WBw1Ph7x7
697 ...
698 C: UIDL 3
699 S: -ERR no such message, only 2 messages in maildrop
700
701
702 USER name
703
704 Arguments:
705 a string identifying a mailbox (required), which is of
706 significance ONLY to the server
707
708 Restrictions:
709 may only be given in the AUTHORIZATION state after the POP3
710 greeting or after an unsuccessful USER or PASS command
711
712 Discussion:
713 To authenticate using the USER and PASS command
714 combination, the client must first issue the USER
715 command. If the POP3 server responds with a positive
716 status indicator ("+OK"), then the client may issue
717 either the PASS command to complete the authentication,
718 or the QUIT command to terminate the POP3 session. If
719 the POP3 server responds with a negative status indicator
720 ("-ERR") to the USER command, then the client may either
721 issue a new authentication command or may issue the QUIT
722 command.
723
724 The server may return a positive response even though no
725 such mailbox exists. The server may return a negative
726 response if mailbox exists, but does not permit plaintext
727
728
729
730 Myers & Rose Standards Track [Page 13]
731
732 RFC 1939 POP3 May 1996
733
734
735 password authentication.
736
737 Possible Responses:
738 +OK name is a valid mailbox
739 -ERR never heard of mailbox name
740
741 Examples:
742 C: USER frated
743 S: -ERR sorry, no mailbox for frated here
744 ...
745 C: USER mrose
746 S: +OK mrose is a real hoopy frood
747
748
749 PASS string
750
751 Arguments:
752 a server/mailbox-specific password (required)
753
754 Restrictions:
755 may only be given in the AUTHORIZATION state immediately
756 after a successful USER command
757
758 Discussion:
759 When the client issues the PASS command, the POP3 server
760 uses the argument pair from the USER and PASS commands to
761 determine if the client should be given access to the
762 appropriate maildrop.
763
764 Since the PASS command has exactly one argument, a POP3
765 server may treat spaces in the argument as part of the
766 password, instead of as argument separators.
767
768 Possible Responses:
769 +OK maildrop locked and ready
770 -ERR invalid password
771 -ERR unable to lock maildrop
772
773 Examples:
774 C: USER mrose
775 S: +OK mrose is a real hoopy frood
776 C: PASS secret
777 S: -ERR maildrop already locked
778 ...
779 C: USER mrose
780 S: +OK mrose is a real hoopy frood
781 C: PASS secret
782 S: +OK mrose's maildrop has 2 messages (320 octets)
783
784
785
786 Myers & Rose Standards Track [Page 14]
787
788 RFC 1939 POP3 May 1996
789
790
791 APOP name digest
792
793 Arguments:
794 a string identifying a mailbox and a MD5 digest string
795 (both required)
796
797 Restrictions:
798 may only be given in the AUTHORIZATION state after the POP3
799 greeting or after an unsuccessful USER or PASS command
800
801 Discussion:
802 Normally, each POP3 session starts with a USER/PASS
803 exchange. This results in a server/user-id specific
804 password being sent in the clear on the network. For
805 intermittent use of POP3, this may not introduce a sizable
806 risk. However, many POP3 client implementations connect to
807 the POP3 server on a regular basis -- to check for new
808 mail. Further the interval of session initiation may be on
809 the order of five minutes. Hence, the risk of password
810 capture is greatly enhanced.
811
812 An alternate method of authentication is required which
813 provides for both origin authentication and replay
814 protection, but which does not involve sending a password
815 in the clear over the network. The APOP command provides
816 this functionality.
817
818 A POP3 server which implements the APOP command will
819 include a timestamp in its banner greeting. The syntax of
820 the timestamp corresponds to the `msg-id' in [RFC822], and
821 MUST be different each time the POP3 server issues a banner
822 greeting. For example, on a UNIX implementation in which a
823 separate UNIX process is used for each instance of a POP3
824 server, the syntax of the timestamp might be:
825
826 <process-ID.clock@hostname>
827
828 where `process-ID' is the decimal value of the process's
829 PID, clock is the decimal value of the system clock, and
830 hostname is the fully-qualified domain-name corresponding
831 to the host where the POP3 server is running.
832
833 The POP3 client makes note of this timestamp, and then
834 issues the APOP command. The `name' parameter has
835 identical semantics to the `name' parameter of the USER
836 command. The `digest' parameter is calculated by applying
837 the MD5 algorithm [RFC1321] to a string consisting of the
838 timestamp (including angle-brackets) followed by a shared
839
840
841
842 Myers & Rose Standards Track [Page 15]
843
844 RFC 1939 POP3 May 1996
845
846
847 secret. This shared secret is a string known only to the
848 POP3 client and server. Great care should be taken to
849 prevent unauthorized disclosure of the secret, as knowledge
850 of the secret will allow any entity to successfully
851 masquerade as the named user. The `digest' parameter
852 itself is a 16-octet value which is sent in hexadecimal
853 format, using lower-case ASCII characters.
854
855 When the POP3 server receives the APOP command, it verifies
856 the digest provided. If the digest is correct, the POP3
857 server issues a positive response, and the POP3 session
858 enters the TRANSACTION state. Otherwise, a negative
859 response is issued and the POP3 session remains in the
860 AUTHORIZATION state.
861
862 Note that as the length of the shared secret increases, so
863 does the difficulty of deriving it. As such, shared
864 secrets should be long strings (considerably longer than
865 the 8-character example shown below).
866
867 Possible Responses:
868 +OK maildrop locked and ready
869 -ERR permission denied
870
871 Examples:
872 S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
873 C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
874 S: +OK maildrop has 1 message (369 octets)
875
876 In this example, the shared secret is the string `tan-
877 staaf'. Hence, the MD5 algorithm is applied to the string
878
879 <1896.697170952@dbc.mtview.ca.us>tanstaaf
880
881 which produces a digest value of
882
883 c4c9334bac560ecc979e58001b3e22fb
884
885 8. Scaling and Operational Considerations
886
887 Since some of the optional features described above were added to the
888 POP3 protocol, experience has accumulated in using them in large-
889 scale commercial post office operations where most of the users are
890 unrelated to each other. In these situations and others, users and
891 vendors of POP3 clients have discovered that the combination of using
892 the UIDL command and not issuing the DELE command can provide a weak
893 version of the "maildrop as semi-permanent repository" functionality
894 normally associated with IMAP. Of course the other capabilities of
895
896
897
898 Myers & Rose Standards Track [Page 16]
899
900 RFC 1939 POP3 May 1996
901
902
903 IMAP, such as polling an existing connection for newly arrived
904 messages and supporting multiple folders on the server, are not
905 present in POP3.
906
907 When these facilities are used in this way by casual users, there has
908 been a tendency for already-read messages to accumulate on the server
909 without bound. This is clearly an undesirable behavior pattern from
910 the standpoint of the server operator. This situation is aggravated
911 by the fact that the limited capabilities of the POP3 do not permit
912 efficient handling of maildrops which have hundreds or thousands of
913 messages.
914
915 Consequently, it is recommended that operators of large-scale multi-
916 user servers, especially ones in which the user's only access to the
917 maildrop is via POP3, consider such options as:
918
919 * Imposing a per-user maildrop storage quota or the like.
920
921 A disadvantage to this option is that accumulation of messages may
922 result in the user's inability to receive new ones into the
923 maildrop. Sites which choose this option should be sure to inform
924 users of impending or current exhaustion of quota, perhaps by
925 inserting an appropriate message into the user's maildrop.
926
927 * Enforce a site policy regarding mail retention on the server.
928
929 Sites are free to establish local policy regarding the storage and
930 retention of messages on the server, both read and unread. For
931 example, a site might delete unread messages from the server after
932 60 days and delete read messages after 7 days. Such message
933 deletions are outside the scope of the POP3 protocol and are not
934 considered a protocol violation.
935
936 Server operators enforcing message deletion policies should take
937 care to make all users aware of the policies in force.
938
939 Clients must not assume that a site policy will automate message
940 deletions, and should continue to explicitly delete messages using
941 the DELE command when appropriate.
942
943 It should be noted that enforcing site message deletion policies
944 may be confusing to the user community, since their POP3 client
945 may contain configuration options to leave mail on the server
946 which will not in fact be supported by the server.
947
948 One special case of a site policy is that messages may only be
949 downloaded once from the server, and are deleted after this has
950 been accomplished. This could be implemented in POP3 server
951
952
953
954 Myers & Rose Standards Track [Page 17]
955
956 RFC 1939 POP3 May 1996
957
958
959 software by the following mechanism: "following a POP3 login by a
960 client which was ended by a QUIT, delete all messages downloaded
961 during the session with the RETR command". It is important not to
962 delete messages in the event of abnormal connection termination
963 (ie, if no QUIT was received from the client) because the client
964 may not have successfully received or stored the messages.
965 Servers implementing a download-and-delete policy may also wish to
966 disable or limit the optional TOP command, since it could be used
967 as an alternate mechanism to download entire messages.
968
969 9. POP3 Command Summary
970
971 Minimal POP3 Commands:
972
973 USER name valid in the AUTHORIZATION state
974 PASS string
975 QUIT
976
977 STAT valid in the TRANSACTION state
978 LIST [msg]
979 RETR msg
980 DELE msg
981 NOOP
982 RSET
983 QUIT
984
985 Optional POP3 Commands:
986
987 APOP name digest valid in the AUTHORIZATION state
988
989 TOP msg n valid in the TRANSACTION state
990 UIDL [msg]
991
992 POP3 Replies:
993
994 +OK
995 -ERR
996
997 Note that with the exception of the STAT, LIST, and UIDL commands,
998 the reply given by the POP3 server to any command is significant
999 only to "+OK" and "-ERR". Any text occurring after this reply
1000 may be ignored by the client.
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010 Myers & Rose Standards Track [Page 18]
1011
1012 RFC 1939 POP3 May 1996
1013
1014
1015 10. Example POP3 Session
1016
1017 S: <wait for connection on TCP port 110>
1018 C: <open connection>
1019 S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
1020 C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
1021 S: +OK mrose's maildrop has 2 messages (320 octets)
1022 C: STAT
1023 S: +OK 2 320
1024 C: LIST
1025 S: +OK 2 messages (320 octets)
1026 S: 1 120
1027 S: 2 200
1028 S: .
1029 C: RETR 1
1030 S: +OK 120 octets
1031 S: <the POP3 server sends message 1>
1032 S: .
1033 C: DELE 1
1034 S: +OK message 1 deleted
1035 C: RETR 2
1036 S: +OK 200 octets
1037 S: <the POP3 server sends message 2>
1038 S: .
1039 C: DELE 2
1040 S: +OK message 2 deleted
1041 C: QUIT
1042 S: +OK dewey POP3 server signing off (maildrop empty)
1043 C: <close connection>
1044 S: <wait for next connection>
1045
1046 11. Message Format
1047
1048 All messages transmitted during a POP3 session are assumed to conform
1049 to the standard for the format of Internet text messages [RFC822].
1050
1051 It is important to note that the octet count for a message on the
1052 server host may differ from the octet count assigned to that message
1053 due to local conventions for designating end-of-line. Usually,
1054 during the AUTHORIZATION state of the POP3 session, the POP3 server
1055 can calculate the size of each message in octets when it opens the
1056 maildrop. For example, if the POP3 server host internally represents
1057 end-of-line as a single character, then the POP3 server simply counts
1058 each occurrence of this character in a message as two octets. Note
1059 that lines in the message which start with the termination octet need
1060 not (and must not) be counted twice, since the POP3 client will
1061 remove all byte-stuffed termination characters when it receives a
1062 multi-line response.
1063
1064
1065
1066 Myers & Rose Standards Track [Page 19]
1067
1068 RFC 1939 POP3 May 1996
1069
1070
1071 12. References
1072
1073 [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
1074 821, USC/Information Sciences Institute, August 1982.
1075
1076 [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text
1077 Messages", STD 11, RFC 822, University of Delaware, August 1982.
1078
1079 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1080 MIT Laboratory for Computer Science, April 1992.
1081
1082 [RFC1730] Crispin, M., "Internet Message Access Protocol - Version
1083 4", RFC 1730, University of Washington, December 1994.
1084
1085 [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
1086 Carnegie Mellon, December 1994.
1087
1088 13. Security Considerations
1089
1090 It is conjectured that use of the APOP command provides origin
1091 identification and replay protection for a POP3 session.
1092 Accordingly, a POP3 server which implements both the PASS and APOP
1093 commands should not allow both methods of access for a given user;
1094 that is, for a given mailbox name, either the USER/PASS command
1095 sequence or the APOP command is allowed, but not both.
1096
1097 Further, note that as the length of the shared secret increases, so
1098 does the difficulty of deriving it.
1099
1100 Servers that answer -ERR to the USER command are giving potential
1101 attackers clues about which names are valid.
1102
1103 Use of the PASS command sends passwords in the clear over the
1104 network.
1105
1106 Use of the RETR and TOP commands sends mail in the clear over the
1107 network.
1108
1109 Otherwise, security issues are not discussed in this memo.
1110
1111 14. Acknowledgements
1112
1113 The POP family has a long and checkered history. Although primarily
1114 a minor revision to RFC 1460, POP3 is based on the ideas presented in
1115 RFCs 918, 937, and 1081.
1116
1117 In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
1118 provided significant comments on the APOP command.
1119
1120
1121
1122 Myers & Rose Standards Track [Page 20]
1123
1124 RFC 1939 POP3 May 1996
1125
1126
1127 15. Authors' Addresses
1128
1129 John G. Myers
1130 Carnegie-Mellon University
1131 5000 Forbes Ave
1132 Pittsburgh, PA 15213
1133
1134 EMail: jgm+@cmu.edu
1135
1136
1137 Marshall T. Rose
1138 Dover Beach Consulting, Inc.
1139 420 Whisman Court
1140 Mountain View, CA 94043-2186
1141
1142 EMail: mrose@dbc.mtview.ca.us
1143
1144
1145
1146
1147
1148
1149
1150
1151
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 Myers & Rose Standards Track [Page 21]
1179
1180 RFC 1939 POP3 May 1996
1181
1182
1183 Appendix A. Differences from RFC 1725
1184
1185 This memo is a revision to RFC 1725, a Draft Standard. It makes the
1186 following changes from that document:
1187
1188 - clarifies that command keywords are case insensitive.
1189
1190 - specifies that servers must send "+OK" and "-ERR" in
1191 upper case.
1192
1193 - specifies that the initial greeting is a positive response,
1194 instead of any string which should be a positive response.
1195
1196 - clarifies behavior for unimplemented commands.
1197
1198 - makes the USER and PASS commands optional.
1199
1200 - clarified the set of possible responses to the USER command.
1201
1202 - reverses the order of the examples in the USER and PASS
1203 commands, to reduce confusion.
1204
1205 - clarifies that the PASS command may only be given immediately
1206 after a successful USER command.
1207
1208 - clarified the persistence requirements of UIDs and added some
1209 implementation notes.
1210
1211 - specifies a UID length limitation of one to 70 octets.
1212
1213 - specifies a status indicator length limitation
1214 of 512 octets, including the CRLF.
1215
1216 - clarifies that LIST with no arguments on an empty mailbox
1217 returns success.
1218
1219 - adds a reference from the LIST command to the Message Format
1220 section
1221
1222 - clarifies the behavior of QUIT upon failure
1223
1224 - clarifies the security section to not imply the use of the
1225 USER command with the APOP command.
1226
1227 - adds references to RFCs 1730 and 1734
1228
1229 - clarifies the method by which a UA may enter mail into the
1230 transport system.
1231
1232
1233
1234 Myers & Rose Standards Track [Page 22]
1235
1236 RFC 1939 POP3 May 1996
1237
1238
1239 - clarifies that the second argument to the TOP command is a
1240 number of lines.
1241
1242 - changes the suggestion in the Security Considerations section
1243 for a server to not accept both PASS and APOP for a given user
1244 from a "must" to a "should".
1245
1246 - adds a section on scaling and operational considerations
1247
1248 Appendix B. Command Index
1249
1250 APOP ....................................................... 15
1251 DELE ....................................................... 8
1252 LIST ....................................................... 6
1253 NOOP ....................................................... 9
1254 PASS ....................................................... 14
1255 QUIT ....................................................... 5
1256 QUIT ....................................................... 10
1257 RETR ....................................................... 8
1258 RSET ....................................................... 9
1259 STAT ....................................................... 6
1260 TOP ........................................................ 11
1261 UIDL ....................................................... 12
1262 USER ....................................................... 13
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290 Myers & Rose Standards Track [Page 23]
1291
1
2
3
4
5
6
7 Network Working Group R. Nelson
8 Request for Comments: 1957 Crynwr Software
9 Updates: 1939 June 1996
10 Category: Informational
11
12
13 Some Observations on Implementations
14 of the Post Office Protocol (POP3)
15
16 Status of this Memo
17
18 This memo provides information for the Internet community. This memo
19 does not specify an Internet standard of any kind. Distribution of
20 this memo is unlimited.
21
22 Observations
23
24 Sometimes an implementation is mistaken for a standard. POP3 servers
25 and clients are no exception. The widely-used UCB POP3 server,
26 popper, which has been further developed by Qualcomm, always has
27 additional information following the status indicator. So, the
28 status indicator always has a space following it. Two POP3 clients
29 have been observed to expect that space, and fail when it has not
30 been found. The RFC does not require the space, hence this memo.
31 These clients are the freely copyable Unix "popclient" and the
32 proprietary "netApp Systems Internet Series". The authors of both of
33 these have been contacted, and new releases will not expect the
34 space, but old versions should be supported.
35
36 In addition, two popular clients require optional parts of the RFC.
37 Netscape requires UIDL, and Eudora requires TOP.
38
39 The optional APOP authentication command has not achieved wide
40 penetration yet. Newer versions of the Qualcomm POP server implement
41 it. Known client implementations of APOP include GNU Emacs VM client
42 and Eudora Lite and Eudora Pro.
43
44 Security Considerations
45
46 Security issues are not discussed in this memo.
47
48 References
49
50 [1] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
51 STD 53, RFC 1939, May 1996.
52
53
54
55
56
57
58 Nelson Informational [Page 1]
59
60 RFC 1957 Notes on POP3 Implementations June 1996
61
62
63 Author's Address
64
65 Russell Nelson
66 Crynwr Software
67 521 Pleasant Valley Rd.
68 Potsdam, NY 13676
69
70 Phone: +1.315.268.1925
71 FAX: +1.315.268.9201
72 EMail: nelson@crynwr.com
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114 Nelson Informational [Page 2]
115
This diff could not be displayed because it is too large.
1
2
3
4
5
6
7 Network Working Group R. Gellens
8 Request for Comments: 2449 Qualcomm
9 Updates: 1939 C. Newman
10 Category: Standards Track Innosoft
11 L. Lundblade
12 Qualcomm
13 November 1998
14
15
16 POP3 Extension Mechanism
17
18 Status of this Memo
19
20 This document specifies an Internet standards track protocol for the
21 Internet community, and requests discussion and suggestions for
22 improvements. Please refer to the current edition of the "Internet
23 Official Protocol Standards" (STD 1) for the standardization state
24 and status of this protocol. Distribution of this memo is unlimited.
25
26 Copyright Notice
27
28 Copyright (C) The Internet Society (1998). All Rights Reserved.
29
30 IESG Note
31
32 This extension to the POP3 protocol is to be used by a server to
33 express policy descisions taken by the server administrator. It is
34 not an endorsement of implementations of further POP3 extensions
35 generally. It is the general view that the POP3 protocol should stay
36 simple, and for the simple purpose of downloading email from a mail
37 server. If more complicated operations are needed, the IMAP protocol
38 [RFC 2060] should be used. The first paragraph of section 7 should
39 be read very carefully.
40
41 Table of Contents
42
43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
44 2. Conventions Used in this Document . . . . . . . . . . . . . 3
45 3. General Command and Response Grammar . . . . . . . . . . . . 3
46 4. Parameter and Response Lengths . . . . . . . . . . . . . . 4
47 5. The CAPA Command . . . . . . . . . . . . . . . . . . . . . . 4
48 6. Initial Set of Capabilities . . . . . . . . . . . . . . . . 5
49 6.1. TOP capability . . . . . . . . . . . . . . . . . . . . . 6
50 6.2. USER capability . . . . . . . . . . . . . . . . . . . . 6
51 6.3. SASL capability . . . . . . . . . . . . . . . . . . . . 7
52 6.4. RESP-CODES capability . . . . . . . . . . . . . . . . . 8
53 6.5. LOGIN-DELAY capability . . . . . . . . . . . . . . . . . 8
54 6.6. PIPELINING capability . . . . . . . . . . . . . . . . . 9
55
56
57
58 Gellens, et. al. Standards Track [Page 1]
59
60 RFC 2449 POP3 Extension Mechanism November 1998
61
62
63 6.7. EXPIRE capability . . . . . . . . . . . . . . . . . . . 10
64 6.8. UIDL capability . . . . . . . . . . . . . . . . . . . . 13
65 6.9. IMPLEMENTATION capability . . . . . . . . . . . . . . . 13
66 7. Future Extensions to POP3 . . . . . . . . . . . . . . . . . 14
67 8. Extended POP3 Response Codes . . . . . . . . . . . . . . . . 14
68 8.1. Initial POP3 response codes . . . . . . . . . . . . . . 15
69 8.1.1. The LOGIN-DELAY response code . . . . . . . . . . . 15
70 8.1.2. The IN-USE response code . . . . . . . . . . . . . 16
71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
72 10. Security Considerations . . . . . . . . . . . . . . . . . . 17
73 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
74 12. References . . . . . . . . . . . . . . . . . . . . . . . . 17
75 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18
76 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
77
78 1. Introduction
79
80 The Post Office Protocol version 3 [POP3] is very widely used.
81 However, while it includes some optional commands (and some useful
82 protocol extensions have been published), it lacks a mechanism for
83 advertising support for these extensions or for behavior variations.
84
85 Currently these optional features and extensions can only be detected
86 by probing, if at all. This is at best inefficient, and possibly
87 worse. As a result, some clients have manual configuration options
88 for POP3 server capabilities.
89
90 Because one of the most important characteristics of POP3 is its
91 simplicity, it is desirable that extensions be few in number (see
92 section 7). However, some extensions are necessary (such as ones
93 that provide improved security [POP-AUTH]), while others are very
94 desirable in certain situations. In addition, a means for
95 discovering server behavior is needed.
96
97 This memo updates RFC 1939 [POP3] to define a mechanism to announce
98 support for optional commands, extensions, and unconditional server
99 behavior. Included is an initial set of currently deployed
100 capabilities which vary between server implementations, and several
101 new capabilities (SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE
102 and IMPLEMENTATION). This document also extends POP3 error messages
103 so that machine parsable codes can be provided to the client. An
104 initial set of response codes is included. In addition, an [ABNF]
105 specification of POP3 commands and responses is defined.
106
107 Public comments should be sent to the IETF POP3 Extensions mailing
108 list, <ietf-pop3ext@imc.org>. To subscribe, send a message
109 containing SUBSCRIBE to <ietf-pop3ext-request@imc.org>.
110
111
112
113
114 Gellens, et. al. Standards Track [Page 2]
115
116 RFC 2449 POP3 Extension Mechanism November 1998
117
118
119 2. Conventions Used in this Document
120
121 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
122 and "MAY" in this document are to be interpreted as described in "Key
123 words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
124
125 In examples, "C:" and "S:" indicate lines sent by the client and
126 server respectively.
127
128 3. General Command and Response Grammar
129
130 The general form of POP3 commands and responses is described using
131 [ABNF]:
132
133 POP3 commands:
134
135 command = keyword *(SP param) CRLF ;255 octets maximum
136 keyword = 3*4VCHAR
137 param = 1*VCHAR
138
139 POP3 responses:
140
141 response = greeting / single-line / capa-resp / multi-line
142 capa-resp = single-line *capability "." CRLF
143 capa-tag = 1*cchar
144 capability = capa-tag *(SP param) CRLF ;512 octets maximum
145 cchar = %x21-2D / %x2F-7F
146 ;printable ASCII, excluding "."
147 dot-stuffed = *CHAR CRLF ;must be dot-stuffed
148 gchar = %x21-3B / %x3D-7F
149 ;printable ASCII, excluding "<"
150 greeting = "+OK" [resp-code] *gchar [timestamp] *gchar CRLF
151 ;512 octets maximum
152 multi-line = single-line *dot-stuffed "." CRLF
153 rchar = %x21-2E / %x30-5C / %x5E-7F
154 ;printable ASCII, excluding "/" and "]"
155 resp-code = "[" resp-level *("/" resp-level) "]"
156 resp-level = 1*rchar
157 schar = %x21-5A / %x5C-7F
158 ;printable ASCII, excluding "["
159 single-line = status [SP text] CRLF ;512 octets maximum
160 status = "+OK" / "-ERR"
161 text = *schar / resp-code *CHAR
162 timestamp = "<" *VCHAR ">"
163 ;MUST conform to RFC-822 msg-id
164
165
166
167
168
169
170 Gellens, et. al. Standards Track [Page 3]
171
172 RFC 2449 POP3 Extension Mechanism November 1998
173
174
175 4. Parameter and Response Lengths
176
177 This specification increases the length restrictions on commands and
178 parameters imposed by RFC 1939.
179
180 The maximum length of a command is increased from 47 characters (4
181 character command, single space, 40 character argument, CRLF) to 255
182 octets, including the terminating CRLF.
183
184 Servers which support the CAPA command MUST support commands up to
185 255 octets. Servers MUST also support the largest maximum command
186 length specified by any supported capability.
187
188 The maximum length of the first line of a command response (including
189 the initial greeting) is unchanged at 512 octets (including the
190 terminating CRLF).
191
192 5. The CAPA Command
193
194 The POP3 CAPA command returns a list of capabilities supported by the
195 POP3 server. It is available in both the AUTHORIZATION and
196 TRANSACTION states.
197
198 A capability description MUST document in which states the capability
199 is announced, and in which states the commands are valid.
200
201 Capabilities available in the AUTHORIZATION state MUST be announced
202 in both states.
203
204 If a capability is announced in both states, but the argument might
205 differ after authentication, this possibility MUST be stated in the
206 capability description.
207
208 (These requirements allow a client to issue only one CAPA command if
209 it does not use any TRANSACTION-only capabilities, or any
210 capabilities whose values may differ after authentication.)
211
212 If the authentication step negotiates an integrity protection layer,
213 the client SHOULD reissue the CAPA command after authenticating, to
214 check for active down-negotiation attacks.
215
216 Each capability may enable additional protocol commands, additional
217 parameters and responses for existing commands, or describe an aspect
218 of server behavior. These details are specified in the description
219 of the capability.
220
221
222
223
224
225
226 Gellens, et. al. Standards Track [Page 4]
227
228 RFC 2449 POP3 Extension Mechanism November 1998
229
230
231 Section 3 describes the CAPA response using [ABNF]. When a
232 capability response describes an optional command, the <capa-tag>
233 SHOULD be identical to the command keyword. CAPA response tags are
234 case-insensitive.
235
236 CAPA
237
238 Arguments:
239 none
240
241 Restrictions:
242 none
243
244 Discussion:
245 An -ERR response indicates the capability command is not
246 implemented and the client will have to probe for
247 capabilities as before.
248
249 An +OK response is followed by a list of capabilities, one
250 per line. Each capability name MAY be followed by a single
251 space and a space-separated list of parameters. Each
252 capability line is limited to 512 octets (including the
253 CRLF). The capability list is terminated by a line
254 containing a termination octet (".") and a CRLF pair.
255
256 Possible Responses:
257 +OK -ERR
258
259 Examples:
260 C: CAPA
261 S: +OK Capability list follows
262 S: TOP
263 S: USER
264 S: SASL CRAM-MD5 KERBEROS_V4
265 S: RESP-CODES
266 S: LOGIN-DELAY 900
267 S: PIPELINING
268 S: EXPIRE 60
269 S: UIDL
270 S: IMPLEMENTATION Shlemazle-Plotz-v302
271 S: .
272
273 6. Initial Set of Capabilities
274
275 This section defines an initial set of POP3 capabilities. These
276 include the optional POP3 commands, already published POP3
277 extensions, and behavior variations between POP3 servers which can
278 impact clients.
279
280
281
282 Gellens, et. al. Standards Track [Page 5]
283
284 RFC 2449 POP3 Extension Mechanism November 1998
285
286
287 Note that there is no APOP capability, even though APOP is an
288 optional command in [POP3]. Clients discover server support of APOP
289 by the presence in the greeting banner of an initial challenge
290 enclosed in angle brackets ("<>"). Therefore, an APOP capability
291 would introduce two ways for a server to announce the same thing.
292
293 6.1. TOP capability
294
295 CAPA tag:
296 TOP
297
298 Arguments:
299 none
300
301 Added commands:
302 TOP
303
304 Standard commands affected:
305 none
306
307 Announced states / possible differences:
308 both / no
309
310 Commands valid in states:
311 TRANSACTION
312
313 Specification reference:
314 [POP3]
315
316 Discussion:
317 The TOP capability indicates the optional TOP command is
318 available.
319
320 6.2. USER capability
321
322 CAPA tag:
323 USER
324
325 Arguments:
326 none
327
328 Added commands:
329 USER PASS
330
331 Standard commands affected:
332 none
333
334
335
336
337
338 Gellens, et. al. Standards Track [Page 6]
339
340 RFC 2449 POP3 Extension Mechanism November 1998
341
342
343 Announced states / possible differences:
344 both / no
345
346 Commands valid in states:
347 AUTHENTICATION
348
349 Specification reference:
350 [POP3]
351
352 Discussion:
353 The USER capability indicates that the USER and PASS commands
354 are supported, although they may not be available to all users.
355
356 6.3. SASL capability
357
358 CAPA tag:
359 SASL
360
361 Arguments:
362 Supported SASL mechanisms
363
364 Added commands:
365 AUTH
366
367 Standard commands affected:
368 none
369
370 Announced states / possible differences:
371 both / no
372
373 Commands valid in states:
374 AUTHENTICATION
375
376 Specification reference:
377 [POP-AUTH, SASL]
378
379 Discussion:
380 The POP3 AUTH command [POP-AUTH] permits the use of [SASL]
381 authentication mechanisms with POP3. The SASL capability
382 indicates that the AUTH command is available and that it supports
383 an optional base64 encoded second argument for an initial client
384 response as described in the SASL specification. The argument to
385 the SASL capability is a space separated list of SASL mechanisms
386 which are supported.
387
388
389
390
391
392
393
394 Gellens, et. al. Standards Track [Page 7]
395
396 RFC 2449 POP3 Extension Mechanism November 1998
397
398
399 6.4. RESP-CODES capability
400
401 CAPA tag:
402 RESP-CODES
403
404 Arguments:
405 none
406
407 Added commands:
408 none
409
410 Standard commands affected:
411 none
412
413 Announced states / possible differences:
414 both / no
415
416 Commands valid in states:
417 n/a
418
419 Specification reference:
420 this document
421
422 Discussion:
423 The RESP-CODES capability indicates that any response text issued
424 by this server which begins with an open square bracket ("[") is
425 an extended response code (see section 8).
426
427 6.5. LOGIN-DELAY capability
428
429 CAPA tag:
430 LOGIN-DELAY
431
432 Arguments:
433 minimum seconds between logins; optionally followed by USER in
434 AUTHENTICATION state.
435
436 Added commands:
437 none
438
439 Standard commands affected:
440 USER PASS APOP AUTH
441
442 Announced states / possible differences:
443 both / yes
444
445 Commands valid in states:
446 n/a
447
448
449
450 Gellens, et. al. Standards Track [Page 8]
451
452 RFC 2449 POP3 Extension Mechanism November 1998
453
454
455 Specification reference:
456 this document
457
458 Discussion:
459 POP3 clients often login frequently to check for new mail.
460 Unfortunately, the process of creating a connection,
461 authenticating the user, and opening the user's maildrop can be
462 very resource intensive on the server. A number of deployed POP3
463 servers try to reduce server load by requiring a delay between
464 logins. The LOGIN-DELAY capability includes an integer argument
465 which indicates the number of seconds after an "+OK" response to
466 a PASS, APOP, or AUTH command before another authentication will
467 be accepted. Clients which permit the user to configure a mail
468 check interval SHOULD use this capability to determine the
469 minimum permissible interval. Servers which advertise LOGIN-
470 DELAY SHOULD enforce it.
471
472 If the minimum login delay period could differ per user (that is,
473 the LOGIN-DELAY argument might change after authentication), the
474 server MUST announce in AUTHENTICATION state the largest value
475 which could be set for any user. This might be the largest value
476 currently in use for any user (so only one value per server), or
477 even the largest value which the server permits to be set for any
478 user. The server SHOULD append the token "USER" to the LOGIN-
479 DELAY parameter in AUTHENTICATION state, to inform the client
480 that a more accurate value is available after authentication.
481 The server SHOULD announce the more accurate value in TRANSACTION
482 state. (The "USER" token allows the client to decide if a second
483 CAPA command is needed or not.)
484
485 Servers enforce LOGIN-DELAY by rejecting an authentication
486 command with or without the LOGIN-DELAY error response. See
487 section 8.1.1 for more information.
488
489 6.6. PIPELINING capability
490
491 CAPA tag:
492 PIPELINING
493
494 Arguments:
495 none
496
497 Added commands:
498 none
499
500 Standard commands affected:
501 all
502
503
504
505
506 Gellens, et. al. Standards Track [Page 9]
507
508 RFC 2449 POP3 Extension Mechanism November 1998
509
510
511 Announced states / possible differences:
512 both / no
513
514 Commands valid in states:
515 n/a
516
517 Specification reference:
518 this document
519
520 Discussion:
521 The PIPELINING capability indicates the server is capable of
522 accepting multiple commands at a time; the client does not have
523 to wait for the response to a command before issuing a subsequent
524 command. If a server supports PIPELINING, it MUST process each
525 command in turn. If a client uses PIPELINING, it MUST keep track
526 of which commands it has outstanding, and match server responses
527 to commands in order. If either the client or server uses
528 blocking writes, it MUST not exceed the window size of the
529 underlying transport layer.
530
531 Some POP3 clients have an option to indicate the server supports
532 "Overlapped POP3 commands." This capability removes the need to
533 configure this at the client.
534
535 This is roughly synonymous with the ESMTP PIPELINING extension
536 [PIPELINING], however, since SMTP [SMTP] tends to have short
537 commands and responses, the benefit is in grouping multiple
538 commands and sending them as a unit. While there are cases of
539 this in POP (for example, USER and PASS could be batched,
540 multiple RETR and/or DELE commands could be sent as a group),
541 because POP has short commands and sometimes lengthy responses,
542 there is also an advantage is sending new commands while still
543 receiving the response to an earlier command (for example,
544 sending RETR and/or DELE commands while processing a UIDL reply).
545
546 6.7. EXPIRE capability
547
548 CAPA tag:
549 EXPIRE
550
551 Arguments:
552 server-guaranteed minimum retention days, or NEVER; optionally
553 followed by USER in AUTHENTICATION state
554
555 Added commands:
556 none
557
558
559
560
561
562 Gellens, et. al. Standards Track [Page 10]
563
564 RFC 2449 POP3 Extension Mechanism November 1998
565
566
567 Standard commands affected:
568 none
569
570 Announced states / possible differences:
571 both / yes
572
573 Commands valid in states:
574 n/a
575
576 Specification reference:
577 this document
578
579 Discussion:
580 While POP3 allows clients to leave messages on the server, RFC
581 1939 [POP3] warns about the problems that may arise from this,
582 and allows servers to delete messages based on site policy.
583
584 The EXPIRE capability avoids the problems mentioned in RFC 1939,
585 by allowing the server to inform the client as to the policy in
586 effect. The argument to the EXPIRE capability indicates the
587 minimum server retention period, in days, for messages on the
588 server.
589
590 EXPIRE 0 indicates the client is not permitted to leave mail on
591 the server; when the session enters the UPDATE state the server
592 MAY assume an implicit DELE for each message which was downloaded
593 with RETR.
594
595 EXPIRE NEVER asserts that the server does not delete messages.
596
597 The concept of a "retention period" is intentionally vague.
598 Servers may start counting days to expiration when a message is
599 added to a maildrop, when a client becomes aware of the existence
600 of a message through the LIST or UIDL commands, when a message
601 has been acted upon in some way (for example, TOP or RETR), or at
602 some other event. The EXPIRE capability cannot provide a precise
603 indication as to exactly when any specific message will expire.
604 The capability is intended to make it easier for clients to
605 behave in ways which conform to site policy and user wishes. For
606 example, a client might display a warning for attempts to
607 configure a "leave mail on server" period which is greater than
608 or equal to some percentage of the value announced by the server.
609
610 If a site uses any automatic deletion policy, it SHOULD use the
611 EXPIRE capability to announce this.
612
613
614
615
616
617
618 Gellens, et. al. Standards Track [Page 11]
619
620 RFC 2449 POP3 Extension Mechanism November 1998
621
622
623 The EXPIRE capability, with a parameter other than 0 or NEVER, is
624 intended to let the client know that the server does permit mail
625 to be left on the server, and to present a value which is the
626 smallest which might be in force.
627
628 Sites which permit users to retain messages indefinitely SHOULD
629 announce this with the EXPIRE NEVER response.
630
631 If the expiration policy differs per user (that is, the EXPIRE
632 argument might change after authentication), the server MUST
633 announce in AUTHENTICATION state the smallest value which could
634 be set for any user. This might be the smallest value currently
635 in use for any user (so only one value per server), or even the
636 smallest value which the server permits to be set for any user.
637 The server SHOULD append the token "USER" to the EXPIRE parameter
638 in AUTHENTICATION state, to inform the client that a more
639 accurate value is available after authentication. The server
640 SHOULD announce the more accurate value in TRANSACTION state.
641 (The "USER" token allows the client to decide if a second CAPA
642 command is needed or not.)
643
644 A site may have a message expiration policy which treats messages
645 differently depending on which user actions have been performed,
646 or based on other factors. For example, a site might delete
647 unseen messages after 60 days, and completely- or partially-seen
648 messages after 15 days.
649
650 The announced EXPIRE value is the smallest retention period which
651 is or might be used by any category or condition of the current
652 site policy, for any user (in AUTHENTICATION state) or the
653 specific user (in TRANSACTION state). That is, EXPIRE informs
654 the client of the minimum number of days messages may remain on
655 the server under any circumstances.
656
657 Examples:
658 EXPIRE 5 USER
659 EXPIRE 30
660 EXPIRE NEVER
661 EXPIRE 0
662
663 The first example indicates the server might delete messages
664 after five days, but the period differs per user, and so a more
665 accurate value can be obtained by issuing a second CAPA command
666 in TRANSACTION state. The second example indicates the server
667 could delete messages after 30 days. In the third example, the
668 server announces it does not delete messages. The fourth example
669 specifies that the site does not permit messages to be left on
670 the server.
671
672
673
674 Gellens, et. al. Standards Track [Page 12]
675
676 RFC 2449 POP3 Extension Mechanism November 1998
677
678
679 6.8. UIDL capability
680
681 CAPA tag:
682 UIDL
683
684 Arguments:
685 none
686
687 Added commands:
688 UIDL
689
690 Standard commands affected:
691 none
692
693 Announced states / possible differences:
694 both / no
695
696 Commands valid in states:
697 TRANSACTION
698
699 Specification reference:
700 [POP3]
701
702 Discussion:
703 The UIDL capability indicates that the optional UIDL command is
704 supported.
705
706 6.9. IMPLEMENTATION capability
707
708 CAPA tag:
709 IMPLEMENTATION
710
711 Arguments:
712 string giving server implementation information
713
714 Added commands:
715 none
716
717 Standard commands affected:
718 none
719
720 Announced states / possible differences:
721 both (optionally TRANSACTION only) / no
722
723 Commands valid in states:
724 n/a
725
726
727
728
729
730 Gellens, et. al. Standards Track [Page 13]
731
732 RFC 2449 POP3 Extension Mechanism November 1998
733
734
735 Specification reference:
736 this document
737
738 Discussion:
739 It is often useful to identify an implementation of a particular
740 server (for example, when logging). This is commonly done in the
741 welcome banner, but one must guess if a string is an
742 implementation ID or not.
743
744 The argument to the IMPLEMENTATION capability consists of one or
745 more tokens which identify the server. (Note that since CAPA
746 response tag arguments are space-separated, it may be convenient
747 for the IMPLEMENTATION capability argument to not contain spaces,
748 so that it is a single token.)
749
750 Normally, servers announce IMPLEMENTATION in both states.
751 However, a server MAY chose to do so only in TRANSACTION state.
752
753 A server MAY include the implementation identification both in
754 the welcome banner and in the IMPLEMENTATION capability.
755
756 Clients MUST NOT modify their behavior based on the server
757 implementation. Instead the server and client should agree on a
758 private extension.
759
760 7. Future Extensions to POP3
761
762 Future extensions to POP3 are in general discouraged, as POP3's
763 usefulness lies in its simplicity. POP3 is intended as a download-
764 and-delete protocol; mail access capabilities are available in IMAP
765 [IMAP4]. Extensions which provide support for additional mailboxes,
766 allow uploading of messages to the server, or which deviate from
767 POP's download-and-delete model are strongly discouraged and unlikely
768 to be permitted on the IETF standards track.
769
770 Clients MUST NOT require the presence of any extension for basic
771 functionality, with the exception of the authentication commands
772 (APOP, AUTH [section 6.3] and USER/PASS).
773
774 Section 9 specifies how additional capabilities are defined.
775
776 8. Extended POP3 Response Codes
777
778 Unextended POP3 is only capable of indicating success or failure to
779 most commands. Unfortunately, clients often need to know more
780 information about the cause of a failure in order to gracefully
781 recover. This is especially important in response to a failed login
782
783
784
785
786 Gellens, et. al. Standards Track [Page 14]
787
788 RFC 2449 POP3 Extension Mechanism November 1998
789
790
791 (there are widely-deployed clients which attempt to decode the error
792 text of a PASS command result, to try and distinguish between "unable
793 to get maildrop lock" and "bad login").
794
795 This specification amends the POP3 standard to permit an optional
796 response code, enclosed in square brackets, at the beginning of the
797 human readable text portion of an "+OK" or "-ERR" response. Clients
798 supporting this extension MAY remove any information enclosed in
799 square brackets prior to displaying human readable text to the user.
800 Immediately following the open square bracket "[" character is a
801 response code which is interpreted in a case-insensitive fashion by
802 the client.
803
804 The response code is hierarchical, with a "/" separating levels of
805 detail about the error. Clients MUST ignore unknown hierarchical
806 detail about the response code. This is important, as it could be
807 necessary to provide further detail for response codes in the future.
808
809 Section 3 describes response codes using [ABNF].
810
811 If a server supports extended response codes, it indicates this by
812 including the RESP-CODES capability in the CAPA response.
813
814 Examples:
815 C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
816 S: -ERR [IN-USE] Do you have another POP session running?
817
818 8.1. Initial POP3 response codes
819
820 This specification defines two POP3 response codes which can be used
821 to determine the reason for a failed login. Section 9 specifies how
822 additional response codes are defined.
823
824 8.1.1. The LOGIN-DELAY response code
825
826 This occurs on an -ERR response to an AUTH, USER (see note), PASS or
827 APOP command and indicates that the user has logged in recently and
828 will not be allowed to login again until the login delay period has
829 expired.
830
831 NOTE: Returning the LOGIN-DELAY response code to the USER command
832 avoids the work of authenticating the user but reveals to the client
833 that the specified user exists. Unless the server is operating in an
834 environment where user names are not secret (for example, many
835 popular email clients advertise the POP server and user name in an
836 outgoing mail header), or where server access is restricted, or the
837 server can verify that the connection is to the same user, it is
838
839
840
841
842 Gellens, et. al. Standards Track [Page 15]
843
844 RFC 2449 POP3 Extension Mechanism November 1998
845
846
847 strongly recommended that the server not issue this response code to
848 the USER command. The server still saves the cost of opening the
849 maildrop, which in some environments is the most expensive step.
850
851 8.1.2. The IN-USE response code
852
853 This occurs on an -ERR response to an AUTH, APOP, or PASS command.
854 It indicates the authentication was successful, but the user's
855 maildrop is currently in use (probably by another POP3 client).
856
857 9. IANA Considerations
858
859 This document requests that IANA maintain two new registries: POP3
860 capabilities and POP3 response codes.
861
862 New POP3 capabilities MUST be defined in a standards track or IESG
863 approved experimental RFC, and MUST NOT begin with the letter "X".
864
865 New POP3 capabilities MUST include the following information:
866 CAPA tag
867 Arguments
868 Added commands
869 Standard commands affected
870 Announced states / possible differences
871 Commands valid in states
872 Specification reference
873 Discussion
874
875 In addition, new limits for POP3 command and response lengths may
876 need to be included.
877
878 New POP3 response codes MUST be defined in an RFC or other permanent
879 and readily available reference, in sufficient detail so that
880 interoperability between independent implementations is possible.
881 (This is the "Specification Required" policy described in [IANA]).
882
883 New POP3 response code specifications MUST include the following
884 information: the complete response code, for which responses (+OK
885 or -ERR) and commands it is valid, and a definition of its meaning and
886 expected client behavior.
887
888
889
890
891
892
893
894
895
896
897
898 Gellens, et. al. Standards Track [Page 16]
899
900 RFC 2449 POP3 Extension Mechanism November 1998
901
902
903 10. Security Considerations
904
905 A capability list can reveal information about the server's
906 authentication mechanisms which can be used to determine if certain
907 attacks will be successful. However, allowing clients to
908 automatically detect availability of stronger mechanisms and alter
909 their configurations to use them can improve overall security at a
910 site.
911
912 Section 8.1 discusses the security issues related to use of the
913 LOGIN-DELAY response code with the USER command.
914
915 11. Acknowledgments
916
917 This document has been revised in part based on comments and
918 discussions which took place on and off the IETF POP3 Extensions
919 mailing list. The help of those who took the time to review this
920 memo and make suggestions is appreciated, especially that of Alexey
921 Melnikov, Harald Alvestrand, and Mike Gahrns.
922
923 12. References
924
925 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
926 Specifications: ABNF", RFC 2234, November 1997.
927
928 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
929 IANA Considerations Section in RFCs", BCP 26, RFC 2434,
930 October 1998.
931
932 [IMAP4] Crispin, M., "Internet Message Access Protocol --
933 Version 4rev1", RFC 2060, December 1996.
934
935 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
936 Requirement Levels", BCP 14, RFC 2119, March 1997.
937
938 [PIPELINING] Freed, N., "SMTP Service Extension for Command
939 Pipelining", RFC 2197, September 1997.
940
941 [POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version
942 3", STD 53, RFC 1939, May 1996.
943
944 [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
945 December 1994.
946
947 [SASL] Myers, J., "Simple Authentication and Security Layer
948 (SASL)", RFC 2222, October 1997.
949
950
951
952
953
954 Gellens, et. al. Standards Track [Page 17]
955
956 RFC 2449 POP3 Extension Mechanism November 1998
957
958
959 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
960 821, August 1982.
961
962 13. Authors' Addresses
963
964 Randall Gellens
965 QUALCOMM Incorporated
966 6455 Lusk Blvd.
967 San Diego, CA 92121-2779
968 USA
969
970 Phone: +1 619 651 5115
971 Fax: +1 619 845 7268
972 EMail: randy@qualcomm.com
973
974
975 Chris Newman
976 Innosoft International, Inc.
977 1050 Lakes Drive
978 West Covina, CA 91790
979 USA
980
981 EMail: chris.newman@innosoft.com
982
983
984 Laurence Lundblade
985 QUALCOMM Incorporated
986 6455 Lusk Blvd.
987 San Diego, Ca, 92121-2779
988 USA
989
990 Phone: +1 619 658 3584
991 Fax: +1 619 845 7268
992 EMail: lgl@qualcomm.com
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010 Gellens, et. al. Standards Track [Page 18]
1011
1012 RFC 2449 POP3 Extension Mechanism November 1998
1013
1014
1015 14. Full Copyright Statement
1016
1017 Copyright (C) The Internet Society (1998). All Rights Reserved.
1018
1019 This document and translations of it may be copied and furnished to
1020 others, and derivative works that comment on or otherwise explain it
1021 or assist in its implementation may be prepared, copied, published
1022 and distributed, in whole or in part, without restriction of any
1023 kind, provided that the above copyright notice and this paragraph are
1024 included on all such copies and derivative works. However, this
1025 document itself may not be modified in any way, such as by removing
1026 the copyright notice or references to the Internet Society or other
1027 Internet organizations, except as needed for the purpose of
1028 developing Internet standards in which case the procedures for
1029 copyrights defined in the Internet Standards process must be
1030 followed, or as required to translate it into languages other than
1031 English.
1032
1033 The limited permissions granted above are perpetual and will not be
1034 revoked by the Internet Society or its successors or assigns.
1035
1036 This document and the information contained herein is provided on an
1037 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1038 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1039 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1040 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1041 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066 Gellens, et. al. Standards Track [Page 19]
1067