翻译披露：本页为对 IETF RFC 2449《POP3 Extension Mechanism》 的中文翻译，原文著作权归 IETF/原作者所有，内容以人类原始 RFC 为准。本译本由 ztpop.net 整理，仅供学习参考；RFC 受 BCP 78 与 IETF 信托法律条款约束，译本保留原文编号与结构，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc2449。

RFC 2449：POP3 扩展机制

IETF · RFC 2449 · 标准跟踪（Standards Track）· 更新 RFC 1939 · R. Gellens（Qualcomm）、C. Newman（Innosoft）、L. Lundblade（Qualcomm） · 1998 年 11 月

本备忘录的状态

本文档为互联网社区规定了一项互联网标准跟踪（standards track）协议，并征求改进意见与建议。有关本协议的标准化状态与状况，请参阅《互联网官方协议标准》（STD 1）的当前版本。本备忘录的分发不受限制。

Copyright (C) The Internet Society (1998). All Rights Reserved.

IESG 说明

POP3 协议的本扩展供服务器用于表达服务器管理员所作的策略决定。它并不构成对一般意义上更多 POP3 扩展实现的认可。普遍的看法是：POP3 协议应当保持简单，并专注于"从邮件服务器下载邮件"这一简单用途。如果需要更复杂的操作，应当使用 IMAP 协议 [RFC 2060]。第 7 节的第一段应当被非常仔细地阅读。

1. 引言

第 3 版邮局协议（POP3）[POP3] 应用极为广泛。然而，尽管它包含一些可选命令（并且已经发布了一些有用的协议扩展），它却缺少一种用于公告自身支持这些扩展或行为差异的机制。

目前，这些可选特性与扩展只能通过探测（probing）来发现——如果还能发现的话。这种做法往好了说是低效，往坏了说可能更糟。其结果是，一些客户端为 POP3 服务器能力提供了手动配置选项。

由于 POP3 最重要的特征之一就是简单，因此扩展在数量上宜少（见第 7 节）。然而有些扩展是必要的（例如提供改进安全性的扩展 [POP-AUTH]），另一些扩展在特定场景下则非常可取。此外，还需要一种发现服务器行为的手段。

本备忘录更新 RFC 1939 [POP3]，定义一种机制用于公告对可选命令、扩展以及无条件服务器行为的支持。其中包含一组当前已部署、且在各服务器实现之间存在差异的初始能力，以及若干新能力（SASL、RESP-CODES、LOGIN-DELAY、PIPELINING、EXPIRE 与 IMPLEMENTATION）。本文档还扩展了 POP3 的错误消息，使得可以向客户端提供机器可解析的代码，并给出一组初始响应码。此外，本文还定义了 POP3 命令与响应的 [ABNF] 规范。

2. 本文档使用的约定

本文档中的关键词 "REQUIRED"（需要）、"MUST"（必须）、"MUST NOT"（不得）、"SHOULD"（应当）、"SHOULD NOT"（不应）与 "MAY"（可以），应按《用于 RFC 中表示需求级别的关键词》[KEYWORDS] 中的描述来解释。

在示例中，"C:" 与 "S:" 分别表示由客户端与服务器发送的行。

3. 通用命令与响应语法

POP3 命令与响应的一般形式使用 [ABNF] 描述如下：

POP3 命令：

command      =  keyword *(SP param) CRLF    ;255 octets maximum
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 octets maximum
cchar        =  %x21-2D / %x2F-7F
                    ;printable ASCII, excluding "."
dot-stuffed  =  *CHAR CRLF                  ;must be dot-stuffed
gchar        =  %x21-3B / %x3D-7F
                    ;printable ASCII, excluding "<"
greeting     =  "+OK" [resp-code] *gchar [timestamp] *gchar CRLF
                    ;512 octets maximum
multi-line   =  single-line *dot-stuffed "." CRLF
rchar        =  %x21-2E / %x30-5C / %x5E-7F
                    ;printable ASCII, excluding "/" and "]"
