Skip to content

John McEleney / mailutils

Go to a project
Toggle navigation
Toggle navigation pinning
Commit 34e0ea26 34e0ea264af7c44463eef1c06fff8b1d428b34de by Sergey Poznyakoff
Options

Remove uncompatibly-copyrighted material. 

* configure.ac: Remove doc/rfc/Makefile.am
* doc/Makefile.am (SUBDIRS): Remove rfc.
(EXTRA_DIST): Add rfc/README.
* doc/rfc/README: New file.
* doc/rfc/CMC_V1.PS.gz: Remove.
* doc/rfc/Makefile.am: Remove.
* doc/rfc/rfc1413.txt: Remove.
* doc/rfc/rfc1521.txt: Remove.
* doc/rfc/rfc1731.txt: Remove.
* doc/rfc/rfc1734.txt: Remove.
* doc/rfc/rfc1738.txt: Remove.
* doc/rfc/rfc1870.txt: Remove.
* doc/rfc/rfc1891.txt: Remove.
* doc/rfc/rfc1892.txt: Remove.
* doc/rfc/rfc1893.txt: Remove.
* doc/rfc/rfc1894.txt: Remove.
* doc/rfc/rfc1939.txt: Remove.
* doc/rfc/rfc1957.txt: Remove.
* doc/rfc/rfc2045.txt: Remove.
* doc/rfc/rfc2046.txt: Remove.
* doc/rfc/rfc2047.txt: Remove.
* doc/rfc/rfc2049.txt: Remove.
* doc/rfc/rfc2060-errata
* doc/rfc/rfc2060.txt: Remove.
* doc/rfc/rfc2087.txt: Remove.
* doc/rfc/rfc2088.txt: Remove.
* doc/rfc/rfc2111.txt: Remove.
* doc/rfc/rfc2177.txt: Remove.
* doc/rfc/rfc2180.txt: Remove.
* doc/rfc/rfc2192.txt: Remove.
* doc/rfc/rfc2193.txt: Remove.
* doc/rfc/rfc2195.txt: Remove.
* doc/rfc/rfc2221.txt: Remove.
* doc/rfc/rfc2222.txt: Remove.
* doc/rfc/rfc2231.txt: Remove.
* doc/rfc/rfc2245.txt: Remove.
* doc/rfc/rfc2298.txt: Remove.
* doc/rfc/rfc2342.txt: Remove.
* doc/rfc/rfc2368.txt: Remove.
* doc/rfc/rfc2384.txt: Remove.
* doc/rfc/rfc2444.txt: Remove.
* doc/rfc/rfc2449.txt: Remove.
* doc/rfc/rfc2595.txt: Remove.
* doc/rfc/rfc2683.txt: Remove.
* doc/rfc/rfc2808.txt: Remove.
* doc/rfc/rfc2821.txt: Remove.
* doc/rfc/rfc2822.txt: Remove.
* doc/rfc/rfc2831.txt: Remove.
* doc/rfc/rfc3028.txt: Remove.
* doc/rfc/rfc3206.txt: Remove.
* doc/rfc/rfc3348.txt: Remove.
* doc/rfc/rfc3431.txt: Remove.
* doc/rfc/rfc3501.txt: Remove.
* doc/rfc/rfc3691.txt: Remove.
* doc/rfc/rfc4314.txt: Remove.
* doc/rfc/rfc821.txt: Remove.
* doc/rfc/rfc822.txt: Remove.
* doc/rfc/rfc934.txt: Remove.
* doc/rfc/sasl-mechanisms: Remove.
1 parent bd8c3722
Expand all
Inline Side-by-side
Showing 58 changed files with 57 additions and 2885 deletions
...@@ -1327,7 +1327,6 @@ AC_CONFIG_FILES([ ...@@ -1327,7 +1327,6 @@ AC_CONFIG_FILES([
1327 config/Makefile 1327 config/Makefile
1328 doc/Makefile 1328 doc/Makefile
1329 doc/man/Makefile 1329 doc/man/Makefile
1330 doc/rfc/Makefile
1331 doc/texinfo/Makefile 1330 doc/texinfo/Makefile
1332 dotlock/Makefile 1331 dotlock/Makefile
1333 examples/Makefile 1332 examples/Makefile
......
...@@ -18,5 +18,5 @@ ...@@ -18,5 +18,5 @@
18 ## Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 18 ## Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA
19 ## 02110-1301 USA 19 ## 02110-1301 USA
20 20
21 SUBDIRS = texinfo rfc man 21 SUBDIRS = texinfo man
22 EXTRA_DIST = ChangeLog.CVS 22 EXTRA_DIST = ChangeLog.CVS rfc/README
......
No preview for this file type
1 ## Process this file with GNU Automake to create Makefile.in
2
3 ## Copyright (C) 2001, 2002, 2003, 2007, 2008, 2010 Free Software
4 ## Foundation, Inc.
5 ##
6 ## GNU Mailutils is free software; you can redistribute it and/or
7 ## modify it under the terms of the GNU General Public License as
8 ## published by the Free Software Foundation; either version 3, or (at
9 ## your option) any later version.
10 ##
11 ## GNU Mailutils is distributed in the hope that it will be useful, but
12 ## WITHOUT ANY WARRANTY; without even the implied warranty of
13 ## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
14 ## General Public License for more details.
15 ##
16 ## You should have received a copy of the GNU General Public License
17 ## along with GNU Mailutils; if not, write to the Free Software
18 ## Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA
19 ## 02110-1301 USA
20
21 EXTRA_DIST = \
22 rfc821.txt\
23 rfc822.txt\
24 rfc934.txt\
25 rfc1413.txt\
26 rfc1521.txt\
27 rfc1731.txt\
28 rfc1734.txt\
29 rfc1738.txt\
30 rfc1870.txt\
31 rfc1939.txt\
32 rfc1957.txt\
33 rfc2045.txt\
34 rfc2046.txt\
35 rfc2047.txt\
36 rfc2049.txt\
37 rfc2060.txt\
38 rfc2060-errata\
39 rfc2087.txt\
40 rfc2088.txt\
41 rfc2111.txt\
42 rfc2177.txt\
43 rfc2180.txt\
44 rfc2192.txt\
45 rfc2193.txt\
46 rfc2221.txt\
47 rfc2245.txt\
48 rfc2298.txt\
49 rfc2231.txt\
50 rfc2342.txt\
51 rfc2368.txt\
52 rfc2384.txt\
53 rfc2449.txt\
54 rfc2595.txt\
55 rfc2683.txt\
56 rfc2821.txt\
57 rfc2822.txt\
58 rfc3028.txt\
59 rfc3206.txt\
60 rfc3431.txt\
61 rfc3501.txt\
62 rfc3691.txt\
63 rfc3348.txt\
64 rfc4314.txt
1 This is a list of RFCs used when designing GNU Mailutils. To read any
2 of them, visit http://tools.ietf.org/html/rfcNNNN, replacing NNNN with
3 the actual RFC number.
4
5 821 SIMPLE MAIL TRANSFER PROTOCOL
6 822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES
7 934 Proposed Standard for Message Encapsulation
8 1413 Identification Protocol
9 1521 MIME Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
10 1731 IMAP4 Authentication Mechanisms
11 1734 POP3 AUTHentication command
12 1738 Uniform Resource Locators (URL)
13 1870 SMTP Service Extension for Message Size Declaration
14 1891 SMTP Service Extension for Delivery Status Notifications
15 1892 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
16 1893 Enhanced Mail System Status Codes
17 1894 An Extensible Message Format for Delivery Status Notifications
18 1939 Post Office Protocol - Version 3
19 1957 Some Observations on Implementations of the Post Office Protocol (POP3)
20 2045 MIME Part One: Format of Internet Message Bodies
21 2046 MIME Part Two: Media Types
22 2047 MIME Part Three: Message Header Extensions for Non-ASCII Text
23 2049 MIME Part Five: Conformance Criteria and Examples
24 2060 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 (+ rfc2060-errata)
25 2087 IMAP4 QUOTA extension
26 2088 IMAP4 non-synchronizing literals
27 2111 Content-ID and Message-ID Uniform Resource Locators
28 2177 IMAP4 IDLE command
29 2180 IMAP4 Multi-Accessed Mailbox Practice
30 2192 IMAP URL Scheme
31 2193 IMAP4 Mailbox Referrals
32 2195 IMAP/POP AUTHorize Extension for Simple Challenge/Response
33 2221 IMAP4 Login Referrals
34 2222 Simple Authentication and Security Layer (SASL)
35 2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
36 2245 Anonymous SASL Mechanism
37 2298 An Extensible Message Format for Message Disposition Notifications
38 2342 IMAP4 Namespace
39 2368 The mailto URL scheme
40 2384 POP URL Scheme
41 2444 The One-Time-Password SASL Mechanism
42 2449 POP3 Extension Mechanism
43 2595 Using TLS with IMAP, POP3 and ACAP
44 2683 IMAP4 Implementation Recommendations
45 2808 The SecurID(r) SASL Mechanism
46 2821 Simple Mail Transfer Protocol
47 2822 Internet Message Format
48 2831 Using Digest Authentication as a SASL Mechanism
49 3028 Sieve: A Mail Filtering Language
50 3206 The SYS and AUTH POP Response Codes
51 3348 The Internet Message Action Protocol (IMAP4) Child Mailbox Extension
52 3431 Sieve Extension: Relational Tests
53 3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
54 3691 Internet Message Access Protocol (IMAP) UNSELECT command
55 4314 IMAP4 Access Control List (ACL) Extension
This diff could not be displayed because it is too large.
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 G. Vaudreuil
8 Request for Comments: 1892 Octel Network Services
9 Category: Standards Track January 1996
10
11
12 The Multipart/Report Content Type
13 for the Reporting of
14 Mail System Administrative Messages
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 1. The Multipart/Report MIME content-type
25
26 The Multipart/Report MIME content-type is a general "family" or
27 "container" type for electronic mail reports of any kind. Although
28 this memo defines only the use of the Multipart/Report content-type
29 with respect to delivery status reports, mail processing programs
30 will benefit if a single content-type is used to for all kinds of
31 reports.
32
33 The Multipart/Report content-type is defined as follows:
34
35 MIME type name: multipart
36 MIME subtype name: report
37 Required parameters: boundary, report-type
38 Optional parameters: none
39 Encoding considerations: 7bit should always be adequate
40 Security considerations: see section 4 of this memo.
41
42 The syntax of Multipart/Report is identical to the Multipart/Mixed
43 content type defined in [MIME]. When used to send a report, the
44 Multipart/Report content-type must be the top-level MIME content type
45 for any report message. The report-type parameter identifies the
46 type of report. The parameter is the MIME content sub-type of the
47 second body part of the Multipart/Report.
48
49 User agents and gateways must be able to automatically determine
50 that a message is a mail system report and should be processed as
51 such. Placing the Multipart/Report as the outermost content
52 provides a mechanism whereby an auto-processor may detect through
53 parsing the RFC 822 headers that the message is a report.
54
55
56
57
58 Vaudreuil Standards Track [Page 1]
59
60 RFC 1892 Multipart/Report January 1996
61
62
63 The Multipart/Report content-type contains either two or three sub-
64 parts, in the following order:
65
66 (1) [required] The first body part contains human readable message.
67 The purpose of this message is to provide an easily-understood
68 description of the condition(s) that caused the report to be
69 generated, for a human reader who may not have an user agent
70 capable of interpreting the second section of the
71 Multipart/Report.
72
73 The text in the first section may be in any MIME standards-track
74 content-type, charset, or language. Where a description of the
75 error is desired in several languages or several media, a
76 Multipart/Alternative construct may be used.
77
78 This body part may also be used to send detailed information
79 that cannot be easily formatted into a Message/Report body part.
80
81 (2) [required] A machine parsable body part containing an account
82 of the reported message handling event. The purpose of this body
83 part is to provide a machine-readable description of the
84 condition(s) which caused the report to be generated, along with
85 details not present in the first body part that may be useful to
86 human experts. An initial body part, Message/delivery-status is
87 defined in [DSN]
88
89 (3) [optional] A body part containing the returned message or a
90 portion thereof. This information may be useful to aid human
91 experts in diagnosing problems. (Although it may also be useful
92 to allow the sender to identify the message which the report was
93 issued, it is hoped that the envelope-id and original-recipient-
94 address returned in the Message/Report body part will replace
95 the traditional use of the returned content for this purpose.)
96
97 Return of content may be wasteful of network bandwidth and a variety
98 of implementation strategies can be used. Generally the sender
99 should choose the appropriate strategy and inform the recipient of
100 the required level of returned content required. In the absence of
101 an explicit request for level of return of content such as that
102 provided in [DRPT], the agent which generated the delivery service
103 report should return the full message content.
104
105 When data not encoded in 7 bits is to be returned, and the return
106 path is not guaranteed to be 8-bit capable, two options are
107 available. The origional message MAY be reencoded into a legal 7 bit
108 MIME message or the Text/RFC822-Headers content-type MAY be used to
109 return only the origional message headers.
110
111
112
113
114 Vaudreuil Standards Track [Page 2]
115
116 RFC 1892 Multipart/Report January 1996
117
118
119 2. The Text/RFC822-Headers MIME content-type
120
121 The Text/RFC822-Headers MIME content-type provides a mechanism to
122 label and return only the RFC 822 headers of a failed message. These
123 headers are not the complete message and should not be returned as a
124 Message/RFC822. The returned headers are useful for identifying the
125 failed message and for diagnostics based on the received: lines.
126
127 The Text/RFC822-Headers content-type is defined as follows:
128
129 MIME type name: Text
130 MIME subtype name: RFC822-Headers
131 Required parameters: None
132 Optional parameters: none
133 Encoding considerations: 7 bit is sufficient for normal RFC822
134 headers, however, if the headers are broken and require
135 encoding, they may be encoded in quoted-printable.
136 Security considerations: see section 4 of this memo.
137
138 The Text/RFC822-headers body part should contain all the RFC822
139 header lines from the message which caused the report. The RFC822
140 headers include all lines prior to the blank line in the message.
141 They include the MIME-Version and MIME Content- headers.
142
143 3. References
144
145 [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
146 Delivery Status Notifications", RFC 1894, University of
147 Tennessee, Octel Network Services, January 1996.
148
149 [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text
150 Messages", STD 11, RFC 822, UDEL, August 1982.
151
152 [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
153 Extensions", RFC 1521, Bellcore, Innosoft, June 1992.
154
155 [DRPT] Moore, K., "SMTP Service Extension for Delivery Status
156 Notifications", RFC 1891, University of Tennessee, January 1996.
157
158 4. Security Considerations
159
160 Automated use of report types without authentication presents several
161 security issues. Forging negative reports presents the opportunity
162 for denial-of-service attacks when the reports are used for automated
163 maintenance of directories or mailing lists. Forging positive
164 reports may cause the sender to incorrectly believe a message was
165 delivered when it was not.
166
167
168
169
170 Vaudreuil Standards Track [Page 3]
171
172 RFC 1892 Multipart/Report January 1996
173
174
175 5. Author's Address
176
177 Gregory M. Vaudreuil
178 Octel Network Services
179 17060 Dallas Parkway
180 Dallas, TX 75248-1905
181
182 Phone: +1-214-733-2722
183 EMail: Greg.Vaudreuil@Octel.com
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226 Vaudreuil Standards Track [Page 4]
227
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 Known errors in RFC 2060 as of 13 September 1998:
2
3 1) The SELECT and EXAMINE response list does not mention UIDVALIDITY.
4
5 2) In the definition of store_att_flags, #flag should be 1#flag; in other
6 words, at least one flag must be given. To do an empty list of flags,
7 you must use the parenthesized form: "()".
8
9 3) The example in 6.4.6 is missing parenthesis around the FETCH attributes.
10 It should read:
11
12 Example: C: A003 STORE 2:4 +FLAGS (\Deleted)
13 S: * 2 FETCH (FLAGS (\Deleted \Seen))
14 S: * 3 FETCH (FLAGS (\Deleted))
15 S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen))
16 S: A003 OK STORE completed
17
18 4) Section 7.4.2 has an example of "a two part message consisting of a
19 text and a BASE645-encoded text attachment". "BASE645" should be
20 BASE64.
21
22 5) In the example in 7.4.2 discussed above, there is a spurious close
23 parenthesis at the end of the example.
24
25 6) Spurious obsolete response "MAILBOX" is listed in mailbox_data and
26 should be removed.
27
28 7) There is a spurious "<" in the mailbox_data rule that should be removed.
29
30 8) CRLF is missing from the continue_req rule.
31
32 9) The atom in resp_text_code should specifically exclude "]".
33
34 10) The example in 6.3.11 does not show the command continuation request.
35
36 11) NEWNAME is missing from resp_text_code.
37
38 12) There is a missing open parenthesis in the media_basic grammar rule.
39
40 13) Status attributes are incorrectly defined in mailbox_data rule.
41
42 14) The UID FETCH example is missing an "OK" in the response.
43
44 15) Multipart extension data incorrectly specifies that language must be
45 given along with disposition.
This diff could not be displayed because it is too large.
1
2
3
4
5
6
7 Network Working Group J. Myers
8 Request for Comments: 2087 Carnegie Mellon
9 Category: Standards Track January 1997
10
11
12 IMAP4 QUOTA extension
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 1. Abstract
23
24 The QUOTA extension of the Internet Message Access Protocol [IMAP4]
25 permits administrative limits on resource usage (quotas) to be
26 manipulated through the IMAP protocol.
27
28 Table of Contents
29
30 1. Abstract........................................... 1
31 2. Conventions Used in this Document.................. 1
32 3. Introduction and Overview.......................... 2
33 4. Commands........................................... 2
34 4.1. SETQUOTA Command................................... 2
35 4.2. GETQUOTA Command................................... 2
36 4.3. GETQUOTAROOT Command............................... 3
37 5. Responses.......................................... 3
38 5.1. QUOTA Response..................................... 3
39 5.2. QUOTAROOT Response................................. 4
40 6. Formal syntax...................................... 4
41 7. References......................................... 5
42 8. Security Considerations............................ 5
43 9. Author's Address................................... 5
44
45
46 2. Conventions Used in this Document
47
48 In examples, "C:" and "S:" indicate lines sent by the client and
49 server respectively.
50
51
52
53
54
55
56
57
58 Myers Standards Track [Page 1]
59
60 RFC 2087 QUOTA January 1997
61
62
63 3. Introduction and Overview
64
65 The QUOTA extension is present in any IMAP4 implementation which
66 returns "QUOTA" as one of the supported capabilities to the
67 CAPABILITY command.
68
69 An IMAP4 server which supports the QUOTA capability may support
70 limits on any number of resources. Each resource has an atom name
71 and an implementation-defined interpretation which evaluates to an
72 integer. Examples of such resources are:
73
74 Name Interpretation
75
76 STORAGE Sum of messages' RFC822.SIZE, in units of 1024 octets
77 MESSAGE Number of messages
78
79
80 Each mailbox has zero or more implementation-defined named "quota
81 roots". Each quota root has zero or more resource limits. All
82 mailboxes that share the same named quota root share the resource
83 limits of the quota root.
84
85 Quota root names do not necessarily have to match the names of
86 existing mailboxes.
87
88 4. Commands
89
90 4.1. SETQUOTA Command
91
92 Arguments: quota root
93 list of resource limits
94
95 Data: untagged responses: QUOTA
96
97 Result: OK - setquota completed
98 NO - setquota error: can't set that data
99 BAD - command unknown or arguments invalid
100
101 The SETQUOTA command takes the name of a mailbox quota root and a
102 list of resource limits. The resource limits for the named quota root
103 are changed to be the specified limits. Any previous resource limits
104 for the named quota root are discarded.
105
106 If the named quota root did not previously exist, an implementation
107 may optionally create it and change the quota roots for any number of
108 existing mailboxes in an implementation-defined manner.
109
110
111
112
113
114 Myers Standards Track [Page 2]
115
116 RFC 2087 QUOTA January 1997
117
118
119 Example: C: A001 SETQUOTA "" (STORAGE 512)
120 S: * QUOTA "" (STORAGE 10 512)
121 S: A001 OK Setquota completed
122
123 4.2. GETQUOTA Command
124
125 Arguments: quota root
126
127 Data: untagged responses: QUOTA
128
129 Result: OK - getquota completed
130 NO - getquota error: no such quota root, permission
131 denied
132 BAD - command unknown or arguments invalid
133
134 The GETQUOTA command takes the name of a quota root and returns the
135 quota root's resource usage and limits in an untagged QUOTA response.
136
137 Example: C: A003 GETQUOTA ""
138 S: * QUOTA "" (STORAGE 10 512)
139 S: A003 OK Getquota completed
140
141 4.3. GETQUOTAROOT Command
142
143 Arguments: mailbox name
144
145 Data: untagged responses: QUOTAROOT, QUOTA
146
147 Result: OK - getquota completed
148 NO - getquota error: no such mailbox, permission denied
149 BAD - command unknown or arguments invalid
150
151 The GETQUOTAROOT command takes the name of a mailbox and returns the
152 list of quota roots for the mailbox in an untagged QUOTAROOT
153 response. For each listed quota root, it also returns the quota
154 root's resource usage and limits in an untagged QUOTA response.
155
156 Example: C: A003 GETQUOTAROOT INBOX
157 S: * QUOTAROOT INBOX ""
158 S: * QUOTA "" (STORAGE 10 512)
159 S: A003 OK Getquota completed
160
161
162
163
164
165
166
167
168
169
170 Myers Standards Track [Page 3]
171
172 RFC 2087 QUOTA January 1997
173
174
175 5. Responses
176
177 5.1. QUOTA Response
178
179 Data: quota root name
180 list of resource names, usages, and limits
181
182 This response occurs as a result of a GETQUOTA or GETQUOTAROOT
183 command. The first string is the name of the quota root for which
184 this quota applies.
185
186 The name is followed by a S-expression format list of the resource
187 usage and limits of the quota root. The list contains zero or
188 more triplets. Each triplet conatins a resource name, the current
189 usage of the resource, and the resource limit.
190
191 Resources not named in the list are not limited in the quota root.
192 Thus, an empty list means there are no administrative resource
193 limits in the quota root.
194
195 Example: S: * QUOTA "" (STORAGE 10 512)
196
197 5.2. QUOTAROOT Response
198
199 Data: mailbox name
200 zero or more quota root names
201
202 This response occurs as a result of a GETQUOTAROOT command. The
203 first string is the mailbox and the remaining strings are the
204 names of the quota roots for the mailbox.
205
206 Example: S: * QUOTAROOT INBOX ""
207 S: * QUOTAROOT comp.mail.mime
208
209 6. Formal syntax
210
211 The following syntax specification uses the augmented Backus-Naur
212 Form (BNF) notation as specified in RFC 822 with one exception; the
213 delimiter used with the "#" construct is a single space (SP) and not
214 one or more commas.
215
216 Except as noted otherwise, all alphabetic characters are case-
217 insensitive. The use of upper or lower case characters to define
218 token strings is for editorial clarity only. Implementations MUST
219 accept these strings in a case-insensitive fashion.
220
221
222
223
224
225
226 Myers Standards Track [Page 4]
227
228 RFC 2087 QUOTA January 1997
229
230
231 getquota ::= "GETQUOTA" SP astring
232
233 getquotaroot ::= "GETQUOTAROOT" SP astring
234
235 quota_list ::= "(" #quota_resource ")"
236
237 quota_resource ::= atom SP number SP number
238
239 quota_response ::= "QUOTA" SP astring SP quota_list
240
241 quotaroot_response
242 ::= "QUOTAROOT" SP astring *(SP astring)
243
244 setquota ::= "SETQUOTA" SP astring SP setquota_list
245
246 setquota_list ::= "(" 0#setquota_resource ")"
247
248 setquota_resource ::= atom SP number
249
250 7. References
251
252 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
253 RFC 1730, University of Washington, December 1994.
254
255 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
256 Text Messages", STD 11, RFC 822.
257
258 8. Security Considerations
259
260 Implementors should be careful to make sure the implementation of
261 these commands does not violate the site's security policy. The
262 resource usage of other users is likely to be considered confidential
263 information and should not be divulged to unauthorized persons.
264
265 9. Author's Address
266
267 John G. Myers
268 Carnegie-Mellon University
269 5000 Forbes Ave.
270 Pittsburgh PA, 15213-3890
271
272 EMail: jgm+@cmu.edu
273
274
275
276
277
278
279
280
281
282 Myers Standards Track [Page 5]
283
284
1
2
3
4
5
6
7 Network Working Group J. Myers
8 Request for Comments: 2088 Carnegie Mellon
9 Cateogry: Standards Track January 1997
10
11
12 IMAP4 non-synchronizing literals
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 1. Abstract
23
24 The Internet Message Access Protocol [IMAP4] contains the "literal"
25 syntactic construct for communicating strings. When sending a
26 literal from client to server, IMAP4 requires the client to wait for
27 the server to send a command continuation request between sending the
28 octet count and the string data. This document specifies an
29 alternate form of literal which does not require this network round
30 trip.
31
32 2. Conventions Used in this Document
33
34 In examples, "C:" and "S:" indicate lines sent by the client and
35 server respectively.
36
37 3. Specification
38
39 The non-synchronizing literal is added an alternate form of literal,
40 and may appear in communication from client to server instead of the
41 IMAP4 form of literal. The IMAP4 form of literal, used in
42 communication from client to server, is referred to as a
43 synchronizing literal.
44
45 Non-synchronizing literals may be used with any IMAP4 server
46 implementation which returns "LITERAL+" as one of the supported
47 capabilities to the CAPABILITY command. If the server does not
48 advertise the LITERAL+ capability, the client must use synchronizing
49 literals instead.
50
51 The non-synchronizing literal is distinguished from the original
52 synchronizing literal by having a plus ('+') between the octet count
53 and the closing brace ('}'). The server does not generate a command
54 continuation request in response to a non-synchronizing literal, and
55
56
57
58 Myers Standards Track [Page 1]
59
60 RFC 2088 LITERAL January 1997
61
62
63 clients are not required to wait before sending the octets of a non-
64 synchronizing literal.
65
66 The protocol receiver of an IMAP4 server must check the end of every
67 received line for an open brace ('{') followed by an octet count, a
68 plus ('+'), and a close brace ('}') immediately preceeding the CRLF.
69 If it finds this sequence, it is the octet count of a non-
70 synchronizing literal and the server MUST treat the specified number
71 of following octets and the following line as part of the same
72 command. A server MAY still process commands and reject errors on a
73 line-by-line basis, as long as it checks for non-synchronizing
74 literals at the end of each line.
75
76 Example: C: A001 LOGIN {11+}
77 C: FRED FOOBAR {7+}
78 C: fat man
79 S: A001 OK LOGIN completed
80
81 4. Formal Syntax
82
83 The following syntax specification uses the augmented Backus-Naur
84 Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
85 Non-terminals referenced but not defined below are as defined by
86 [IMAP4].
87
88 literal ::= "{" number ["+"] "}" CRLF *CHAR8
89 ;; Number represents the number of CHAR8 octets
90
91 6. References
92
93 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
94 draft-crispin-imap-base-XX.txt, University of Washington, April 1996.
95
96 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
97 Messages", STD 11, RFC 822.
98
99 7. Security Considerations
100
101 There are no known security issues with this extension.
102
103 8. Author's Address
104
105 John G. Myers
106 Carnegie-Mellon University
107 5000 Forbes Ave.
108 Pittsburgh PA, 15213-3890
109
110 Email: jgm+@cmu.edu
111
112
113
114 Myers Standards Track [Page 2]
115
1
2
3
4
5
6
7 Network Working Group E. Levinson
8 Request for Comments: 2111 XIson, Inc.
9 Category: Standards Track March 1997
10
11
12 Content-ID and Message-ID Uniform Resource Locators
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 Abstract
23
24 The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow
25 references to messages and the body parts of messages. For example,
26 within a single multipart message, one HTML body part might include
27 embedded references to other parts of the same message.
28
29 1. Introduction
30
31 The use of [MIME] within email to convey Web pages and their
32 associated images requires a URL scheme to permit the HTML to refer
33 to the images or other data included in the message. The Content-ID
34 Uniform Resource Locator, "cid:", serves that purpose.
35
36 Similarly Net News readers use Message-IDs to link related messages
37 together. The Message-ID URL provides a scheme, "mid:", to refer to
38 such messages as a "resource".
39
40 The "mid" (Message-ID) and "cid" (Content-ID) URL schemes provide
41 identifiers for messages and their body parts. The "mid" scheme uses
42 (a part of) the message-id of an email message to refer to a specific
43 message. The "cid" scheme refers to a specific body part of a
44 message; its use is generally limited to references to other body
45 parts in the same message as the referring body part. The "mid"
46 scheme may also refer to a specific body part within a designated
47 message, by including the content-ID's address.
48
49 A note on terminology. The terms "body part" and "MIME entity" are
50 used interchangeably. They refer to the headers and body of a MIME
51 message, either the message itself or one of the body parts contained
52 in a Multipart message.
53
54
55
56
57
58 Levinson Standards Track [Page 1]
59
60 RFC 2111 CID and MID URLs March 1997
61
62
63 2. The MID and CID URL Schemes
64
65 RFC1738 [URL] reserves the "mid" and "cid" schemes for Message-ID and
66 Content-ID respectively. This memorandum defines the syntax for
67 those URLs. Because they use the same syntactic elements they are
68 presented together.
69
70 The URLs take the form
71
72 content-id = url-addr-spec
73
74 message-id = url-addr-spec
75
76 url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec
77
78 cid-url = "cid" ":" content-id
79
80 mid-url = "mid" ":" message-id [ "/" content-id ]
81
82 Note: in Internet mail messages, the addr-spec in a Content-ID
83 [MIME] or Message-ID [822] header are enclosed in angle brackets
84 (<>). Since addr-spec in a Message-ID or Content-ID might contain
85 characters not allowed within a URL; any such character (including
86 "/", which is reserved within the "mid" scheme) must be hex-
87 encoded using the %hh escape mechanism in [URL].
88
89 A "mid" URL with only a "message-id" refers to an entire message.
90 With the appended "content-id", it refers to a body part within a
91 message, as does a "cid" URL. The Content-ID of a MIME body part is
92 required to be globally unique. However, in many systems that store
93 messages, body parts are not indexed independently their context
94 (message). The "mid" URL long form was designed to supply the
95 context needed to support interoperability with such systems.
96
97 A implementation conforming to this specification is required to
98 support the "mid" URL long form (message-id/content-id). Conforming
99 implementations can choose to, but are not required to, take
100 advantage of the content-id's uniqueness and interpret a "cid" URL to
101 refer to any body part within the message store.
102
103 In limited circumstances (e.g., within multipart/alternate), a single
104 message may contain several body parts that have the same Content-ID.
105 That occurs, for example, when identical data can be accessed through
106 different methods [MIME, sect. 7.2.3]. In those cases, conforming
107 implementations are required to use the rules of the containing MIME
108 entity (e.g., multi-part/alternate) to select the body part to which
109 the Content-ID refers.
110
111
112
113
114 Levinson Standards Track [Page 2]
115
116 RFC 2111 CID and MID URLs March 1997
117
118
119 A "cid" URL is converted to the corresponding Content-ID message
120 header [MIME] by removing the "cid:" prefix, converting %hh hex-
121 escaped characters to their ASCII equivalents and enclosing the
122 remaining parts with an angle bracket pair, "<" and ">". For
123 example, "mid:foo4%25foo1@bar.net" corresponds to
124
125 Message-ID: <foo4%foo1@bar.net>
126
127 A "mid" URL is converted to a Message-ID or Message-ID/Content-ID
128 pair in a similar fashion.
129
130 Both message-id and content-id are required to be globally unique.
131 That is, no two different messages will ever have the same Message-ID
132 addr-spec; no different body parts will ever have the same Content-ID
133 addr-spec. A common technique used by many message systems is to use
134 a time and date stamp along with the local host's domain name, e.g.,
135 950124.162336@XIson.com.
136
137 Some Examples
138
139 The following message contains an HTML body part that refers to an
140 image contained in another body part. Both body parts are contained
141 in a Multipart/Related MIME entity. The HTML IMG tag contains a
142 cidurl which points to the image.
143
144 From: foo1@bar.net
145 To: foo2@bar.net
146 Subject: A simple example
147 Mime-Version: 1.0
148 Content-Type: multipart/related; boundary="boundary-example-1";
149 type=Text/HTML
150
151 --boundary-example 1
152 Content-Type: Text/HTML; charset=US-ASCII
153
154 ... text of the HTML document, which might contain a hyperlink
155 to the other body part, for example through a statement such as:
156 <IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo">
157
158 --boundary-example-1
159 Content-ID: foo4*foo1@bar.net
160 Content-Type: IMAGE/GIF
161 Content-Transfer-Encoding: BASE64
162
163
164
165
166
167
168
169
170 Levinson Standards Track [Page 3]
171
172 RFC 2111 CID and MID URLs March 1997
173
174
175 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
176 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
177 etc...
178
179 --boundary-example-1--
180
181 The following message points to another message (hopefully still in
182 the recipient's message store).
183
184 From: bar@none.com
185 To: phooey@all.com
186 Subject: Here's how to do it
187 Content-type: text/html; charset=usascii
188
189 ... The items in my
190 <A HREF= "mid:960830.1639@XIson.com/partA.960830.1639@XIson.com">
191 previous message</A>, shows how the approach you propose can be
192 used to accomplish ...
193
194 3. Security Considerations
195
196 The URLs defined here provide an addressing or referencing mechanism.
197 The values of these URLs disclose no more about the originators
198 environment than the corresponding Message-ID and Content-ID values.
199 Where concern exists about such disclosures the originator of a
200 message using mid and cid URLs must take precautions to insure that
201 confidential information is not disclosed. Those precautions should
202 already be in place to handle existing mail use of the Message-ID and
203 Content-ID.
204
205 4. References
206
207 [822] Crocker, D., "Standard for the Format of ARPA Internet Text
208 Messages," August 1982, University of Delaware, STD 11, RFC
209 822.
210
211 [MIME] N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail
212 Extensions) Part One: Mechanisms for Specifying and
213 Describing the Format of Internet Message Bodies,"
214 September 1993, RFC 1521.
215
216 [URL] Berners-Lee, T., Masinter, L., and McCahill, M., "Uniform
217 Resource Locators (URL)," December 1994.
218
219 [MULREL] E. Levinson, "The MIME Multipart/Related Content-type,"
220 December 1995, RFC 1874.
221
222
223
224
225
226 Levinson Standards Track [Page 4]
227
228 RFC 2111 CID and MID URLs March 1997
229
230
231 5. Acknowledgments
232
233 The original concept of "mid" and "cid" URLs were part of the Tim
234 Berners-Lee's original vision of the World Wide Web. The ideas and
235 design have benefited greatly by discussions with Harald Alvestrand,
236 Dan Connolly, Roy Fielding, Larry Masinter, Jacob Palme, and others
237 in the MHTML working group.
238
239 6. Author's Address
240
241 Edward Levinson
242 47 Clive Street
243 Metuchen, NJ 08840-1060
244 USA
245 +1 908 549 3716
246 <XIson@cnj.digex.net>
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282 Levinson Standards Track [Page 5]
283
1
2 Network Working Group
3 Request for Comments: 2177
4 Category: Standards Track
5 B. Leiba
6 IBM T.J. Watson Research Center
7 June 1997
8
9 Page 1
10
11 IMAP4 IDLE command
12
13 Status of this Memo
14 This document specifies an Internet standards track protocol
15 for the Internet community, and requests discussion and
16 suggestions for improvements. Please refer to the current
17 edition of the "Internet Official Protocol Standards" (STD 1)
18 for the standardization state and status of this protocol.
19 Distribution of this memo is unlimited.
20
21 1 Abstract
22 The Internet Message Access Protocol [IMAP4] requires a client
23 to poll the server for changes to the selected mailbox (new
24 mail, deletions). It's often more desirable to have the server
25 transmit updates to the client in real time. This allows a user
26 to see new mail immediately. It also helps some real-time
27 applications based on IMAP, which might otherwise need to poll
28 extremely often (such as every few seconds). (While the spec
29 actually does allow a server to push EXISTS responses
30 aysynchronously, a client can't expect this behaviour and must
31 poll.)
32
33 This document specifies the syntax of an IDLE command, which
34 will allow a client to tell the server that it's ready to
35 accept such real-time updates.
36
37 2 Conventions Used in this Document
38 In examples, "C:" and "S:" indicate lines sent by the client
39 and server respectively.
40
41 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and
42 "MAY" in this document are to be interpreted as described in
43 RFC 2060 [IMAP4].
44
45 3 Specification
46 IDLE Command
47
48 Arguments: none
49
50 Responses: continuation data will be requested; the client
51 sends the continuation data "DONE" to end the command
52 __________________________________________________________
53
54 Page 2
55
56 Result: OK - IDLE completed after client sent "DONE"
57 NO - failure: the server will not allow the IDLE
58 command at this time
59 BAD - command unknown or arguments invalid
60
61 The IDLE command may be used with any IMAP4 server
62 implementation that returns "IDLE" as one of the supported
63 capabilities to the CAPABILITY command. If the server does not
64 advertise the IDLE capability, the client MUST NOT use the IDLE
65 command and must poll for mailbox updates. In particular, the
66 client MUST continue to be able to accept unsolicited untagged
67 responses to ANY command, as specified in the base IMAP
68 specification.
69
70 The IDLE command is sent from the client to the server when the
71 client is ready to accept unsolicited mailbox update messages.
72 The server requests a response to the IDLE command using the
73 continuation ("+") response. The IDLE command remains active
74 until the client responds to the continuation, and as long as
75 an IDLE command is active, the server is now free to send
76 untagged EXISTS, EXPUNGE, and other messages at any time.
77
78 The IDLE command is terminated by the receipt of a "DONE"
79 continuation from the client; such response satisfies the
80 server's continuation request. At that point, the server MAY
81 send any remaining queued untagged responses and then MUST
82 immediately send the tagged response to the IDLE command and
83 prepare to process other commands. As in the base
84 specification, the processing of any new command may cause the
85 sending of unsolicited untagged responses, subject to the
86 ambiguity limitations. The client MUST NOT send a command while
87 the server is waiting for the DONE, since the server will not
88 be able to distinguish a command from a continuation.
89
90 The server MAY consider a client inactive if it has an IDLE
91 command running, and if such a server has an inactivity timeout
92 it MAY log the client off implicitly at the end of its timeout
93 period. Because of that, clients using IDLE are advised to
94 terminate the IDLE and re-issue it at least every 29 minutes to
95 avoid being logged off. This still allows a client to receive
96 immediate mailbox updates even though it need only "poll" at
97 half hour intervals.
98 __________________________________________________________
99
100 Page 3
101
102 Example: C: A001 SELECT INBOX
103 S: * FLAGS (Deleted Seen)
104 S: * 3 EXISTS
105 S: * 0 RECENT
106 S: * OK [UIDVALIDITY 1]
107 S: A001 OK SELECT completed
108 C: A002 IDLE
109 S: + idling
110 ...time passes; new mail arrives...
111 S: * 4 EXISTS
112 C: DONE
113 S: A002 OK IDLE terminated
114 ...another client expunges message 2 now...
115 C: A003 FETCH 4 ALL
116 S: * 4 FETCH (...)
117 S: A003 OK FETCH completed
118 C: A004 IDLE
119 S: * 2 EXPUNGE
120 S: * 3 EXISTS
121 S: + idling
122 ...time passes; another client expunges message 3...
123 S: * 3 EXPUNGE
124 S: * 2 EXISTS
125 ...time passes; new mail arrives...
126 S: * 3 EXISTS
127 C: DONE
128 S: A004 OK IDLE terminated
129 C: A005 FETCH 3 ALL
130 S: * 3 FETCH (...)
131 S: A005 OK FETCH completed
132 C: A006 IDLE
133
134 4 Formal Syntax
135 The following syntax specification uses the augmented
136 Backus-Naur Form (BNF) notation as specified in [RFC-822] as
137 modified by [IMAP4]. Non-terminals referenced but not defined
138 below are as defined by [IMAP4].
139
140 command_auth ::= append / create / delete / examine / list / lsub /
141 rename / select / status / subscribe / unsubscribe
142 / idle
143 ;; Valid only in Authenticated or Selected state
144
145 idle ::= "IDLE" CRLF "DONE"
146 __________________________________________________________
147
148 Page 4
149
150 5 References
151 [IMAP4] Crispin, M., "Internet Message Access Protocol -
152 Version 4rev1", RFC 2060, December 1996.
153
154 6 Security Considerations
155 There are no known security issues with this extension.
156
157 7 Author's Address
158 Barry Leiba
159 IBM T.J. Watson Research Center
160 30 Saw Mill River Road
161 Hawthorne, NY 10532
162
163 Email: leiba@watson.ibm.com
164 __________________________________________________________
1
2
3
4
5
6
7 Network Working Group M. Gahrns
8 Request for Comments: 2221 Microsoft
9 Category: Standards Track October 1997
10
11
12 IMAP4 Login Referrals
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 Copyright Notice
23
24 Copyright (C) The Internet Society (1997). All Rights Reserved.
25
26 1. Abstract
27
28 When dealing with large amounts of users and many IMAP4 [RFC-2060]
29 servers, it is often necessary to move users from one IMAP4 server to
30 another. For example, hardware failures or organizational changes
31 may dictate such a move.
32
33 Login referrals allow clients to transparently connect to an
34 alternate IMAP4 server, if their home IMAP4 server has changed.
35
36 A referral mechanism can provide efficiencies over the alternative
37 'proxy method', in which the local IMAP4 server contacts the remote
38 server on behalf of the client, and then transfers the data from the
39 remote server to itself, and then on to the client. The referral
40 mechanism's direct client connection to the remote server is often a
41 more efficient use of bandwidth, and does not require the local
42 server to impersonate the client when authenticating to the remote
43 server.
44
45 2. Conventions used in this document
46
47 In examples, "C:" and "S:" indicate lines sent by the client and
48 server respectively.
49
50 A home server, is an IMAP4 server that contains the user's inbox.
51
52 A remote server is a server that contains remote mailboxes.
53
54
55
56
57
58 Gahrns Standards Track [Page 1]
59
60 RFC 2221 IMAP4 Login Referrals October 1997
61
62
63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
65 document are to be interpreted as described in [RFC-2119].
66
67 3. Introduction and Overview
68
69 IMAP4 servers that support this extension MUST list the keyword
70 LOGIN-REFERRALS in their CAPABILITY response. No client action is
71 needed to invoke the LOGIN-REFERRALS capability in a server.
72
73 A LOGIN-REFERRALS capable IMAP4 server SHOULD NOT return a referral
74 to a server that will return a referral. A client MUST NOT follow
75 more than 10 levels of referral without consulting the user.
76
77 A LOGIN-REFERRALS response code MUST contain as an argument a valid
78 IMAP server URL as defined in [IMAP-URL].
79
80 A home server referral consists of either a tagged NO or OK, or an
81 untagged BYE response that contains a LOGIN-REFERRALS response code.
82
83 Example: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/] Remote Server
84
85 NOTE: user;AUTH=* is specified as required by [IMAP-URL] to avoid a
86 client falling back to anonymous login.
87
88 4. Home Server Referrals
89
90 A home server referral may be returned in response to an AUTHENTICATE
91 or LOGIN command, or it may appear in the connection startup banner.
92 If a server returns a home server referral in a tagged NO response,
93 that server does not contain any mailboxes that are accessible to the
94 user. If a server returns a home server referral in a tagged OK
95 response, it indicates that the user's personal mailboxes are
96 elsewhere, but the server contains public mailboxes which are
97 readable by the user. After receiving a home server referral, the
98 client can not make any assumptions as to whether this was a
99 permanent or temporary move of the user.
100
101 4.1. LOGIN and AUTHENTICATE Referrals
102
103 An IMAP4 server MAY respond to a LOGIN or AUTHENTICATE command with a
104 home server referral if it wishes to direct the user to another IMAP4
105 server.
106
107 Example: C: A001 LOGIN MIKE PASSWORD
108 S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified user
109 is invalid on this server. Try SERVER2.
110
111
112
113
114 Gahrns Standards Track [Page 2]
115
116 RFC 2221 IMAP4 Login Referrals October 1997
117
118
119 Example: C: A001 LOGIN MATTHEW PASSWORD
120 S: A001 OK [REFERRAL IMAP://MATTHEW@SERVER2/] Specified
121 user's personal mailboxes located on Server2, but
122 public mailboxes are available.
123
124 Example: C: A001 AUTHENTICATE GSSAPI
125 <authentication exchange>
126 S: A001 NO [REFERRAL IMAP://user;AUTH=GSSAPI@SERVER2/]
127 Specified user is invalid on this server. Try
128 SERVER2.
129
130 4.2. BYE at connection startup referral
131
132 An IMAP4 server MAY respond with an untagged BYE and a REFERRAL
133 response code that contains an IMAP URL to a home server if it is not
134 willing to accept connections and wishes to direct the client to
135 another IMAP4 server.
136
137 Example: S: * BYE [REFERRAL IMAP://user;AUTH=*@SERVER2/] Server not
138 accepting connections. Try SERVER2
139
140 5. Formal Syntax
141
142 The following syntax specification uses the augmented Backus-Naur
143 Form (BNF) as described in [ABNF].
144
145 This amends the "resp_text_code" element of the IMAP4 grammar
146 described in [RFC-2060]
147
148 resp_text_code =/ "REFERRAL" SPACE <imapurl>
149 ; See [IMAP-URL] for definition of <imapurl>
150 ; See [RFC-2060] for base definition of resp_text_code
151
152 6. Security Considerations
153
154 The IMAP4 login referral mechanism makes use of IMAP URLs, and as
155 such, have the same security considerations as general internet URLs
156 [RFC-1738], and in particular IMAP URLs [IMAP-URL].
157
158 A server MUST NOT give a login referral if authentication for that
159 user fails. This is to avoid revealing information about the user's
160 account to an unauthorized user.
161
162 With the LOGIN-REFERRALS capability, it is potentially easier to
163 write a rogue 'password catching' server that collects login data and
164 then refers the client to their actual IMAP4 server. Although
165 referrals reduce the effort to write such a server, the referral
166 response makes detection of the intrusion easier.
167
168
169
170 Gahrns Standards Track [Page 3]
171
172 RFC 2221 IMAP4 Login Referrals October 1997
173
174
175 7. References
176
177 [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
178 4rev1", RFC 2060, December 1996.
179
180 [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft,
181 September 1997.
182
183 [RFC-1738], Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
184 Resource Locators (URL)", RFC 1738, December 1994.
185
186 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
187 Requirement Levels", RFC 2119, March 1997.
188
189 [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
190 Syntax Specifications: ABNF", Work in Progress.
191
192 8. Acknowledgments
193
194 Many valuable suggestions were received from private discussions and
195 the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin,
196 Mark Keasling Chris Newman and Larry Osterman made significant
197 contributions to this document.
198
199 9. Author's Address
200
201 Mike Gahrns
202 Microsoft
203 One Microsoft Way
204 Redmond, WA, 98072
205
206 Phone: (206) 936-9833
207 EMail: mikega@microsoft.com
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226 Gahrns Standards Track [Page 4]
227
228 RFC 2221 IMAP4 Login Referrals October 1997
229
230
231 10. Full Copyright Statement
232
233 Copyright (C) The Internet Society (1997). All Rights Reserved.
234
235 This document and translations of it may be copied and furnished to
236 others, and derivative works that comment on or otherwise explain it
237 or assist in its implmentation may be prepared, copied, published
238 andand distributed, in whole or in part, without restriction of any
239 kind, provided that the above copyright notice and this paragraph are
240 included on all such copies and derivative works. However, this
241 document itself may not be modified in any way, such as by removing
242 the copyright notice or references to the Internet Society or other
243 Internet organizations, except as needed for the purpose of
244 developing Internet standards in which case the procedures for
245 copyrights defined in the Internet Standards process must be
246 followed, or as required to translate it into languages other than
247 English.
248
249 The limited permissions granted above are perpetual and will not be
250 revoked by the Internet Society or its successors or assigns.
251
252 This document and the information contained herein is provided on an
253 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
254 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
255 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
256 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
257 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282 Gahrns Standards Track [Page 5]
283
1
2
3
4
5
6
7 Network Working Group C. Newman
8 Request for Comments: 2245 Innosoft
9 Category: Standards Track November 1997
10
11
12 Anonymous SASL Mechanism
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 Copyright Notice
23
24 Copyright (C) The Internet Society (1997). All Rights Reserved.
25
26 Abstract
27
28 It is common practice on the Internet to permit anonymous access to
29 various services. Traditionally, this has been done with a plain
30 text password mechanism using "anonymous" as the user name and
31 optional trace information, such as an email address, as the
32 password. As plaintext login commands are not permitted in new IETF
33 protocols, a new way to provide anonymous login is needed within the
34 context of the SASL [SASL] framework.
35
36 1. Conventions Used in this Document
37
38 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
39 in this document are to be interpreted as defined in "Key words for
40 use in RFCs to Indicate Requirement Levels" [KEYWORDS].
41
42 2. Anonymous SASL mechanism
43
44 The mechanism name associated with anonymous access is "ANONYMOUS".
45 The mechanism consists of a single message from the client to the
46 server. The client sends optional trace information in the form of a
47 human readable string. The trace information should take one of
48 three forms: an Internet email address, an opaque string which does
49 not contain the '@' character and can be interpreted by the system
50 administrator of the client's domain, or nothing. For privacy
51 reasons, an Internet email address should only be used with
52 permission from the user.
53
54
55
56
57
58 Newman Standards Track [Page 1]
59
60 RFC 2245 Anonymous SASL Mechanism November 1997
61
62
63 A server which permits anonymous access will announce support for the
64 ANONYMOUS mechanism, and allow anyone to log in using that mechanism,
65 usually with restricted access.
66
67 The formal grammar for the client message using Augmented BNF [ABNF]
68 follows.
69
70 message = [email / token]
71
72 TCHAR = %x20-3F / %x41-7E
73 ;; any printable US-ASCII character except '@'
74
75 email = addr-spec
76 ;; as defined in [IMAIL], except with no free
77 ;; insertion of linear-white-space, and the
78 ;; local-part MUST either be entirely enclosed in
79 ;; quotes or entirely unquoted
80
81 token = 1*255TCHAR
82
83 3. Example
84
85
86 Here is a sample anonymous login between an IMAP client and server.
87 In this example, "C:" and "S:" indicate lines sent by the client and
88 server respectively. If such lines are wrapped without a new "C:" or
89 "S:" label, then the wrapping is for editorial clarity and is not
90 part of the command.
91
92 Note that this example uses the IMAP profile [IMAP4] of SASL. The
93 base64 encoding of challenges and responses, as well as the "+ "
94 preceding the responses are part of the IMAP4 profile, not part of
95 SASL itself. Newer profiles of SASL will include the client message
96 with the AUTHENTICATE command itself so the extra round trip below
97 (the server response with an empty "+ ") can be eliminated.
98
99 In this example, the user's opaque identification token is "sirhc".
100
101 S: * OK IMAP4 server ready
102 C: A001 CAPABILITY
103 S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=ANONYMOUS
104 S: A001 OK done
105 C: A002 AUTHENTICATE ANONYMOUS
106 S: +
107 C: c2lyaGM=
108 S: A003 OK Welcome, trace information has been logged.
109
110
111
112
113
114 Newman Standards Track [Page 2]
115
116 RFC 2245 Anonymous SASL Mechanism November 1997
117
118
119 4. Security Considerations
120
121 The anonymous mechanism grants access to information by anyone. For
122 this reason it should be disabled by default so the administrator can
123 make an explicit decision to enable it.
124
125 If the anonymous user has any write privileges, a denial of service
126 attack is possible by filling up all available space. This can be
127 prevented by disabling all write access by anonymous users.
128
129 If anonymous users have read and write access to the same area, the
130 server can be used as a communication mechanism to anonymously
131 exchange information. Servers which accept anonymous submissions
132 should implement the common "drop box" model which forbids anonymous
133 read access to the area where anonymous submissions are accepted.
134
135 If the anonymous user can run many expensive operations (e.g., an
136 IMAP SEARCH BODY command), this could enable a denial of service
137 attack. Servers are encouraged to limit the number of anonymous
138 users and reduce their priority or limit their resource usage.
139
140 If there is no idle timeout for the anonymous user and there is a
141 limit on the number of anonymous users, a denial of service attack is
142 enabled. Servers should implement an idle timeout for anonymous
143 users.
144
145 The trace information is not authenticated so it can be falsified.
146 This can be used as an attempt to get someone else in trouble for
147 access to questionable information. Administrators trying to trace
148 abuse need to realize this information may be falsified.
149
150 A client which uses the user's correct email address as trace
151 information without explicit permission may violate that user's
152 privacy. Information about who accesses an anonymous archive on a
153 sensitive subject (e.g., sexual abuse) has strong privacy needs.
154 Clients should not send the email address without explicit permission
155 of the user and should offer the option of supplying no trace token
156 -- thus only exposing the source IP address and time. Anonymous
157 proxy servers could enhance this privacy, but would have to consider
158 the resulting potential denial of service attacks.
159
160 Anonymous connections are susceptible to man in the middle attacks
161 which view or alter the data transferred. Clients and servers are
162 encouraged to support external integrity and encryption mechanisms.
163
164 Protocols which fail to require an explicit anonymous login are more
165 susceptible to break-ins given certain common implementation
166 techniques. Specifically, Unix servers which offer user login may
167
168
169
170 Newman Standards Track [Page 3]
171
172 RFC 2245 Anonymous SASL Mechanism November 1997
173
174
175 initially start up as root and switch to the appropriate user id
176 after an explicit login command. Normally such servers refuse all
177 data access commands prior to explicit login and may enter a
178 restricted security environment (e.g., the Unix chroot function) for
179 anonymous users. If anonymous access is not explicitly requested,
180 the entire data access machinery is exposed to external security
181 attacks without the chance for explicit protective measures.
182 Protocols which offer restricted data access should not allow
183 anonymous data access without an explicit login step.
184
185 5. References
186
187 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
188 Specifications: ABNF", RFC 2234, November 1997.
189
190 [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text
191 Messages", STD 11, RFC 822, August 1982.
192
193 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
194 4rev1", RFC 2060, December 1996.
195
196 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
197 Requirement Levels", RFC 2119, March 1997.
198
199 [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)",
200 RFC 2222, October 1997.
201
202 6. Author's Address
203
204 Chris Newman
205 Innosoft International, Inc.
206 1050 Lakes Drive
207 West Covina, CA 91790 USA
208
209 Email: chris.newman@innosoft.com
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226 Newman Standards Track [Page 4]
227
228 RFC 2245 Anonymous SASL Mechanism November 1997
229
230
231 7. Full Copyright Statement
232
233 Copyright (C) The Internet Society (1997). All Rights Reserved.
234
235 This document and translations of it may be copied and furnished to
236 others, and derivative works that comment on or otherwise explain it
237 or assist in its implementation may be prepared, copied, published
238 and distributed, in whole or in part, without restriction of any
239 kind, provided that the above copyright notice and this paragraph are
240 included on all such copies and derivative works. However, this
241 document itself may not be modified in any way, such as by removing
242 the copyright notice or references to the Internet Society or other
243 Internet organizations, except as needed for the purpose of
244 developing Internet standards in which case the procedures for
245 copyrights defined in the Internet Standards process must be
246 followed, or as required to translate it into languages other than
247 English.
248
249 The limited permissions granted above are perpetual and will not be
250 revoked by the Internet Society or its successors or assigns.
251
252 This document and the information contained herein is provided on an
253 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
254 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
255 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
256 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
257 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282 Newman Standards Track [Page 5]
283
This diff could not be displayed because it is too large.
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: 3206 QUALCOMM
9 Category: Standards Track February 2002
10
11
12 The SYS and AUTH POP Response Codes
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 Copyright Notice
23
24 Copyright (C) The Internet Society (2002). All Rights Reserved.
25
26 Abstract
27
28 This memo proposes two response codes: SYS and AUTH, which enable
29 clients to unambiguously determine an optimal response to an
30 authentication failure. In addition, a new capability (AUTH-RESP-
31 CODE) is defined.
32
33 Table of Contents
34
35 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
36 2. Conventions Used in this Document . . . . . . . . . . . . . . 2
37 3. Background . . . . . . . . . . . . . . . . . . . . . . . . 2
38 4. The SYS Response Code . . . . . . . . . . . . . . . . . . . 3
39 5. The AUTH Response Code . . . . . . . . . . . . . . . . . . 3
40 6. The AUTH-RESP-CODE Capability . . . . . . . . . . . . . . . 4
41 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 4
42 8. Security Considerations . . . . . . . . . . . . . . . . . . 4
43 9. References . . . . . . . . . . . . . . . . . . . . . . . . 5
44 10. Author's Address . . . . . . . . . . . . . . . . . . . . . . 5
45 11. Full Copyright Statement . . . . . . . . . . . . . . . . . 6
46
47
48
49
50
51
52
53
54
55
56
57
58 Gellens Standards Track [Page 1]
59
60 RFC 3206 The SYS and AUTH POP Response Codes February 2002
61
62
63
64 1. Introduction
65
66 RFC 2449 [POP3-EXT] defined extended [POP3] response codes, to give
67 clients more information about errors so clients can respond more
68 appropriately. In addition to the mechanism, two initial response
69 codes were defined (IN-USE and LOGIN-DELAY), in an attempt to
70 differentiate between authentication failures related to user
71 credentials, and other errors.
72
73 In practice, these two response codes, while helpful, do not go far
74 enough. This memo proposes two additional response codes: SYS and
75 AUTH, which enable clients to unambiguously determine an optimal
76 response to an authentication failure.
77
78 In addition, a new capability (AUTH-RESP-CODE) is defined.
79
80 2. Conventions Used in this Document
81
82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
84 document are to be interpreted as described in RFC 2119 [KEYWORDS].
85
86 3. Background
87
88 RFC 2449 [POP3-EXT] introduced the IN-USE and LOGIN-DELAY response
89 codes. The intent is to allow clients to clearly determine the
90 underlying cause of a failure in order to respond. For example,
91 clients need to know if the user should be asked for new credentials,
92 or if the POP3 session should simply be tried again later. (Some
93 deployed POP3 clients attempt to parse the text of authentication
94 failure errors, looking for strings known to be issued by various
95 servers which indicate the mailbox is locked.)
96
97 IN-USE indicates that an exclusive lock could not be obtained for the
98 user's mailbox, probably because another POP3 session is in progress.
99 LOGIN-DELAY informs the client that the user has not waited long
100 enough before authenticating again.
101
102 However, there are other error conditions which do not require new
103 credentials, some of which should be brought to the user's attention.
104
105 Despite the IN-USE and LOGIN-DELAY responses, clients cannot be sure
106 if any other error requires new user credentials.
107
108
109
110
111
112
113
114 Gellens Standards Track [Page 2]
115
116 RFC 3206 The SYS and AUTH POP Response Codes February 2002
117
118
119 4. The SYS Response Code
120
121 The SYS response code announces that a failure is due to a system
122 error, as opposed to the user's credentials or an external condition.
123 It is hierarchical, with two possible second-level codes: TEMP and
124 PERM. (Case is not significant at any level of the hierarchy.)
125
126 SYS/TEMP indicates a problem which is likely to be temporary in
127 nature, and therefore there is no need to alarm the user, unless the
128 failure persists. Examples might include a central resource which is
129 currently locked or otherwise temporarily unavailable, insufficient
130 free disk or memory, etc.
131
132 SYS/PERM is used for problems which are unlikely to be resolved
133 without intervention. It is appropriate to alert the user and
134 suggest that the organization's support or assistance personnel be
135 contacted. Examples include corrupted mailboxes, system
136 configuration errors, etc.
137
138 The SYS response code is valid with an -ERR response to any command.
139
140 5. The AUTH Response Code
141
142 The AUTH response code informs the client that there is a problem
143 with the user's credentials. This might be an incorrect password, an
144 unknown user name, an expired account, an attempt to authenticate in
145 violation of policy (such as from an invalid location or during an
146 unauthorized time), or some other problem.
147
148 The AUTH response code is valid with an -ERR response to any
149 authentication command including AUTH, USER (see note), PASS, or
150 APOP.
151
152 Servers which include the AUTH response code with any authentication
153 failure SHOULD support the CAPA command [POP3-EXT] and SHOULD include
154 the AUTH-RESP-CODE capability in the CAPA response. AUTH-RESP-CODE
155 assures the client that only errors with the AUTH code are caused by
156 credential problems.
157
158 NOTE: Returning the AUTH response code to the USER command
159 reveals to the client that the specified user exists. It is
160 strongly RECOMMENDED that the server not issue this response code
161 to the USER command.
162
163
164
165
166
167
168
169
170 Gellens Standards Track [Page 3]
171
172 RFC 3206 The SYS and AUTH POP Response Codes February 2002
173
174
175 6. The AUTH-RESP-CODE Capability
176
177 CAPA tag:
178 AUTH-RESP-CODE
179
180 Arguments:
181 none
182
183 Added commands:
184 none
185
186 Standard commands affected:
187 none
188
189 Announced states / possible differences:
190 both / no
191
192 Commands valid in states:
193 n/a
194
195 Specification reference:
196 this document
197
198 Discussion:
199 The AUTH-RESP-CODE capability indicates that the server includes
200 the AUTH response code with any authentication error caused by a
201 problem with the user's credentials.
202
203 7. IANA Considerations
204
205 IANA has added the AUTH-RESP-CODE capability to the list of POP3
206 capabilities (established by RFC 2449 [POP3-EXT]).
207
208 IANA has also added the SYS and AUTH response codes to the list of
209 POP3 response codes (also established by RFC 2449 [POP3-EXT]).
210
211 8. Security Considerations
212
213 Section 5, The AUTH Response Code, discusses the security issues
214 related to use of the AUTH response code with the USER command.
215
216
217
218
219
220
221
222
223
224
225
226 Gellens Standards Track [Page 4]
227
228 RFC 3206 The SYS and AUTH POP Response Codes February 2002
229
230
231 9. References
232
233 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
234 Requirement Levels", BCP 14, RFC 2119, March 1997.
235
236 [POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version
237 3", STD 53, RFC 1939, May 1996.
238
239 [POP3-EXT] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension
240 Mechanism", RFC 2449, November 1998.
241
242 10. Author's Address
243
244 Randall Gellens
245 QUALCOMM Incorporated
246 5775 Morehouse Drive
247 San Diego, CA 92121-2779
248 U.S.A.
249
250 Phone: +1 858 651 5115
251 EMail: randy@qualcomm.com
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282 Gellens Standards Track [Page 5]
283
284 RFC 3206 The SYS and AUTH POP Response Codes February 2002
285
286
287 11. Full Copyright Statement
288
289 Copyright (C) The Internet Society (2002). All Rights Reserved.
290
291 This document and translations of it may be copied and furnished to
292 others, and derivative works that comment on or otherwise explain it
293 or assist in its implementation may be prepared, copied, published
294 and distributed, in whole or in part, without restriction of any
295 kind, provided that the above copyright notice and this paragraph are
296 included on all such copies and derivative works. However, this
297 document itself may not be modified in any way, such as by removing
298 the copyright notice or references to the Internet Society or other
299 Internet organizations, except as needed for the purpose of
300 developing Internet standards in which case the procedures for
301 copyrights defined in the Internet Standards process must be
302 followed, or as required to translate it into languages other than
303 English.
304
305 The limited permissions granted above are perpetual and will not be
306 revoked by the Internet Society or its successors or assigns.
307
308 This document and the information contained herein is provided on an
309 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
310 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
311 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
312 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
313 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
314
315 Acknowledgement
316
317 Funding for the RFC Editor function is currently provided by the
318 Internet Society.
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338 Gellens Standards Track [Page 6]
339
This diff could not be displayed because it is too large.
1
2
3
4
5
6
7 Network Working Group A. Melnikov
8 Request for Comments: 3691 Isode Ltd.
9 Category: Standards Track February 2004
10
11
12 Internet Message Access Protocol (IMAP) UNSELECT 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 Copyright Notice
23
24 Copyright (C) The Internet Society (2004). All Rights Reserved.
25
26 Abstract
27
28 This document defines an UNSELECT command that can be used to close
29 the current mailbox in an Internet Message Access Protocol - version
30 4 (IMAP4) session without expunging it. Certain types of IMAP
31 clients need to release resources associated with the selected
32 mailbox without selecting a different mailbox. While IMAP4 provides
33 this functionality (via a SELECT command with a nonexistent mailbox
34 name or reselecting the same mailbox with EXAMINE command), a more
35 clean solution is desirable.
36
37 Table of Contents
38
39 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
40 2. UNSELECT command . . . . . . . . . . . . . . . . . . . . . . . 2
41 3. Security Considerations. . . . . . . . . . . . . . . . . . . . 3
42 4. Formal Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 3
43 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 3
44 6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 3
45 7. Normative References . . . . . . . . . . . . . . . . . . . . . 4
46 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4
47 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 5
48
49
50
51
52
53
54
55
56
57
58 Melnikov Standards Track [Page 1]
59
60 RFC 3691 IMAP UNSELECT command February 2004
61
62
63 1. Introduction
64
65 Certain types of IMAP clients need to release resources associated
66 with the selected mailbox without selecting a different mailbox.
67 While [IMAP4] provides this functionality (via a SELECT command with
68 a nonexistent mailbox name or reselecting the same mailbox with
69 EXAMINE command), a more clean solution is desirable.
70
71 [IMAP4] defines the CLOSE command that closes the selected mailbox as
72 well as permanently removes all messages with the \Deleted flag set.
73
74 However [IMAP4] lacks a command that simply closes the mailbox
75 without expunging it. This document defines the UNSELECT command for
76 this purpose.
77
78 A server which supports this extension indicates this with a
79 capability name of "UNSELECT".
80
81 "C:" and "S:" in examples show lines sent by the client and server
82 respectively.
83
84 The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
85 this document when typed in uppercase are to be interpreted as
86 defined in "Key words for use in RFCs to Indicate Requirement Levels"
87 [KEYWORDS].
88
89 2. UNSELECT Command
90
91 Arguments: none
92
93 Responses: no specific responses for this command
94
95 Result: OK - unselect completed, now in authenticated state
96 BAD - no mailbox selected, or argument supplied but
97 none permitted
98
99 The UNSELECT command frees server's resources associated with the
100 selected mailbox and returns the server to the authenticated
101 state. This command performs the same actions as CLOSE, except
102 that no messages are permanently removed from the currently
103 selected mailbox.
104
105 Example: C: A341 UNSELECT
106 S: A341 OK Unselect completed
107
108
109
110
111
112
113
114 Melnikov Standards Track [Page 2]
115
116 RFC 3691 IMAP UNSELECT command February 2004
117
118
119 3. Security Considerations
120
121 It is believed that this extension doesn't raise any additional
122 security concerns not already discussed in [IMAP4].
123
124 4. Formal Syntax
125
126 The following syntax specification uses the Augmented Backus-Naur
127 Form (ABNF) notation as specified in [ABNF]. Non-terminals
128 referenced but not defined below are as defined by [IMAP4].
129
130 Except as noted otherwise, all alphabetic characters are case-
131 insensitive. The use of upper or lower case characters to define
132 token strings is for editorial clarity only. Implementations MUST
133 accept these strings in a case-insensitive fashion.
134
135 command-select /= "UNSELECT"
136
137 5. IANA Considerations
138
139 IMAP4 capabilities are registered by publishing a standards track or
140 IESG approved experimental RFC. The registry is currently located
141 at:
142
143 http://www.iana.org/assignments/imap4-capabilities
144
145 This document defines the UNSELECT IMAP capabilities. IANA has added
146 this capability to the registry.
147
148 6. Acknowledgments
149
150 UNSELECT command was originally implemented by Tim Showalter in Cyrus
151 IMAP server.
152
153 Also, the author of the document would like to thank Vladimir Butenko
154 and Mark Crispin for reminding that UNSELECT has to be documented.
155 Also thanks to Simon Josefsson for pointing out that there are
156 multiple ways to implement UNSELECT.
157
158
159
160
161
162
163
164
165
166
167
168
169
170 Melnikov Standards Track [Page 3]
171
172 RFC 3691 IMAP UNSELECT command February 2004
173
174
175 7. Normative References
176
177 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
178 Requirement Levels", BCP 14, RFC 2119, March 1997.
179
180 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
181 4rev1", RFC 3501, March 2003.
182
183 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
184 Specifications: ABNF", RFC 2234, November 1997.
185
186 8. Author's Address
187
188 Alexey Melnikov
189 Isode Limited
190 5 Castle Business Village
191 Hampton, Middlesex TW12 2BX
192
193 EMail: Alexey.Melnikov@isode.com
194 URI: http://www.melnikov.ca/
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226 Melnikov Standards Track [Page 4]
227
228 RFC 3691 IMAP UNSELECT command February 2004
229
230
231 9. Full Copyright Statement
232
233 Copyright (C) The Internet Society (2004). This document is subject
234 to the rights, licenses and restrictions contained in BCP 78 and
235 except as set forth therein, the authors retain all their rights.
236
237 This document and the information contained herein are provided on an
238 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
239 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
240 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
241 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
242 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
243 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
244
245 Intellectual Property
246
247 The IETF takes no position regarding the validity or scope of any
248 Intellectual Property Rights or other rights that might be claimed
249 to pertain to the implementation or use of the technology
250 described in this document or the extent to which any license
251 under such rights might or might not be available; nor does it
252 represent that it has made any independent effort to identify any
253 such rights. Information on the procedures with respect to
254 rights in RFC documents can be found in BCP 78 and BCP 79.
255
256 Copies of IPR disclosures made to the IETF Secretariat and any
257 assurances of licenses to be made available, or the result of an
258 attempt made to obtain a general license or permission for the use
259 of such proprietary rights by implementers or users of this
260 specification can be obtained from the IETF on-line IPR repository
261 at http://www.ietf.org/ipr.
262
263 The IETF invites any interested party to bring to its attention
264 any copyrights, patents or patent applications, or other
265 proprietary rights that may cover technology that may be required
266 to implement this standard. Please address the information to the
267 IETF at ietf-ipr@ietf.org.
268
269 Acknowledgement
270
271 Funding for the RFC Editor function is currently provided by the
272 Internet Society.
273
274
275
276
277
278
279
280
281
282 Melnikov Standards Track [Page 5]
283
This diff could not be displayed because it is too large.
This diff could not be displayed because it is too large.
1
2 SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS
3 ----------------------------------------------------------
4
5 (last updated 2001 Jul 24)
6
7 The Simple Authentication and Security Layer (SASL) [RFC2222] is a
8 method for adding authentication support to connection-based
9 protocols. To use this specification, a protocol includes a command
10 for identifying and authenticating a user to a server and for
11 optionally negotiating a security layer for subsequent protocol
12 interactions. The command has a required argument identifying a SASL
13 mechanism.
14
15 SASL mechanisms are named by strings, from 1 to 20 characters in
16 length, consisting of upper-case letters, digits, hyphens, and/or
17 underscores. SASL mechanism names must be registered with the IANA.
18 Procedures for registering new SASL mechanisms are given in the
19 section "Registration procedures" of RFC2222.
20
21
22 MECHANISMS OWNER REFERENCE
23 ---------- ----- ---------
24
25 KERBEROS_V4 IESG <iesg@ietf.org> [RFC2222]
26
27 GSSAPI IESG <iesg@ietf.org> [RFC2222]
28
29 SKEY (OBSOLETE) IESG <iesg@ietf.org> [RFC2444]
30
31 EXTERNAL IESG <iesg@ietf.org> [RFC2222]
32
33 CRAM-MD5 IESG <iesg@ietf.org> [RFC2195]
34
35 ANONYMOUS IESG <iesg@ietf.org> [RFC2245]
36
37 OTP IESG <iesg@ietf.org> [RFC2444]
38
39 GSS-SPNEGO Paul Leach <paulle@microsoft.com> [Leach]
40
41 PLAIN IESG <iesg@ietf.org> [RFC2595]
42
43 SECURID Magnus Nystrom <magnus@rsasecurity.com>[RFC2808]
44
45 NTLM Paul Leach <paulle@microsoft.com> [Leach]
46
47 NMAS_LOGIN Mark G. Gayman <mgayman@novell.com> [Gayman]
48
49 NMAS_AUTHEN Mark G. Gayman <mgayman@novell.com> [Gayman]
50
51 DIGEST-MD5 IESG <iesg@ietf.org> [RFC2831]
52
53 9798-U-RSA-SHA1-ENC robert.zuccherato@entrust.com [RFCZUCC]
54
55 9798-M-RSA-SHA1-ENC robert.zuccherato@entrust.com [RFCZUCC]
56
57 9798-U-DSA-SHA1 robert.zuccherato@entrust.com [RFCZUCC]
58
59 9798-M-DSA-SHA1 robert.zuccherato@entrust.com [RFCZUCC]
60
61 9798-U-ECDSA-SHA1 robert.zuccherato@entrust.com [RFCZUCC]
62
63 9798-M-ECDSA-SHA1 robert.zuccherato@entrust.com [RFCZUCC]
64
65
66
67 References
68 ----------
69
70 [RFC2222] Myers, J., "Simple Authentication and Security Layer
71 (SASL)", RFC 2222, Netscape Communications, October 1997.
72
73 [RFC2195] Klensin, J., Catoe, R., Krumviede, P. "IMAP/POP AUTHorize
74 Extension for Simple Challenge/Response", RFC 2195, MCI,
75 September 1997.
76
77 [RFC2245] Newman, C., "Anonymous SASL Mechanism", RFC 2245, Innosoft,
78 November 1997.
79
80 [RFC2444] Newman, C., "The One-Time-Password SASL Mechanism", RFC
81 2444, October 1998.
82
83 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
84 Innosoft, June 1999.
85
86 [RFC2808] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808,
87 April 2000.
88
89 [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a
90 SASL Mechanism", RFC 2831, May 2000.
91
92
93 [RFCZUCC] R. Zuccherato and M. Nystrom, "ISO/IEC 9798-3 Authentication
94 SASL Mechanism", RFC XXXX, Month 2001.
95
96
97
98 People
99 ------
100
101 [Gayman] Mark G. Gayman, <mgayman@novell.com>, September 2000.
102
103 [Leach] Paul Leach, <paulle@microsoft.com>, December 1998, June 2000.
104
105 []
106
107
108
109
110
111
112
113
114