rfc2449.txt

很多RFC的中文文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：mailto:[e-mail]
译者：（）
译文发布时间：2001-11-4
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。



Network Working Group                                         R. Gellens
Request for Comments: 2449                                      Qualcomm
Updates: 1939                                                  C. Newman
Category: Standards Track                                       Innosoft
                                                            L. Lundblade
                                                                Qualcomm
November 1998


POP3扩展机制
(RFC2449——POP3 Extension Mechanism)
本备忘录的状态
本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建
议以得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化
程度和状态。本备忘录的发布不受任何限制。
版权声明
Copyright (C) The Internet Society (2001).
IESG声明
此POP3协议的扩展是供服务器使用，来描述服务器管理员采取的对策的。它不是POP3
进一步扩展之实现的保证。普通的观点是，出于单纯的从一个邮件服务器下载邮件的目的，
POP3协议应该保持简单。如果需要更复杂的操作，应该使用IMAP协议。第7节的第一段
应该仔细阅读。
目录
1．介绍	2
2．这篇文档使用的约定。	2
3．一般命令和响应语法	3
4．参数和响应长度	3
5.CAPA命令	4
6.功能的初始集合	4
6.1 TOP功能	5
6.2.  USER 功能	5
6.3.  SASL capability	5
6.4.  RESP-CODES功能	5
6.5.  LOGIN-DELAY 功能	6
6.6 PIPELINING功能	6
6.7 EXPIRE功能	7
6.8 UIDL功能	8
6.9 IMPLEMENTATION功能	8
7.POP3的未来扩展	9
8.扩展POP3响应码	9
8．1初始化POP3响应码	9
9．IANA考虑	10
10.安全考虑	10
11.致谢	11
12.参考文献	11
13.作者地址	11
14.完整版权说明	12

1．介绍
   邮局协议第3版[POP3]使用广泛。但是，当它包含某些可选的命令时（以及某些已经发
布的协议扩展），它缺乏一种机制，来对这些扩展或动作变化提供公开的支持。
   目前这些可选特征和扩展只能通过探测的方式检测到，如果可行的话。这种方式至少是
缺乏效率的，甚至可能更坏。因此，某些客户端有用于人工配置POP3功能的选项。
因为POP3的一个最重要的特征是它的简单，所以扩展的数目最好比较少。但是，某些
扩展是必需的（比如提供改善的安全性的扩展[POP-AUTH]），而其它的只在特定情况下是值
得要的。另外，需要一种发现服务器的方法。
此备忘录对RFC1939[POP3]进行改进，以提供一种机制用来声明对可选命令，扩展，和
无条件服务器行为的支持。它包含了已经配置的功能的初始配置，这些配置因服务器而异，
以及许多新功能（SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE和
IMPLEMENTATION)。这篇文档也对POP3的错误信息进行了扩展，这样机器的可解析代码就能
够提供给客户端。还包含响应码的初始设置。另外，还定义了一个POP3命令和响应的[ABNF]
规格说明。
公开的评论应该发送到IETF　POP3扩展邮件列表<[e-mail]>。想订阅的
话，可以向<[e-mail]>发送一条包含SUBSCRIBE的消息。
2．这篇文档使用的约定。
　　这篇文档里的"REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
和“MAY”的解释和“Keywords for use in RFCs to Indicate Requirement Levels”[KEYWORDS]
里描述的一样。
  在例子中，“C:”和“S:”表是客户端和服务器端分别发送的信息。
3．一般命令和响应语法
   POP3命令和响应的一般形式使用[ABNF]进行描述：
   POP3命令：
      command      =  keyword *(SP param) CRLF    ;最大255八位组 
      keyword      =  3*4VCHAR
      param        =  1*VCHAR
   POP3响应
      response     =  greeting / single-line / capa-resp / multi-line
      capa-resp    =  single-line *capability "." CRLF
      capa-tag     =  1*cchar
      capability   =  capa-tag *(SP param) CRLF   ;最大512八位组 
      cchar        =  %x21-2D / %x2F-7F
                          ;可打印ASCII码, “.”除外
      dot-stuffed  =  *CHAR CRLF                  ;必须以圆点填充
