diff options
Diffstat (limited to 'vendor/github.com/mattermost/rsc/imap/rfc2971.txt')
| -rw-r--r-- | vendor/github.com/mattermost/rsc/imap/rfc2971.txt | 451 |
1 files changed, 0 insertions, 451 deletions
diff --git a/vendor/github.com/mattermost/rsc/imap/rfc2971.txt b/vendor/github.com/mattermost/rsc/imap/rfc2971.txt deleted file mode 100644 index 9e7264dcc..000000000 --- a/vendor/github.com/mattermost/rsc/imap/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] - |