1 ../imapserver/server.go:149
2
3
4
5
6
7Network Working Group T. Showalter
8Request for Comments: 2971 Mirapoint, Inc.
9Category: Standards Track October 2000
10
11
12 IMAP4 ID extension
13
14Status 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
22Copyright Notice
23
24 Copyright (C) The Internet Society (2000). All Rights Reserved.
25
26Abstract
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
331. 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
58Showalter Standards Track [Page 1]
59
60RFC 2971 IMAP4 ID extension October 2000
61
62
632. 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
743. 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 ../imapclient/protocol.go:33
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
114Showalter Standards Track [Page 2]
115
116RFC 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
1293.1. ID Command ../imapserver/server.go:1409
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
1573.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
170Showalter Standards Track [Page 3]
171
172RFC 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
1843.3. Defined Field Values ../imapclient/protocol.go:306
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 ../imapserver/server.go:1437
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
226Showalter Standards Track [Page 4]
227
228RFC 2971 IMAP4 ID extension October 2000
229
230
2314. 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 ../imapserver/server.go:1411
242
243 id_response ::= "ID" SPACE id_params_list ../imapclient/parse.go:458 ../imapserver/server.go:1436
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
2515. 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
282Showalter Standards Track [Page 5]
283
284RFC 2971 IMAP4 ID extension October 2000
285
286
2876. 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
2987. 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
338Showalter Standards Track [Page 6]
339
340RFC 2971 IMAP4 ID extension October 2000
341
342
3438. 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
394Showalter Standards Track [Page 7]
395
396RFC 2971 IMAP4 ID extension October 2000
397
398
3999. 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
427Acknowledgement
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
450Showalter Standards Track [Page 8]
451
452