gchar        =  %x21-3B / %x3D-7F
                          ;可打印的ASCII码，“<"除外
      greeting     =  "+OK" [resp-code] *gchar [timestamp] *gchar CRLF
                          ;最大512八位组
      multi-line   =  single-line *dot-stuffed "." CRLF
      rchar        =  %x21-2E / %x30-5C / %x5E-7F
                          ; 可打印的ASCII码，“/”和“]”除外
      resp-code    =  "[" resp-level *("/" resp-level) "]"
      resp-level   =  1*rchar
      schar        =  %x21-5A / %x5C-7F
                          ; 可打印的ASCII码, “［”除外
      single-line  =  status [SP text] CRLF       ;最大512八位组
      status       =  "+OK" / "-ERR"
      text         =  *schar / resp-code *CHAR
      timestamp    =  "<" *VCHAR ">"
                          ;必须符合RFC-822的msg-id规定
4．参数和响应长度
     这里的阐述增加了RFC 1939提出的命令和参数长度限制。
     一个命令的最大长度从47字符（4字符的命令，单空格，40个字符变量，CRLF）增加
到255八位组，包括有限CRLF。
    支持CAPA命令的服务器必须支持长达255八位组的命令。服务器也必须支持任何支持
的功能所指定的最大命令长度。
    命令响应的第一行的最大长度（包括开始的问候）还是512八位组不变（包括有限CRLF）。
5.CAPA命令
  POP3的CAPA命令返回POP3服务器支持的功能列表。它在AUTHORIZATION和TRANSACTION
状态下均可使用。
  一个功能描述必须记录在功能通告于何种状态下，以及在哪种状态下命令有效。
    在AUTHORIZATION状态下可用的功能必须在两种状态下都予以通告。
    如果某个功能在两种状态下都被通告了，但是在身份验证之后参数可能不同。这种可能
性必须在功能描述中说明。
（这些要求允许一个客户端在不使用任何TRANSACTION-only功能，以及任何在身份验证之
后参数值可能不同的功能时，只发送一个CAPA命令。）
    如果身份验证这步商定了一个完整性保护层，客户端应该在验证重新发送CAPA命令，
以阻止活动的down-negotiation攻击。
每个功能都可能激活额外的协议命令，额外的参数和已存在命令的响应，或者描述服务
器行为的一个方面。这些细节在相应的功能描述中阐述。
第3节描述了使用[ABNF]的CAPA响应。当一个功能响应描述了一个可选命令时，
<capa-tag>应该和命令关键词一样。CAPA响应标记对大小写敏感。
CAPA
参数：无
限制：无
讨论：-ERR响应表明功能命令没有实现，客户端必须像以前一样对功能进行探测。
-OK响应后面紧跟着的就是一个功能列表，一行一个功能。每个功能名后面可能都有一
个空格和由空格分隔的一个参数列表。每个功能行被限制在512八位组以内（包括CRLF在
内）。功能列表碰到包含一个终止八位组（“.”）和一个CRLF对时结束。
可能的响应：+OK –ERR
例子：
     C: CAPA
     S: +OK Capability list follows
     S: TOP
     S: USER
     S: SASL CRAM-MD5 KERBEROS_V4
     S: RESP-CODES
     S: LOGIN-DELAY 900
     S: PIPELINING
     S: EXPIRE 60
     S: UIDL
     S: IMPLEMENTATION Shlemazle-Plotz-v302
     S: .