resp-code    =  "[" resp-level *("/" resp-level) "]"
resp-level   =  1*rchar
schar        =  %x21-5A / %x5C-7F
                    ;printable ASCII, excluding "["
single-line  =  status [SP text] CRLF       ;512 octets maximum
status       =  "+OK" / "-ERR"
text         =  *schar / resp-code *CHAR
timestamp    =  "<" *VCHAR ">"
                    ;MUST conform to 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 状态的能力，也不使用任何在认证后取值可能变化的能力，那么它只需发出一次 CAPA 命令。）

如果认证步骤协商出了完整性保护层，客户端应当在认证之后重新发出 CAPA 命令，以检查是否存在主动的降级协商攻击。

每项能力可能启用额外的协议命令、为既有命令启用额外的参数与响应，或者描述服务器行为的某个方面。这些细节在该能力的描述中给出。

第 3 节用 [ABNF] 描述了 CAPA 响应。当某个能力响应描述的是一条可选命令时，其 <capa-tag> 应当与该命令关键字相同。CAPA 响应标签大小写不敏感。

字段内容
命令CAPA
参数无
限制无
可能的响应+OK、-ERR

讨论：返回 -ERR 响应表示未实现该能力命令，客户端将不得不像以前那样通过探测来发现能力。

+OK 响应之后跟随一份能力列表，每行一项。每个能力名称之后可以跟一个空格以及一个以空格分隔的参数列表。每个能力行限制为 512 个八位组（含 CRLF）。能力列表以仅含终止八位组（"."）与 CRLF 对的一行作为结束。

示例：

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 标签：USER；参数：无；新增命令：USER、PASS；受影响的标准命令：无；公告状态/是否可能有差异：两种状态 / 否；命令有效状态：AUTHENTICATION；规范引用：[POP3]。

讨论：USER 能力表示支持 USER 与 PASS 命令，尽管它们未必对所有用户都可用。

6.3 SASL 能力

CAPA 标签：SASL；参数：所支持的 SASL 机制；新增命令：AUTH；受影响的标准命令：无；公告状态/是否可能有差异：两种状态 / 否；命令有效状态：AUTHENTICATION；规范引用：[POP-AUTH]、[SASL]。

讨论：POP3 的 AUTH 命令 [POP-AUTH] 允许在 POP3 中使用 [SASL] 认证机制。SASL 能力表示 AUTH 命令可用，并且它支持一个可选的、经 base64 编码的第二参数用于承载初始客户端响应（如 SASL 规范所述）。SASL 能力的参数是一个以空格分隔的、所支持 SASL 机制的列表。

6.4 RESP-CODES 能力

CAPA 标签：RESP-CODES；参数：无；新增命令：无；受影响的标准命令：无；公告状态/是否可能有差异：两种状态 / 否；命令有效状态：不适用；规范引用：本文档。

讨论：RESP-CODES 能力表示：本服务器发出的任何以左方括号（"["）开头的响应文本都是一个扩展响应码（见第 8 节）。

6.5 LOGIN-DELAY 能力

CAPA 标签：LOGIN-DELAY；参数：两次登录之间的最小秒数，在 AUTHENTICATION 状态下可选地后接 USER；新增命令：无；受影响的标准命令：USER、PASS、APOP、AUTH；公告状态/是否可能有差异：两种状态 / 是；命令有效状态：不适用；规范引用：本文档。

讨论：POP3 客户端往往频繁登录以检查新邮件。遗憾的是，建立连接、认证用户并打开用户信箱（maildrop）的过程可能非常消耗服务器资源。许多已部署的 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；参数：无；新增命令：无；受影响的标准命令：全部；公告状态/是否可能有差异：两种状态 / 否；命令有效状态：不适用；规范引用：本文档。

讨论：PIPELINING 能力表示服务器能够一次接受多条命令；客户端不必等到某条命令的响应返回后才发出后续命令。如果服务器支持 PIPELINING，它必须依次处理每条命令。如果客户端使用 PIPELINING，它必须跟踪自己有哪些命令尚未完成，并按顺序把服务器响应与命令匹配起来。若客户端或服务器使用阻塞式写入，则不得超出底层传输层的窗口大小。

