|
0
|
1
|
|
|
2
|
|
|
3
|
|
|
4
|
|
|
5
|
|
|
6
|
|
|
7 Network Working Group T. Showalter
|
|
|
8 Request for Comments: 2971 Mirapoint, Inc.
|
|
|
9 Category: Standards Track October 2000
|
|
|
10
|
|
|
11
|
|
|
12 IMAP4 ID 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 Copyright Notice
|
|
|
23
|
|
|
24 Copyright (C) The Internet Society (2000). All Rights Reserved.
|
|
|
25
|
|
|
26 Abstract
|
|
|
27
|
|
|
28 The ID extension to the Internet Message Access Protocol - Version
|
|
|
29 4rev1 (IMAP4rev1) protocol allows the server and client to exchange
|
|
|
30 identification information on their implementation in order to make
|
|
|
31 bug reports and usage statistics more complete.
|
|
|
32
|
|
|
33 1. Introduction
|
|
|
34
|
|
|
35 The IMAP4rev1 protocol described in [IMAP4rev1] provides a method for
|
|
|
36 accessing remote mail stores, but it provides no facility to
|
|
|
37 advertise what program a client or server uses to provide service.
|
|
|
38 This makes it difficult for implementors to get complete bug reports
|
|
|
39 from users, as it is frequently difficult to know what client or
|
|
|
40 server is in use.
|
|
|
41
|
|
|
42 Additionally, some sites may wish to assemble usage statistics based
|
|
|
43 on what clients are used, but in an an environment where users are
|
|
|
44 permitted to obtain and maintain their own clients this is difficult
|
|
|
45 to accomplish.
|
|
|
46
|
|
|
47 The ID command provides a facility to advertise information on what
|
|
|
48 programs are being used along with contact information (should bugs
|
|
|
49 ever occur).
|
|
|
50
|
|
|
51
|
|
|
52
|
|
|
53
|
|
|
54
|
|
|
55
|
|
|
56
|
|
|
57
|
|
|
58 Showalter Standards Track [Page 1]
|
|
|
59
|
|
|
60 RFC 2971 IMAP4 ID extension October 2000
|
|
|
61
|
|
|
62
|
|
|
63 2. Conventions Used in this Document
|
|
|
64
|
|
|
65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
|
66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|
|
67 document are to be interpreted as described in [KEYWORDS].
|
|
|
68
|
|
|
69 The conventions used in this document are the same as specified in
|
|
|
70 [IMAP4rev1]. In examples, "C:" and "S:" indicate lines sent by the
|
|
|
71 client and server respectively. Line breaks have been inserted for
|
|
|
72 readability.
|
|
|
73
|
|
|
74 3. Specification
|
|
|
75
|
|
|
76 The sole purpose of the ID extension is to enable clients and servers
|
|
|
77 to exchange information on their implementations for the purposes of
|
|
|
78 statistical analysis and problem determination.
|
|
|
79
|
|
|
80 This information is be submitted to a server by any client wishing to
|
|
|
81 provide information for statistical purposes, provided the server
|
|
|
82 advertises its willingness to take the information with the atom "ID"
|
|
|
83 included in the list of capabilities returned by the CAPABILITY
|
|
|
84 command.
|
|
|
85
|
|
|
86 Implementations MUST NOT make operational changes based on the data
|
|
|
87 sent as part of the ID command or response. The ID command is for
|
|
|
88 human consumption only, and is not to be used in improving the
|
|
|
89 performance of clients or servers.
|
|
|
90
|
|
|
91 This includes, but is not limited to, the following:
|
|
|
92
|
|
|
93 Servers MUST NOT attempt to work around client bugs by using
|
|
|
94 information from the ID command. Clients MUST NOT attempt to work
|
|
|
95 around server bugs based on the ID response.
|
|
|
96
|
|
|
97 Servers MUST NOT provide features to a client or otherwise
|
|
|
98 optimize for a particular client by using information from the ID
|
|
|
99 command. Clients MUST NOT provide features to a server or
|
|
|
100 otherwise optimize for a particular server based on the ID
|
|
|
101 response.
|
|
|
102
|
|
|
103 Servers MUST NOT deny access to or refuse service for a client
|
|
|
104 based on information from the ID command. Clients MUST NOT refuse
|
|
|
105 to operate or limit their operation with a server based on the ID
|
|
|
106 response.
|
|
|
107
|
|
|
108
|
|
|
109
|
|
|
110
|
|
|
111
|
|
|
112
|
|
|
113
|
|
|
114 Showalter Standards Track [Page 2]
|
|
|
115
|
|
|
116 RFC 2971 IMAP4 ID extension October 2000
|
|
|
117
|
|
|
118
|
|
|
119 Rationale: It is imperative that this extension not supplant IMAP's
|
|
|
120 CAPABILITY mechanism with a ad-hoc approach where implementations
|
|
|
121 guess each other's features based on who they claim to be.
|
|
|
122
|
|
|
123 Implementations MUST NOT send false information in an ID command.
|
|
|
124
|
|
|
125 Implementations MAY send less information than they have available or
|
|
|
126 no information at all. Such behavior may be useful to preserve user
|
|
|
127 privacy. See Security Considerations, section 7.
|
|
|
128
|
|
|
129 3.1. ID Command
|
|
|
130
|
|
|
131 Arguments: client parameter list or NIL
|
|
|
132
|
|
|
133 Responses: OPTIONAL untagged response: ID
|
|
|
134
|
|
|
135 Result: OK identification information accepted
|
|
|
136 BAD command unknown or arguments invalid
|
|
|
137
|
|
|
138 Implementation identification information is sent by the client with
|
|
|
139 the ID command.
|
|
|
140
|
|
|
141 This command is valid in any state.
|
|
|
142
|
|
|
143 The information sent is in the form of a list of field/value pairs.
|
|
|
144 Fields are permitted to be any IMAP4 string, and values are permitted
|
|
|
145 to be any IMAP4 string or NIL. A value of NIL indicates that the
|
|
|
146 client can not or will not specify this information. The client may
|
|
|
147 also send NIL instead of the list, indicating that it wants to send
|
|
|
148 no information, but would still accept a server response.
|
|
|
149
|
|
|
150 The available fields are defined in section 3.3.
|
|
|
151
|
|
|
152 Example: C: a023 ID ("name" "sodr" "version" "19.34" "vendor"
|
|
|
153 "Pink Floyd Music Limited")
|
|
|
154 S: * ID NIL
|
|
|
155 S: a023 OK ID completed
|
|
|
156
|
|
|
157 3.2. ID Response
|
|
|
158
|
|
|
159 Contents: server parameter list
|
|
|
160
|
|
|
161 In response to an ID command issued by the client, the server replies
|
|
|
162 with a tagged response containing information on its implementation.
|
|
|
163 The format is the same as the client list.
|
|
|
164
|
|
|
165
|
|
|
166
|
|
|
167
|
|
|
168
|
|
|
169
|
|
|
170 Showalter Standards Track [Page 3]
|
|
|
171
|
|
|
172 RFC 2971 IMAP4 ID extension October 2000
|
|
|
173
|
|
|
174
|
|
|
175 Example: C: a042 ID NIL
|
|
|
176 S: * ID ("name" "Cyrus" "version" "1.5" "os" "sunos"
|
|
|
177 "os-version" "5.5" "support-url"
|
|
|
178 "mailto:cyrus-bugs+@andrew.cmu.edu")
|
|
|
179 S: a042 OK ID command completed
|
|
|
180
|
|
|
181 A server MUST send a tagged ID response to an ID command. However, a
|
|
|
182 server MAY send NIL in place of the list.
|
|
|
183
|
|
|
184 3.3. Defined Field Values
|
|
|
185
|
|
|
186 Any string may be sent as a field, but the following are defined to
|
|
|
187 describe certain values that might be sent. Implementations are free
|
|
|
188 to send none, any, or all of these. Strings are not case-sensitive.
|
|
|
189 Field strings MUST NOT be longer than 30 octets. Value strings MUST
|
|
|
190 NOT be longer than 1024 octets. Implementations MUST NOT send more
|
|
|
191 than 30 field-value pairs.
|
|
|
192
|
|
|
193 name Name of the program
|
|
|
194 version Version number of the program
|
|
|
195 os Name of the operating system
|
|
|
196 os-version Version of the operating system
|
|
|
197 vendor Vendor of the client/server
|
|
|
198 support-url URL to contact for support
|
|
|
199 address Postal address of contact/vendor
|
|
|
200 date Date program was released, specified as a date-time
|
|
|
201 in IMAP4rev1
|
|
|
202 command Command used to start the program
|
|
|
203 arguments Arguments supplied on the command line, if any
|
|
|
204 if any
|
|
|
205 environment Description of environment, i.e., UNIX environment
|
|
|
206 variables or Windows registry settings
|
|
|
207
|
|
|
208 Implementations MUST NOT use contact information to submit automatic
|
|
|
209 bug reports. Implementations may include information from an ID
|
|
|
210 response in a report automatically prepared, but are prohibited from
|
|
|
211 sending the report without user authorization.
|
|
|
212
|
|
|
213 It is preferable to find the name and version of the underlying
|
|
|
214 operating system at runtime in cases where this is possible.
|
|
|
215
|
|
|
216 Information sent via an ID response may violate user privacy. See
|
|
|
217 Security Considerations, section 7.
|
|
|
218
|
|
|
219 Implementations MUST NOT send the same field name more than once.
|
|
|
220
|
|
|
221
|
|
|
222
|
|
|
223
|
|
|
224
|
|
|
225
|
|
|
226 Showalter Standards Track [Page 4]
|
|
|
227
|
|
|
228 RFC 2971 IMAP4 ID extension October 2000
|
|
|
229
|
|
|
230
|
|
|
231 4. Formal Syntax
|
|
|
232
|
|
|
233 This syntax is intended to augment the grammar specified in
|
|
|
234 [IMAP4rev1] in order to provide for the ID command. This
|
|
|
235 specification uses the augmented Backus-Naur Form (BNF) notation as
|
|
|
236 used in [IMAP4rev1].
|
|
|
237
|
|
|
238 command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command / id
|
|
|
239 ;; adds id command to command_any in [IMAP4rev1]
|
|
|
240
|
|
|
241 id ::= "ID" SPACE id_params_list
|
|
|
242
|
|
|
243 id_response ::= "ID" SPACE id_params_list
|
|
|
244
|
|
|
245 id_params_list ::= "(" #(string SPACE nstring) ")" / nil
|
|
|
246 ;; list of field value pairs
|
|
|
247
|
|
|
248 response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
|
|
|
249 mailbox_data / message_data / capability_data / id_response)
|
|
|
250
|
|
|
251 5. Use of the ID extension with Firewalls and Other Intermediaries
|
|
|
252
|
|
|
253 There exist proxies, firewalls, and other intermediary systems that
|
|
|
254 can intercept an IMAP session and make changes to the data exchanged
|
|
|
255 in the session. Such intermediaries are not anticipated by the IMAP4
|
|
|
256 protocol design and are not within the scope of the IMAP4 standard.
|
|
|
257 However, in order for the ID command to be useful in the presence of
|
|
|
258 such intermediaries, those intermediaries need to take special note
|
|
|
259 of the ID command and response. In particular, if an intermediary
|
|
|
260 changes any part of the IMAP session it must also change the ID
|
|
|
261 command to advertise its presence.
|
|
|
262
|
|
|
263 A firewall MAY act to block transmission of specific information
|
|
|
264 fields in the ID command and response that it believes reveal
|
|
|
265 information that could expose a security vulnerability. However, a
|
|
|
266 firewall SHOULD NOT disable the extension, when present, entirely,
|
|
|
267 and SHOULD NOT unconditionally remove either the client or server
|
|
|
268 list.
|
|
|
269
|
|
|
270 Finally, it should be noted that a firewall, when handling a
|
|
|
271 CAPABILITY response, MUST NOT allow the names of extensions to be
|
|
|
272 returned to the client that the firewall has no knowledge of.
|
|
|
273
|
|
|
274
|
|
|
275
|
|
|
276
|
|
|
277
|
|
|
278
|
|
|
279
|
|
|
280
|
|
|
281
|
|
|
282 Showalter Standards Track [Page 5]
|
|
|
283
|
|
|
284 RFC 2971 IMAP4 ID extension October 2000
|
|
|
285
|
|
|
286
|
|
|
287 6. References
|
|
|
288
|
|
|
289 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
|
|
|
290 Requirement Levels", RFC 2119, March 1997.
|
|
|
291
|
|
|
292 [IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version
|
|
|
293 4rev1", RFC 2060, October 1996.
|
|
|
294
|
|
|
295 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
|
|
|
296 Text Messages", STD 11, RFC 822, August 1982.
|
|
|
297
|
|
|
298 7. Security Considerations
|
|
|
299
|
|
|
300 This extension has the danger of violating the privacy of users if
|
|
|
301 misused. Clients and servers should notify users that they implement
|
|
|
302 and enable the ID command.
|
|
|
303
|
|
|
304 It is highly desirable that implementations provide a method of
|
|
|
305 disabling ID support, perhaps by not sending ID at all, or by sending
|
|
|
306 NIL as the argument to the ID command or response.
|
|
|
307
|
|
|
308 Implementors must exercise extreme care in adding fields sent as part
|
|
|
309 of an ID command or response. Some fields, including a processor ID
|
|
|
310 number, Ethernet address, or other unique (or mostly unique)
|
|
|
311 identifier allow tracking of users in ways that violate user privacy
|
|
|
312 expectations.
|
|
|
313
|
|
|
314 Having implementation information of a given client or server may
|
|
|
315 make it easier for an attacker to gain unauthorized access due to
|
|
|
316 security holes.
|
|
|
317
|
|
|
318 Since this command includes arbitrary data and does not require the
|
|
|
319 user to authenticate, server implementations are cautioned to guard
|
|
|
320 against an attacker sending arbitrary garbage data in order to fill
|
|
|
321 up the ID log. In particular, if a server naively logs each ID
|
|
|
322 command to disk without inspecting it, an attacker can simply fire up
|
|
|
323 thousands of connections and send a few kilobytes of random data.
|
|
|
324 Servers have to guard against this. Methods include truncating
|
|
|
325 abnormally large responses; collating responses by storing only a
|
|
|
326 single copy, then keeping a counter of the number of times that
|
|
|
327 response has been seen; keeping only particularly interesting parts
|
|
|
328 of responses; and only logging responses of users who actually log
|
|
|
329 in.
|
|
|
330
|
|
|
331 Security is affected by firewalls which modify the IMAP protocol
|
|
|
332 stream; see section 5, Use of the ID Extension with Firewalls and
|
|
|
333 Other Intermediaries, for more information.
|
|
|
334
|
|
|
335
|
|
|
336
|
|
|
337
|
|
|
338 Showalter Standards Track [Page 6]
|
|
|
339
|
|
|
340 RFC 2971 IMAP4 ID extension October 2000
|
|
|
341
|
|
|
342
|
|
|
343 8. Author's Address
|
|
|
344
|
|
|
345 Tim Showalter
|
|
|
346 Mirapoint, Inc.
|
|
|
347 909 Hermosa Ct.
|
|
|
348 Sunnyvale, CA 94095
|
|
|
349
|
|
|
350 EMail: tjs@mirapoint.com
|
|
|
351
|
|
|
352
|
|
|
353
|
|
|
354
|
|
|
355
|
|
|
356
|
|
|
357
|
|
|
358
|
|
|
359
|
|
|
360
|
|
|
361
|
|
|
362
|
|
|
363
|
|
|
364
|
|
|
365
|
|
|
366
|
|
|
367
|
|
|
368
|
|
|
369
|
|
|
370
|
|
|
371
|
|
|
372
|
|
|
373
|
|
|
374
|
|
|
375
|
|
|
376
|
|
|
377
|
|
|
378
|
|
|
379
|
|
|
380
|
|
|
381
|
|
|
382
|
|
|
383
|
|
|
384
|
|
|
385
|
|
|
386
|
|
|
387
|
|
|
388
|
|
|
389
|
|
|
390
|
|
|
391
|
|
|
392
|
|
|
393
|
|
|
394 Showalter Standards Track [Page 7]
|
|
|
395
|
|
|
396 RFC 2971 IMAP4 ID extension October 2000
|
|
|
397
|
|
|
398
|
|
|
399 9. Full Copyright Statement
|
|
|
400
|
|
|
401 Copyright (C) The Internet Society (2000). All Rights Reserved.
|
|
|
402
|
|
|
403 This document and translations of it may be copied and furnished to
|
|
|
404 others, and derivative works that comment on or otherwise explain it
|
|
|
405 or assist in its implementation may be prepared, copied, published
|
|
|
406 and distributed, in whole or in part, without restriction of any
|
|
|
407 kind, provided that the above copyright notice and this paragraph are
|
|
|
408 included on all such copies and derivative works. However, this
|
|
|
409 document itself may not be modified in any way, such as by removing
|
|
|
410 the copyright notice or references to the Internet Society or other
|
|
|
411 Internet organizations, except as needed for the purpose of
|
|
|
412 developing Internet standards in which case the procedures for
|
|
|
413 copyrights defined in the Internet Standards process must be
|
|
|
414 followed, or as required to translate it into languages other than
|
|
|
415 English.
|
|
|
416
|
|
|
417 The limited permissions granted above are perpetual and will not be
|
|
|
418 revoked by the Internet Society or its successors or assigns.
|
|
|
419
|
|
|
420 This document and the information contained herein is provided on an
|
|
|
421 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|
|
422 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|
|
423 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|
|
424 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|
|
425 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
|
426
|
|
|
427 Acknowledgement
|
|
|
428
|
|
|
429 Funding for the RFC Editor function is currently provided by the
|
|
|
430 Internet Society.
|
|
|
431
|
|
|
432
|
|
|
433
|
|
|
434
|
|
|
435
|
|
|
436
|
|
|
437
|
|
|
438
|
|
|
439
|
|
|
440
|
|
|
441
|
|
|
442
|
|
|
443
|
|
|
444
|
|
|
445
|
|
|
446
|
|
|
447
|
|
|
448
|
|
|
449
|
|
|
450 Showalter Standards Track [Page 8]
|
|
|
451
|
