452 lines
14 KiB
Plaintext
452 lines
14 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group T. Showalter
|
||
Request for Comments: 2971 Mirapoint, Inc.
|
||
Category: Standards Track October 2000
|
||
|
||
|
||
IMAP4 ID extension
|
||
|
||
Status of this Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2000). All Rights Reserved.
|
||
|
||
Abstract
|
||
|
||
The ID extension to the Internet Message Access Protocol - Version
|
||
4rev1 (IMAP4rev1) protocol allows the server and client to exchange
|
||
identification information on their implementation in order to make
|
||
bug reports and usage statistics more complete.
|
||
|
||
1. Introduction
|
||
|
||
The IMAP4rev1 protocol described in [IMAP4rev1] provides a method for
|
||
accessing remote mail stores, but it provides no facility to
|
||
advertise what program a client or server uses to provide service.
|
||
This makes it difficult for implementors to get complete bug reports
|
||
from users, as it is frequently difficult to know what client or
|
||
server is in use.
|
||
|
||
Additionally, some sites may wish to assemble usage statistics based
|
||
on what clients are used, but in an an environment where users are
|
||
permitted to obtain and maintain their own clients this is difficult
|
||
to accomplish.
|
||
|
||
The ID command provides a facility to advertise information on what
|
||
programs are being used along with contact information (should bugs
|
||
ever occur).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Showalter Standards Track [Page 1]
|
||
|
||
RFC 2971 IMAP4 ID extension October 2000
|
||
|
||
|
||
2. Conventions Used in this Document
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in [KEYWORDS].
|
||
|
||
The conventions used in this document are the same as specified in
|
||
[IMAP4rev1]. In examples, "C:" and "S:" indicate lines sent by the
|
||
client and server respectively. Line breaks have been inserted for
|
||
readability.
|
||
|
||
3. Specification
|
||
|
||
The sole purpose of the ID extension is to enable clients and servers
|
||
to exchange information on their implementations for the purposes of
|
||
statistical analysis and problem determination.
|
||
|
||
This information is be submitted to a server by any client wishing to
|
||
provide information for statistical purposes, provided the server
|
||
advertises its willingness to take the information with the atom "ID"
|
||
included in the list of capabilities returned by the CAPABILITY
|
||
command.
|
||
|
||
Implementations MUST NOT make operational changes based on the data
|
||
sent as part of the ID command or response. The ID command is for
|
||
human consumption only, and is not to be used in improving the
|
||
performance of clients or servers.
|
||
|
||
This includes, but is not limited to, the following:
|
||
|
||
Servers MUST NOT attempt to work around client bugs by using
|
||
information from the ID command. Clients MUST NOT attempt to work
|
||
around server bugs based on the ID response.
|
||
|
||
Servers MUST NOT provide features to a client or otherwise
|
||
optimize for a particular client by using information from the ID
|
||
command. Clients MUST NOT provide features to a server or
|
||
otherwise optimize for a particular server based on the ID
|
||
response.
|
||
|
||
Servers MUST NOT deny access to or refuse service for a client
|
||
based on information from the ID command. Clients MUST NOT refuse
|
||
to operate or limit their operation with a server based on the ID
|
||
response.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Showalter Standards Track [Page 2]
|
||
|
||
RFC 2971 IMAP4 ID extension October 2000
|
||
|
||
|
||
Rationale: It is imperative that this extension not supplant IMAP's
|
||
CAPABILITY mechanism with a ad-hoc approach where implementations
|
||
guess each other's features based on who they claim to be.
|
||
|
||
Implementations MUST NOT send false information in an ID command.
|
||
|
||
Implementations MAY send less information than they have available or
|
||
no information at all. Such behavior may be useful to preserve user
|
||
privacy. See Security Considerations, section 7.
|
||
|
||
3.1. ID Command
|
||
|
||
Arguments: client parameter list or NIL
|
||
|
||
Responses: OPTIONAL untagged response: ID
|
||
|
||
Result: OK identification information accepted
|
||
BAD command unknown or arguments invalid
|
||
|
||
Implementation identification information is sent by the client with
|
||
the ID command.
|
||
|
||
This command is valid in any state.
|
||
|
||
The information sent is in the form of a list of field/value pairs.
|
||
Fields are permitted to be any IMAP4 string, and values are permitted
|
||
to be any IMAP4 string or NIL. A value of NIL indicates that the
|
||
client can not or will not specify this information. The client may
|
||
also send NIL instead of the list, indicating that it wants to send
|
||
no information, but would still accept a server response.
|
||
|
||
The available fields are defined in section 3.3.
|
||
|
||
Example: C: a023 ID ("name" "sodr" "version" "19.34" "vendor"
|
||
"Pink Floyd Music Limited")
|
||
S: * ID NIL
|
||
S: a023 OK ID completed
|
||
|
||
3.2. ID Response
|
||
|
||
Contents: server parameter list
|
||
|
||
In response to an ID command issued by the client, the server replies
|
||
with a tagged response containing information on its implementation.
|
||
The format is the same as the client list.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Showalter Standards Track [Page 3]
|
||
|
||
RFC 2971 IMAP4 ID extension October 2000
|
||
|
||
|
||
Example: C: a042 ID NIL
|
||
S: * ID ("name" "Cyrus" "version" "1.5" "os" "sunos"
|
||
"os-version" "5.5" "support-url"
|
||
"mailto:cyrus-bugs+@andrew.cmu.edu")
|
||
S: a042 OK ID command completed
|
||
|
||
A server MUST send a tagged ID response to an ID command. However, a
|
||
server MAY send NIL in place of the list.
|
||
|
||
3.3. Defined Field Values
|
||
|
||
Any string may be sent as a field, but the following are defined to
|
||
describe certain values that might be sent. Implementations are free
|
||
to send none, any, or all of these. Strings are not case-sensitive.
|
||
Field strings MUST NOT be longer than 30 octets. Value strings MUST
|
||
NOT be longer than 1024 octets. Implementations MUST NOT send more
|
||
than 30 field-value pairs.
|
||
|
||
name Name of the program
|
||
version Version number of the program
|
||
os Name of the operating system
|
||
os-version Version of the operating system
|
||
vendor Vendor of the client/server
|
||
support-url URL to contact for support
|
||
address Postal address of contact/vendor
|
||
date Date program was released, specified as a date-time
|
||
in IMAP4rev1
|
||
command Command used to start the program
|
||
arguments Arguments supplied on the command line, if any
|
||
if any
|
||
environment Description of environment, i.e., UNIX environment
|
||
variables or Windows registry settings
|
||
|
||
Implementations MUST NOT use contact information to submit automatic
|
||
bug reports. Implementations may include information from an ID
|
||
response in a report automatically prepared, but are prohibited from
|
||
sending the report without user authorization.
|
||
|
||
It is preferable to find the name and version of the underlying
|
||
operating system at runtime in cases where this is possible.
|
||
|
||
Information sent via an ID response may violate user privacy. See
|
||
Security Considerations, section 7.
|
||
|
||
Implementations MUST NOT send the same field name more than once.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Showalter Standards Track [Page 4]
|
||
|
||
RFC 2971 IMAP4 ID extension October 2000
|
||
|
||
|
||
4. Formal Syntax
|
||
|
||
This syntax is intended to augment the grammar specified in
|
||
[IMAP4rev1] in order to provide for the ID command. This
|
||
specification uses the augmented Backus-Naur Form (BNF) notation as
|
||
used in [IMAP4rev1].
|
||
|
||
command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command / id
|
||
;; adds id command to command_any in [IMAP4rev1]
|
||
|
||
id ::= "ID" SPACE id_params_list
|
||
|
||
id_response ::= "ID" SPACE id_params_list
|
||
|
||
id_params_list ::= "(" #(string SPACE nstring) ")" / nil
|
||
;; list of field value pairs
|
||
|
||
response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
|
||
mailbox_data / message_data / capability_data / id_response)
|
||
|
||
5. Use of the ID extension with Firewalls and Other Intermediaries
|
||
|
||
There exist proxies, firewalls, and other intermediary systems that
|
||
can intercept an IMAP session and make changes to the data exchanged
|
||
in the session. Such intermediaries are not anticipated by the IMAP4
|
||
protocol design and are not within the scope of the IMAP4 standard.
|
||
However, in order for the ID command to be useful in the presence of
|
||
such intermediaries, those intermediaries need to take special note
|
||
of the ID command and response. In particular, if an intermediary
|
||
changes any part of the IMAP session it must also change the ID
|
||
command to advertise its presence.
|
||
|
||
A firewall MAY act to block transmission of specific information
|
||
fields in the ID command and response that it believes reveal
|
||
information that could expose a security vulnerability. However, a
|
||
firewall SHOULD NOT disable the extension, when present, entirely,
|
||
and SHOULD NOT unconditionally remove either the client or server
|
||
list.
|
||
|
||
Finally, it should be noted that a firewall, when handling a
|
||
CAPABILITY response, MUST NOT allow the names of extensions to be
|
||
returned to the client that the firewall has no knowledge of.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Showalter Standards Track [Page 5]
|
||
|
||
RFC 2971 IMAP4 ID extension October 2000
|
||
|
||
|
||
6. References
|
||
|
||
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", RFC 2119, March 1997.
|
||
|
||
[IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version
|
||
4rev1", RFC 2060, October 1996.
|
||
|
||
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
|
||
Text Messages", STD 11, RFC 822, August 1982.
|
||
|
||
7. Security Considerations
|
||
|
||
This extension has the danger of violating the privacy of users if
|
||
misused. Clients and servers should notify users that they implement
|
||
and enable the ID command.
|
||
|
||
It is highly desirable that implementations provide a method of
|
||
disabling ID support, perhaps by not sending ID at all, or by sending
|
||
NIL as the argument to the ID command or response.
|
||
|
||
Implementors must exercise extreme care in adding fields sent as part
|
||
of an ID command or response. Some fields, including a processor ID
|
||
number, Ethernet address, or other unique (or mostly unique)
|
||
identifier allow tracking of users in ways that violate user privacy
|
||
expectations.
|
||
|
||
Having implementation information of a given client or server may
|
||
make it easier for an attacker to gain unauthorized access due to
|
||
security holes.
|
||
|
||
Since this command includes arbitrary data and does not require the
|
||
user to authenticate, server implementations are cautioned to guard
|
||
against an attacker sending arbitrary garbage data in order to fill
|
||
up the ID log. In particular, if a server naively logs each ID
|
||
command to disk without inspecting it, an attacker can simply fire up
|
||
thousands of connections and send a few kilobytes of random data.
|
||
Servers have to guard against this. Methods include truncating
|
||
abnormally large responses; collating responses by storing only a
|
||
single copy, then keeping a counter of the number of times that
|
||
response has been seen; keeping only particularly interesting parts
|
||
of responses; and only logging responses of users who actually log
|
||
in.
|
||
|
||
Security is affected by firewalls which modify the IMAP protocol
|
||
stream; see section 5, Use of the ID Extension with Firewalls and
|
||
Other Intermediaries, for more information.
|
||
|
||
|
||
|
||
|
||
Showalter Standards Track [Page 6]
|
||
|
||
RFC 2971 IMAP4 ID extension October 2000
|
||
|
||
|
||
8. Author's Address
|
||
|
||
Tim Showalter
|
||
Mirapoint, Inc.
|
||
909 Hermosa Ct.
|
||
Sunnyvale, CA 94095
|
||
|
||
EMail: tjs@mirapoint.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Showalter Standards Track [Page 7]
|
||
|
||
RFC 2971 IMAP4 ID extension October 2000
|
||
|
||
|
||
9. Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2000). All Rights Reserved.
|
||
|
||
This document and translations of it may be copied and furnished to
|
||
others, and derivative works that comment on or otherwise explain it
|
||
or assist in its implementation may be prepared, copied, published
|
||
and distributed, in whole or in part, without restriction of any
|
||
kind, provided that the above copyright notice and this paragraph are
|
||
included on all such copies and derivative works. However, this
|
||
document itself may not be modified in any way, such as by removing
|
||
the copyright notice or references to the Internet Society or other
|
||
Internet organizations, except as needed for the purpose of
|
||
developing Internet standards in which case the procedures for
|
||
copyrights defined in the Internet Standards process must be
|
||
followed, or as required to translate it into languages other than
|
||
English.
|
||
|
||
The limited permissions granted above are perpetual and will not be
|
||
revoked by the Internet Society or its successors or assigns.
|
||
|
||
This document and the information contained herein is provided on an
|
||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Showalter Standards Track [Page 8]
|
||
|