一些 POP3 客户端设有选项用于标明服务器支持"重叠的 POP3 命令"。本能力免除了在客户端进行此项配置的必要。

这大致等同于 ESMTP 的 PIPELINING 扩展 [PIPELINING]；不过，由于 SMTP [SMTP] 的命令与响应往往较短，其收益在于把多条命令编组并作为一个单元发送。虽然 POP 中也存在这类情形（例如 USER 与 PASS 可以批量发送，多条 RETR 和/或 DELE 命令可以成组发出），但由于 POP 的命令较短而响应有时很长，因此"在仍在接收前一条命令响应的同时发送新命令"也具有优势（例如在处理 UIDL 回复的同时发送 RETR 和/或 DELE 命令）。

6.7 EXPIRE 能力

CAPA 标签：EXPIRE；参数：服务器保证的最小保留天数，或 NEVER，在 AUTHENTICATION 状态下可选地后接 USER；新增命令：无；受影响的标准命令：无；公告状态/是否可能有差异：两种状态 / 是；命令有效状态：不适用；规范引用：本文档。

讨论：虽然 POP3 允许客户端把邮件留在服务器上，但 RFC 1939 [POP3] 对此可能引发的问题提出了警告，并允许服务器依据站点策略删除邮件。

EXPIRE 能力通过让服务器把生效中的策略告知客户端，从而规避了 RFC 1939 中提到的问题。EXPIRE 能力的参数表示服务器上邮件的最小保留期限（以天为单位）。

"保留期限"这一概念是有意含糊的。服务器可以从邮件被加入信箱时开始计算到期天数，也可以从客户端通过 LIST 或 UIDL 命令得知该邮件存在时开始，或从邮件以某种方式被操作过（例如 TOP 或 RETR）时开始，或从其他某个事件开始。EXPIRE 能力无法精确指出任何一封特定邮件究竟何时到期。该能力的目的是让客户端更容易按照符合站点策略与用户意愿的方式行事。例如，当用户试图把"邮件留存服务器"的期限配置为大于等于服务器所公告值的某个百分比时，客户端可以显示警告。

如果某站点采用了任何自动删除策略，它应当使用 EXPIRE 能力来公告这一点。

参数不为 0 或 NEVER 的 EXPIRE 能力，意在让客户端知道服务器确实允许把邮件留在服务器上，并给出一个可能生效的最小值。

允许用户无限期保留邮件的站点应当以 EXPIRE NEVER 响应公告这一点。

如果过期策略因用户而异（即 EXPIRE 参数在认证后可能改变），服务器必须在 AUTHENTICATION 状态下公告可能为任何用户设定的最小值。该值可以是当前对任何用户实际使用的最小值（即每台服务器只有一个值），甚至可以是服务器允许为任何用户设定的最小值。服务器应当在 AUTHENTICATION 状态下于 EXPIRE 参数后追加标记 "USER"，以告知客户端认证之后可获得更精确的值；服务器应当在 TRANSACTION 状态下公告该更精确的值。（"USER" 标记使客户端能够判断是否需要第二次 CAPA 命令。）

某站点的邮件过期策略可能依据用户执行过哪些操作、或基于其他因素而对邮件区别对待。例如，某站点可能在 60 天后删除未读邮件，而在 15 天后删除已完全阅读或部分阅读的邮件。

所公告的 EXPIRE 值，是当前站点策略中任何类别或条件下、对任何用户（在 AUTHENTICATION 状态）或对特定用户（在 TRANSACTION 状态）正在使用或可能使用的最小保留期限。也就是说，EXPIRE 告知客户端：在任何情况下邮件可能留存在服务器上的最少天数。

示例：

EXPIRE 5 USER
EXPIRE 30
EXPIRE NEVER
EXPIRE 0

第一个示例表示服务器可能在 5 天后删除邮件，但该期限因用户而异，因此可在 TRANSACTION 状态下发出第二次 CAPA 命令以获得更精确的值。第二个示例表示服务器可能在 30 天后删除邮件。第三个示例中，服务器公告它不删除邮件。第四个示例规定该站点不允许把邮件留在服务器上。

