分享
 
 
 

RFC2971 - IMAP4 ID extension

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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).

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.

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.

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.

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.

6. References

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate

Requirement Levels", RFC2119, March 1997.

[IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version

4rev1", RFC2060, October 1996.

[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet

Text Messages", STD 11, RFC822, 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.

8. Author's Address

Tim Showalter

Mirapoint, Inc.

909 Hermosa Ct.

Sunnyvale, CA 94095

EMail: tjs@mirapoint.com

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 RFCEditor function is currently provided by the

Internet Society.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有