6.功能的初始集合
这节定义了POP3功能的一个初始集合。这些包括可选POP3命令，已经发布的POP3扩
展，以及POP3服务器之间的行为差异，这种差异能够影响到客户端。
注意到没有APOP功能，尽管APOP在[POP3]中是可选命令。客户端通过包含在一个尖括
号（“<>”）里的初始验证的问候语的存在与否来发现服务器对APOP的支持。因此，APOP功
能为服务器声明同样的事情引进了两种方法。
  6.1 TOP功能
     CAPA标记：TOP
     参数：无
   附加命令：TOP
   影响的标准命令：无
   声明的状态/可能的不同：两者/没有
   命令有效的状态：TRANSACTION
   规范参考：[POP3]
   讨论：TOP 功能表明TOP可选命令可用。
6.2.  USER 功能
CAPA tag:USER
参数：无
  附加命令:USER PASS
  受影响的标准命令:无
  声明的状态/可能的不同：两者/没有
命令有效的状态：AUTHENTICATION
  规范参考：[POP3]
讨论:USER功能表明支持USER和PASS命令，尽管它们可能不是对所有用户都可用。
6.3.  SASL capability
  CAPA标记:SASL
  参数:支持的SASL机制
  附加命令:AUTH
  受影响的标准命令：无
  声明的状态/可能的不同：两者/没有   
命令有效的状态：AUTHENTICATION
  规范参考：[POP-AUTH, SASL]
  讨论:POP3AUTH命令[POP-AUTH]允许使用带POP3的[SASL]的认证机制. SASL功能表明
AUTH命令可用，并且支持base64编码的另一参数，此参数可选，是为初始的客户端响应而
设的，如SASL里所述。SASL功能的参数是受支持的SASL机制列表，列表由空格分隔。
6.4.  RESP-CODES功能
 CAPA标记: RESP-CODES
  参数:无
  附加命令:无
受影响的标准命令:无
  声明的状态/可能的不同: 两者/没有
  命令有效的状态:n/a
  规范参考:此文档
讨论: RESP-CODES性能表明任何由此服务器发送的响应文本，只要是由一个左方括号
（“[”]）开始的，它就是扩展响应编码（参见第8节）。
6.5.  LOGIN-DELAY 功能
 CAPA标记:LOGIN-DELAY
  参数:多个登陆间的最小间隔秒数; AUTHENTICATION状态下可以跟上USER。
附加命令:无
  受影响的标准命令:USER PASS APOP AUTH
  声明的状态/可能的不同：两者/有
  命令有效的状态:n/a
  规范参考:此文档
  讨论：POP3客户经常登陆来检查是否有新邮件。不幸的是，创建一个连接，验证用户，
以及打开用户的邮箱非常消耗服务器的资源。许多POP3服务器试图通过要求登陆之间有一
个延迟的方式来降低服务器负载。LOGIN-DELAY功能包括一个整型参数，它表示在一个对
PASS, APOP, 或 AUTH命令的“+OK”响应之后，接受另一个验证之前，延迟的秒数。允许
用户配置邮件检查间隔的客户端应该使用这个功能来确定允许的最小间隔。发布LOGIN-       
DELAY的服务器应该强制此实现。
如果最小登陆延迟可以因用户而异（就是说，LOGIN-DELAY参数在验证之后可以改变），
服务器必须在AUTHENTICATION时设置用户能够配置的最大值。这可能是当前所有用户使用
中的最大值（这样的话每个服务器就只有一个值），或者是服务器允许为任意用户设置的最
大值。服务器应该在AUTHENTICATION状态下给LOGIN-DELAY参数附加“USER”标记，以通
知客户端在验证之后可以获取一个更加精确的值。服务器应该在TRANSACTION下宣布那个更
加精确的值。（“USER”标记允许客户端决定是否需要另一个CAPA命令。）
服务器通过带或不带LOGIN-DELAY的出错响应来拒绝验证，这样强制LOGIN-DELAY。参
见第8.1.1节获取更多信息。
6.6 PIPELINING功能
CAPA标记：PIPELINING
参数：无
附加命令：无
受影响的标准命令：全部
声明的状态/可能的不同: 两者/没有
命令有效的状态:n/a