6.8 UIDL 能力

CAPA 标签：UIDL；参数：无；新增命令：UIDL；受影响的标准命令：无；公告状态/是否可能有差异：两种状态 / 否；命令有效状态：TRANSACTION；规范引用：[POP3]。

讨论：UIDL 能力表示支持可选的 UIDL 命令。

6.9 IMPLEMENTATION 能力

CAPA 标签：IMPLEMENTATION；参数：给出服务器实现信息的字符串；新增命令：无；受影响的标准命令：无；公告状态/是否可能有差异：两种状态（也可仅在 TRANSACTION 状态）/ 否；命令有效状态：不适用；规范引用：本文档。

讨论：识别某台特定服务器的实现常常很有用（例如记录日志时）。这通常是在欢迎横幅中完成的，但人们只能猜测某个字符串是否为实现标识。

IMPLEMENTATION 能力的参数由一个或多个用于标识服务器的标记组成。（注意，由于 CAPA 响应标签的参数以空格分隔，让 IMPLEMENTATION 能力的参数不含空格、从而构成单个标记，可能会比较方便。）

通常，服务器在两种状态下都公告 IMPLEMENTATION。不过，服务器可以选择仅在 TRANSACTION 状态下这样做。服务器可以同时在欢迎横幅与 IMPLEMENTATION 能力中包含实现标识。

客户端不得基于服务器实现来改变自身行为；相反，服务器与客户端之间应当就某个私有扩展达成一致。

7. POP3 的未来扩展

总体上不鼓励对 POP3 作进一步扩展，因为 POP3 的价值正在于其简单性。POP3 被设计为一种"下载并删除"（download-and-delete）协议；邮件访问能力可通过 IMAP [IMAP4] 获得。凡是为额外信箱提供支持、允许向服务器上传邮件、或偏离 POP 的下载并删除模型的扩展，都被强烈不鼓励，并且不太可能被允许进入 IETF 标准跟踪。

客户端不得要求必须存在任何扩展才能实现基本功能，认证命令（APOP、AUTH［见 6.3 节］与 USER/PASS）除外。

第 9 节规定了如何定义额外的能力。

8. 扩展的 POP3 响应码

未经扩展的 POP3 对大多数命令只能表示成功或失败。遗憾的是，客户端往往需要了解更多关于失败原因的信息才能优雅地恢复。这一点在登录失败的响应中尤为重要（已有大量部署的客户端试图解码 PASS 命令结果的错误文本，以区分"无法获得信箱锁"与"登录信息错误"）。

本规范修订 POP3 标准，允许在 "+OK" 或 "-ERR" 响应的人类可读文本部分的开头，放置一个用方括号括起的可选响应码。支持本扩展的客户端可以在向用户显示人类可读文本之前移除方括号内的所有信息。紧随左方括号 "[" 字符之后的是响应码，客户端以大小写不敏感的方式解释它。

响应码是分层的，以 "/" 分隔关于该错误的各级细节。客户端必须忽略响应码中未知的层级细节——这一点很重要，因为将来可能需要为响应码提供更进一步的细节。

第 3 节用 [ABNF] 描述了响应码。如果服务器支持扩展响应码，它通过在 CAPA 响应中包含 RESP-CODES 能力来表明这一点。

示例：

C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: -ERR [IN-USE] Do you have another POP session running?

8.1 初始 POP3 响应码

本规范定义两个可用于确定登录失败原因的 POP3 响应码。第 9 节规定了如何定义额外的响应码。

8.1.1 LOGIN-DELAY 响应码

该响应码出现在对 AUTH、USER（见说明）、PASS 或 APOP 命令的 -ERR 响应中，表示该用户最近已经登录过，在登录延迟周期届满之前不会被允许再次登录。

