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