7
Network Working Group T. Showalter
8
Request for Comments: 2971 Mirapoint, Inc.
9
Category: Standards Track October 2000
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.
24
Copyright (C) The Internet Society (2000). All Rights Reserved.
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.
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
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
47
The ID command provides a facility to advertise information on what
48
programs are being used along with contact information (should bugs
58
Showalter Standards Track [Page 1]
60
RFC 2971 IMAP4 ID extension October 2000
63
2. Conventions Used in this Document
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].
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
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.
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
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.
91
This includes, but is not limited to, the following:
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.
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
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
114
Showalter Standards Track [Page 2]
116
RFC 2971 IMAP4 ID extension October 2000
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.
123
Implementations MUST NOT send false information in an ID command.
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.
131
Arguments: client parameter list or NIL
133
Responses: OPTIONAL untagged response: ID
135
Result: OK identification information accepted
136
BAD command unknown or arguments invalid
138
Implementation identification information is sent by the client with
141
This command is valid in any state.
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.
150
The available fields are defined in section 3.3.
152
Example: C: a023 ID ("name" "sodr" "version" "19.34" "vendor"
153
"Pink Floyd Music Limited")
155
S: a023 OK ID completed
159
Contents: server parameter list
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.
170
Showalter Standards Track [Page 3]
172
RFC 2971 IMAP4 ID extension October 2000
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
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.
184
3.3. Defined Field Values
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.
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
202
command Command used to start the program
203
arguments Arguments supplied on the command line, if any
205
environment Description of environment, i.e., UNIX environment
206
variables or Windows registry settings
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.
213
It is preferable to find the name and version of the underlying
214
operating system at runtime in cases where this is possible.
216
Information sent via an ID response may violate user privacy. See
217
Security Considerations, section 7.
219
Implementations MUST NOT send the same field name more than once.
226
Showalter Standards Track [Page 4]
228
RFC 2971 IMAP4 ID extension October 2000
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
238
command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command / id
239
;; adds id command to command_any in [IMAP4rev1]
241
id ::= "ID" SPACE id_params_list
243
id_response ::= "ID" SPACE id_params_list
245
id_params_list ::= "(" #(string SPACE nstring) ")" / nil
246
;; list of field value pairs
248
response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
249
mailbox_data / message_data / capability_data / id_response)
251
5. Use of the ID extension with Firewalls and Other Intermediaries
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.
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
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.
282
Showalter Standards Track [Page 5]
284
RFC 2971 IMAP4 ID extension October 2000
289
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
290
Requirement Levels", RFC 2119, March 1997.
292
[IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version
293
4rev1", RFC 2060, October 1996.
295
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
296
Text Messages", STD 11, RFC 822, August 1982.
298
7. Security Considerations
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.
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.
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
314
Having implementation information of a given client or server may
315
make it easier for an attacker to gain unauthorized access due to
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
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.
338
Showalter Standards Track [Page 6]
340
RFC 2971 IMAP4 ID extension October 2000
350
EMail: tjs@mirapoint.com
394
Showalter Standards Track [Page 7]
396
RFC 2971 IMAP4 ID extension October 2000
399
9. Full Copyright Statement
401
Copyright (C) The Internet Society (2000). All Rights Reserved.
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
417
The limited permissions granted above are perpetual and will not be
418
revoked by the Internet Society or its successors or assigns.
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.
429
Funding for the RFC Editor function is currently provided by the
450
Showalter Standards Track [Page 8]
added
removed
imap/docs/rfc/rfc2971.txt