说明：对 USER 命令返回 LOGIN-DELAY 响应码可以省去认证用户的开销，但同时也向客户端泄露了该指定用户存在这一事实。除非服务器运行在用户名并非秘密的环境中（例如许多流行的邮件客户端会在外发邮件头中公布 POP 服务器与用户名），或者服务器访问受到限制，或者服务器能够验证该连接来自同一用户，否则强烈建议服务器不要对 USER 命令发出此响应码。即便如此，服务器仍然省下了打开信箱的开销——在某些环境中这正是最昂贵的步骤。

8.1.2 IN-USE 响应码

该响应码出现在对 AUTH、APOP 或 PASS 命令的 -ERR 响应中。它表示认证已经成功，但用户的信箱当前正在被使用（很可能被另一个 POP3 客户端占用）。

9. IANA 考量

本文档请求 IANA 维护两个新的注册表：POP3 能力（capabilities）与 POP3 响应码（response codes）。

新的 POP3 能力必须在标准跟踪或经 IESG 批准的实验性 RFC 中定义，并且不得以字母 "X" 开头。

新的 POP3 能力必须包含以下信息：

此外，可能还需要包含 POP3 命令与响应长度的新限制。

新的 POP3 响应码必须在某个 RFC 或其他永久且易于获取的参考文献中定义，且细节需充分到足以让各自独立的实现之间实现互操作。（这就是 [IANA] 中所述的"需要规范"（Specification Required）策略。）

新的 POP3 响应码规范必须包含以下信息：完整的响应码、它对哪些响应（+OK 或 -ERR）与哪些命令有效，以及其含义与预期客户端行为的定义。

10. 安全考量

能力列表可能泄露关于服务器认证机制的信息，这些信息可被用来判断某些攻击是否会成功。然而，允许客户端自动检测更强机制的可用性并调整其配置以使用这些机制，可以提升站点的整体安全性。

第 8.1 节讨论了对 USER 命令使用 LOGIN-DELAY 响应码所涉及的安全问题。

11. 致谢

本文档的修订部分基于 IETF POP3 Extensions 邮件列表内外所进行的评论与讨论。感谢所有抽时间审阅本备忘录并提出建议的人士，特别是 Alexey Melnikov、Harald Alvestrand 与 Mike Gahrns 的帮助。

12. 参考文献

13. 作者地址

Randall Gellens，QUALCOMM Incorporated，6455 Lusk Blvd., San Diego, CA 92121-2779, USA。电话：+1 619 651 5115；传真：+1 619 845 7268；邮箱：randy@qualcomm.com

Chris Newman，Innosoft International, Inc.，1050 Lakes Drive, West Covina, CA 91790, USA。邮箱：chris.newman@innosoft.com

Laurence Lundblade，QUALCOMM Incorporated，6455 Lusk Blvd., San Diego, CA 92121-2779, USA。电话：+1 619 658 3584；传真：+1 619 845 7268；邮箱：lgl@qualcomm.com

14. 完整版权声明

Copyright (C) The Internet Society (1998). All Rights Reserved.

本文档及其译本可以被复制并提供给他人；对其进行注释或以其他方式解释、或协助其实现的衍生作品，也可以被全部或部分地准备、复制、发布与分发，不受任何形式的限制，前提是在所有此类副本与衍生作品上都包含上述版权声明与本段文字。但是，本文档本身不得以任何方式修改，例如移除版权声明或对互联网协会及其他互联网组织的引用；除非是出于制定互联网标准的需要（此时必须遵循互联网标准流程中定义的版权程序），或者是将其翻译为英语以外的语言所必需。

上述授予的有限许可是永久性的，不会被互联网协会或其继任者或受让人撤销。

本文档及其中所含信息以"按现状"（AS IS）的方式提供，互联网协会与互联网工程任务组不作任何明示或默示的担保，包括但不限于对使用本文中信息不会侵犯任何权利的担保，以及任何关于适销性或特定用途适用性的默示担保。

来源（Source）

本页译自 IETF 人类原始文本，英文原文与权威版本：

如中文表述与英文原文存在歧义，一律以 ietf.org / rfc-editor.org 英文原文为准。