summaryrefslogtreecommitdiff
path: root/imap/docs/rfc/rfc2971.txt
diff options
context:
space:
mode:
authorEduardo Chappa <chappa@washington.edu>2013-06-03 10:30:56 -0600
committerEduardo Chappa <chappa@washington.edu>2013-06-03 10:30:56 -0600
commite4b35478c8b3ce7352a74b2fea0e067f068daf18 (patch)
tree0b8a97debddc8210c6696c252c26f03703b606fa /imap/docs/rfc/rfc2971.txt
parenta46157ba61f2c65f88b42abb31db60c4a714f87b (diff)
downloadalpine-e4b35478c8b3ce7352a74b2fea0e067f068daf18.tar.xz
* Changes to configure.ac to add -lkrb5 to the link
* Changes to avoud errors in compilation when -Wformat-security is used * Remove RFC files from source code
Diffstat (limited to 'imap/docs/rfc/rfc2971.txt')
-rw-r--r--imap/docs/rfc/rfc2971.txt451
1 files changed, 0 insertions, 451 deletions
diff --git a/imap/docs/rfc/rfc2971.txt b/imap/docs/rfc/rfc2971.txt
deleted file mode 100644
index 9e7264dc..00000000
--- a/imap/docs/rfc/rfc2971.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-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]
-