1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
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
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
POP3 Extension Mechanism
(last updated 2001 Jun 29)
The POP3 Extension Mechanism [RFC 2449] updates RFC 1939 to define a
mechanism to announce support for optional commands, extensions, and
unconditional server behavior. Included is an initial set of
currently deployed capabilities which vary between server
implementations, and several new capabilities (SASL, RESP-CODES,
LOGIN-DELAY, PIPELINING, EXPIRE and IMPLEMENTATION). The RFC also
extends POP3 error messages so that machine parsable codes can be
provided to the client.
POP3 capabilities
New POP3 capabilities MUST be defined in a standards track or IESG
approved experimental RFC, and MUST NOT begin with the letter "X".
New POP3 capabilities MUST include the following information:
CAPA tag
Arguments
Added commands
Standard commands affected
Announced states / possible differences
Commands valid in states
Specification reference
Discussion
Initial Set of Capabilities
TOP [RFC2449]
USER [RFC2449]
SASL [RFC2449]
RESP-CODES [RFC2449]
LOGIN-DELAY [RFC2449]
PIPELINING [RFC2449]
EXPIRE [RFC2449]
UIDL [RFC2449]
IMPLEMENTATION [RFC2449]
POP3 Response Codes
New POP3 response codes MUST be defined in an RFC or other permanent
and readily available reference, in sufficient detail so that
interoperability between independent implementations is possible.
New POP3 response code specifications MUST include the following
information: the complete response code, for which responses (+OK or
-ERR) and commands it is valid, and a definition of its meaning and
expectedNew POP3 response codes MUST be defined in an RFC or other
permanent and readily available reference, in sufficient detail so
that interoperability between independent implementations is possible.
New POP3 response code specifications MUST include the following
information: the complete response code, for which responses (+OK or
-ERR) and commands it is valid, and a definition of its meaning and
expected client behavior.
This document requests that IANA maintain two new registries: POP3
capabilities and POP3 response codes.
New POP3 capabilities MUST be defined in a standards track or IESG
approved experimental RFC, and MUST NOT begin with the letter "X".
New POP3 capabilities MUST include the following information:
CAPA tag
Arguments
Added commands
Standard commands affected
Announced states / possible differences
Commands valid in states
Specification reference
Discussion
In addition, new limits for POP3 command and response lengths may
need to be included.
New POP3 response codes MUST be defined in an RFC or other
permanent and readily available reference, in sufficient detail so that
interoperability between independent implementations is possible.
(This is the "Specification Required" policy described in [IANA]).
New POP3 response codes MUST be defined in an RFC or other
permanent and readily available reference, in sufficient detail so
that interoperability between independent implementations is
possible. (This is the "Specification Required" policy described
in [IANA]).
New POP3 response code specifications MUST include the following
information: the complete response code, for which responses (+OK
or -ERR) and commands it is valid, and a definition of its meaning and
expected client behavior.
CAPA tag CAPA Args Added cmds Affected List Diffs Cmd Valid References
-------- --------- ---------- -------- ---- ----- --------- ----------
TOP none TOP none both no TRANSACTION [RFC2449,
RFC1939]
USER none USER,PASS none both no AUTHENTICAT [RFC2449,
RFC1939]
SASL mech list AUTH none both no AUTHENTICAT [RFC2449,
RFC1734]
RESP-CODES none none none both no n/a [RFC2449]
LOGIN-DELAY secs&USER none USER,PASS both yes n/a [RFC2449]
APOP,AUTH
PIPELINING none none all both no n/a [RFC2449]
EXPIRE days/ none none both yes n/a [RFC2449]
NEVER&USER
UIDL none UIDL none both no TRANSACTION [RFC2449,
RFC1939]
IMPLEMENTATION text none none TRANS/both no n/a [RFC2449,
RFC1939]
STLS none STLS USER, both no AUTHENTICAT [RFC2595]
PASS,CAPA
Response Code Response Types Commands Reference
------------- -------------- -------- ---------
LOGIN-DELAY -ERR USER*,PASS,APOP,AUTH [RFC2449]
IN-USE -ERR PASS,APOP,AUTH [RFC2449]
* - see spec for details
REFERENCES
----------
[RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, December
1994.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol -- Version 3",
STD 53, RFC 1939, May 1996.
[RFC2449] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension
Mechanism", RFC 2449, November 1998.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
Innosoft, June 1999.
[]
|
