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]
|
|||
|
|
|