非官方中文译本声明：本页为 IETF RFC 1939《Post Office Protocol - Version 3 (POP3)》 的中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布，受 BCP 78 与 IETF 信托法律条款约束；本译本保留原文编号与结构，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc1939。

RFC 1939：邮局协议（POP3）

Internet Engineering Task Force (IETF) · J. Myers（卡内基梅隆大学）、M. Rose（Dover Beach Consulting, Inc.）· STD: 53 · 取代：RFC 1725 · 类别：Standards Track（标准跟踪）· 1996 年 5 月

封面

本文档为《Post Office Protocol - Version 3（POP3，邮局协议第 3 版）》的规范文本。POP3 定义了客户端主机如何以一种有用的方式，从服务器主机上的信箱（maildrop）动态检索邮件，是经典的邮件收取协议。通常，这意味着使用 POP3 协议让工作站检索服务器为其保存的邮件。

本备忘录的状态

本文档为互联网社区规定了一种互联网标准跟踪（Standards Track）协议，并请求讨论与改进建议。有关本协议的标准化状态与现状，请参考最新版《Internet Official Protocol Standards》（STD 1）。本备忘录的分发不受限制。

目录

1. 引言

在互联网上某些较小类型的节点上，通常难以维护消息传输系统（MTS）。例如，一台工作站可能没有足够的资源（CPU 周期、磁盘空间）来使 SMTP 服务器 [RFC821] 以及相关的本地邮件投递系统常驻并持续运行。类似地，让个人计算机长时间与 IP 风格的网络保持互联可能代价高昂（或不可能）（该节点缺乏被称为"连通性"的资源）。

尽管如此，在这些较小节点上管理邮件通常非常有用，并且它们通常支持一个用户代理（UA）以辅助邮件处理任务。为解决这个问题，一个能够支持 MTS 实体的节点向这些资源较少的节点提供信箱（maildrop）服务。邮局协议第 3 版（POP3）旨在让工作站以有用的方式动态访问服务器主机上的信箱。通常，这意味着使用 POP3 协议让工作站检索服务器为其保存的邮件。

POP3 并非旨在提供对服务器上邮件的广泛操作；通常，邮件被下载然后删除。一个更高级（且更复杂）的协议 IMAP4 在 [RFC1730] 中讨论。

在本备忘录的其余部分，术语"客户端主机"指使用 POP3 服务的主机，而术语"服务器主机"指提供 POP3 服务的主机。

2. 简短题外话

本备忘录未规定客户端主机如何将邮件送入传输系统，不过这里给出一种符合本备忘录理念的方法：

当用户代理在客户端主机上希望将一条消息送入传输系统时，它与自己的中继主机建立 SMTP 连接并将所有邮件发送给它。该中继主机可以是、但不必是客户端主机的 POP3 服务器主机。当然，中继主机必须接受向任意收件人地址的邮件投递，并非所有 SMTP 服务器都要求具备该功能。

3. 基本操作

最初，服务器主机通过监听 TCP 端口 110 来启动 POP3 服务。当客户端主机希望使用该服务时，它与服务器主机建立一条 TCP 连接。连接建立后，POP3 服务器发送一条问候语。随后客户端与 POP3 服务器相互交换命令与响应（分别对应），直到连接被关闭或异常中止。

POP3 中的命令由一个不区分大小写的关键字组成，其后可能跟随一个或多个参数。所有命令都以 CRLF（回车换行）对结束。关键字与参数由可打印的 ASCII 字符组成。关键字与参数之间各以一个空格（SPACE）字符分隔。关键字长度为三或四个字符。每个参数最长可达 40 个字符。

POP3 中的响应由一个状态指示符和一个关键字组成，其后可能跟随附加信息。所有响应都以 CRLF 对结束。响应长度（包括结尾的 CRLF）最长可达 512 个字符。当前有两种状态指示符：肯定（"+OK"）与否定（"-ERR"）。服务器 MUST（必须）以大写形式发送 "+OK" 和 "-ERR"。

对某些命令的响应是多行的。在这些（下文明确指出的）情况下，发送响应的第一行及一个 CRLF 之后，会发送任意附加行，每行以一个 CRLF 对结束。当响应的所有行都已发送后，会发送最后一行，由终止八位组（十进制码 046，"."）和一个 CRLF 对组成。如果多行响应中的任何一行以终止八位组开头，则该行通过在该响应行前加上一个终止八位组而实现"字节填充"（byte-stuffing）。因此，多行响应以五个八位组 "CRLF.CRLF" 结束。客户端在检查多行响应时，会查看该行是否以终止八位组开头。若是，且其后跟随的不是 CRLF，则去掉该行的第一个八位组（终止八位组）。若是，且终止字符后紧跟着 CRLF，则来自 POP 服务器的响应结束，且包含 ".CRLF" 的那一行不被视为多行响应的一部分。

POP3 会话在其生命周期内会经历若干个状态。一旦 TCP 连接被打开且 POP3 服务器已发送问候语，会话便进入授权（AUTHORIZATION）状态。在此状态下，客户端必须向 POP3 服务器表明自身身份。一旦客户端成功完成此操作，服务器获取与客户端信箱相关联的资源，会话进入事务（TRANSACTION）状态。在此状态下，客户端向 POP3 服务器请求执行动作。当客户端发出 QUIT 命令后，会话进入更新（UPDATE）状态。在此状态下，POP3 服务器释放事务状态期间获取的任何资源并道别。随后 TCP 连接被关闭。

服务器 MUST（必须）对无法识别、未实现或语法无效的命令以否定状态指示符作出响应。服务器 MUST（必须）对在不正确的状态下发出的命令以否定状态指示符作出响应。客户端没有通用方法来区分"未实现某可选命令的服务器"与"不愿或无法处理该命令的服务器"。

POP3 服务器 MAY（可以）拥有一个不活动自动登出计时器。该计时器 MUST（必须）至少有 10 分钟的时长。在该间隔内收到来自客户端的任何命令都应足以重置自动登出计时器。当计时器到期时，会话不会进入更新状态——服务器应关闭 TCP 连接，而不移除任何消息，也不向客户端发送任何响应。

4. 授权状态（AUTHORIZATION）

一旦 TCP 连接由 POP3 客户端打开，POP3 服务器就发出一行问候语。这可以是任何肯定响应。例如：

S:  +OK POP3 server ready

POP3 会话现在处于授权状态。客户端现在必须向 POP3 服务器标识并认证自身。本文档描述了两种可能的机制：USER 与 PASS 命令组合，以及 APOP 命令。两种机制均在本文档后文描述。其他认证机制在 [RFC1734] 中描述。尽管并不要求所有 POP3 服务器都实现某一种单一的认证机制，但 POP3 服务器当然必须至少支持一种认证机制。

一旦 POP3 服务器通过任何认证命令确定应给予客户端对相应信箱的访问权，POP3 服务器便获取该信箱上的独占访问锁，以防在会话进入更新状态之前消息被修改或移除。如果锁获取成功，POP3 服务器以肯定状态指示符响应。POP3 会话现在进入事务状态，没有任何消息被标记为已删除。如果由于某种原因无法打开信箱（例如，无法获取锁、客户端被拒绝访问相应信箱，或信箱无法被解析），POP3 服务器以否定状态指示符响应。（如果曾获取锁但 POP3 服务器打算以否定状态指示符响应，POP3 服务器必须在拒绝该命令之前释放该锁。）返回否定状态指示符后，服务器 MAY（可以）关闭连接。如果服务器不关闭连接，客户端可以发出新的认证命令并重新开始，也可以发出 QUIT 命令。

在 POP3 服务器打开信箱之后，它为每一条消息分配一个报文编号（message-number），并记录每条消息以八位组计的字节大小。信箱中的第一条消息被赋予报文编号 "1"，第二条为 "2"，依此类推，因此信箱中的第 n 条消息被赋予报文编号 "n"。在 POP3 命令与响应中，所有报文编号与报文大小都以十进制（base-10）表示。

以下是 QUIT 命令在授权状态下的摘要：

QUIT 命令

QUIT

   Arguments: none

   Restrictions: none

   Possible Responses:
       +OK

   Examples:
       C: QUIT
       S: +OK dewey POP3 server signing off

5. 事务状态（TRANSACTION）

一旦客户端成功向 POP3 服务器表明自身身份，且 POP3 服务器已锁定并打开相应的信箱，POP3 会话便处于事务状态。客户端现在可以反复发出以下任意 POP3 命令。每条命令之后，POP3 服务器发出一条响应。最终，客户端发出 QUIT 命令，POP3 会话进入更新状态。

以下是事务状态下有效的 POP3 命令：

STAT 命令

讨论：POP3 服务器发出一条肯定响应，其中包含关于该信箱的一行信息。该行被称为该信箱的"信箱清单"（drop listing）。

为简化解析，要求所有 POP3 服务器对信箱清单使用某种固定格式。肯定响应由 "+OK"、一个空格、信箱中的消息数、一个空格，以及信箱以八位组计的大小组成。本备忘录对信箱大小之后跟什么内容不作要求。最小实现只需以 CRLF 对结束该响应行。更高级的实现 MAY（可以）包含其他信息。

注意：本备忘录强烈反对实现在信箱清单中提供附加信息。后文讨论了其他可选机制，允许客户端解析信箱中的消息。

注意，被标记为已删除的消息不计入任何一个总数。

STAT

   Arguments: none

   Restrictions:
       may only be given in the TRANSACTION state

   Possible Responses:
       +OK nn mm

   Examples:
       C: STAT
       S: +OK 2 320

LIST 命令

讨论：如果给定了参数且 POP3 服务器发出肯定响应，则响应包含关于该消息的一行信息。该行被称为该消息的"扫描清单"（scan listing）。

如果未给定参数且 POP3 服务器发出肯定响应，那么给出的响应是多行的。在初始的 +OK 之后，对于信箱中的每条消息，POP3 服务器都响应一行包含该消息信息的内容。该行也被称为该消息的"扫描清单"。如果信箱中没有消息，则 POP3 服务器不响应任何扫描清单——它发出一条肯定响应，后跟一行包含终止八位组与 CRLF 对的内容。

为简化解析，要求所有 POP3 服务器对扫描清单使用某种固定格式。扫描清单由该消息的报文编号、一个空格，以及以八位组计的该消息精确大小组成。"精确大小"的计算方法在下面的"报文格式"一节中描述。本备忘录对扫描清单中消息大小之后跟什么内容不作要求。最小实现只需以 CRLF 对结束该响应行。更高级的实现 MAY（可以）包含从消息中解析出的其他信息。

注意：本备忘录强烈反对实现在扫描清单中提供附加信息。后文讨论了其他可选机制，允许客户端解析信箱中的消息。

注意，被标记为已删除的消息不会被列出。

LIST [msg]

   Arguments:
       a message-number (optional), which, if present, may NOT
       refer to a message marked as deleted

   Restrictions:
       may only be given in the TRANSACTION state

   Possible Responses:
       +OK scan listing follows
       -ERR no such message

   Examples:
       C: LIST
       S: +OK 2 messages (320 octets)
       S: 1 120
       S: 2 200
       S: .
         ...
       C: LIST 2
       S: +OK 2 200
         ...
       C: LIST 3
       S: -ERR no such message, only 2 messages in maildrop

RETR 命令

讨论：如果 POP3 服务器发出肯定响应，那么给出的响应是多行的。在初始的 +OK 之后，POP3 服务器发送与给定报文编号对应的消息，并小心地对终止字符进行字节填充（与所有多行响应一样）。

RETR msg

   Arguments:
       a message-number (required) which may NOT refer to a
       message marked as deleted

   Restrictions:
       may only be given in the TRANSACTION state

   Possible Responses:
       +OK message follows
       -ERR no such message

   Examples:
       C: RETR 1
       S: +OK 120 octets
       S: <the POP3 server sends the entire message here>
       S: .

DELE 命令

讨论：POP3 服务器将该消息标记为已删除。此后在 POP3 命令中对该消息关联报文编号的任何引用都会产生错误。POP3 服务器实际删除该消息，要等到 POP3 会话进入更新状态时才进行。

DELE msg

   Arguments:
       a message-number (required) which may NOT refer to a
       message marked as deleted

   Restrictions:
       may only be given in the TRANSACTION state

   Possible Responses:
       +OK message deleted
       -ERR no such message

   Examples:
       C: DELE 1
       S: +OK message 1 deleted
         ...
       C: DELE 2
       S: -ERR message 2 already deleted

NOOP 命令

讨论：POP3 服务器不做任何事，仅以肯定响应回复。

NOOP

   Arguments: none

   Restrictions:
       may only be given in the TRANSACTION state

   Possible Responses:
       +OK

   Examples:
       C: NOOP
       S: +OK

RSET 命令

讨论：如果 POP3 服务器已将某些消息标记为已删除，则取消其标记。随后 POP3 服务器以肯定响应回复。

RSET

   Arguments: none

   Restrictions:
       may only be given in the TRANSACTION state

   Possible Responses:
       +OK

   Examples:
       C: RSET
       S: +OK maildrop has 2 messages (320 octets)

6. 更新状态（UPDATE）

当客户端从事务状态发出 QUIT 命令时，POP3 会话进入更新状态。（注意，如果客户端从授权状态发出 QUIT 命令，POP3 会话终止，但不会进入更新状态。）

如果会话因客户端发出的 QUIT 命令以外的原因而终止，则 POP3 会话不会进入更新状态，且 MUST（必须）不从信箱中移除任何消息。

QUIT 命令

讨论：POP3 服务器从信箱中移除所有被标记为已删除的消息，并就本次操作的状态作出回复。如果在移除消息时遇到错误（例如资源不足），信箱可能最终只移除了部分或全部标记为已删除的消息。在任何情况下，服务器都不得移除任何未被标记为已删除的消息。

无论移除是否成功，服务器随后释放信箱上的任何独占访问锁，并关闭 TCP 连接。

QUIT

   Arguments: none

   Restrictions: none

   Possible Responses:
       +OK
       -ERR some deleted messages not removed

   Examples:
       C: QUIT
       S: +OK dewey POP3 server signing off (maildrop empty)
         ...
       C: QUIT
       S: +OK dewey POP3 server signing off (2 messages left)
         ...

7. 可选 POP3 命令

上述讨论的 POP3 命令必须被所有最小化的 POP3 服务器实现所支持。

下面描述的可选 POP3 命令在保留简单 POP3 服务器实现的同时，赋予 POP3 客户端在消息处理上更大的自由度。

注意：本备忘录强烈鼓励实现支持这些命令，以取代开发增强的信箱清单与扫描清单。简而言之，本备忘录的理念是把智能放在 POP3 客户端一侧，而非 POP3 服务器一侧。

TOP 命令

讨论：如果 POP3 服务器发出肯定响应，那么给出的响应是多行的。在初始的 +OK 之后，POP3 服务器发送该消息的报文头、分隔报文头与主体的空行，以及所指示消息主体的若干行，并小心地对终止字符进行字节填充（与所有多行响应一样）。

注意，如果 POP3 客户端请求的行数大于主体中的行数，则 POP3 服务器发送整条消息。

TOP msg n

   Arguments:
       a message-number (required) which may NOT refer to to a
       message marked as deleted, and a non-negative number
       of lines (required)

   Restrictions:
       may only be given in the TRANSACTION state

   Possible Responses:
       +OK top of message follows
       -ERR no such message

   Examples:
       C: TOP 1 10
       S: +OK
       S: <the POP3 server sends the headers of the
          message, a blank line, and the first 10 lines
          of the body of the message>
       S: .
         ...
       C: TOP 100 3
       S: -ERR no such message

UIDL 命令

讨论：如果给定了参数且 POP3 服务器发出肯定响应，则响应包含关于该消息的一行信息。该行被称为该消息的"唯一标识清单"（unique-id listing）。

如果未给定参数且 POP3 服务器发出肯定响应，那么给出的响应是多行的。在初始的 +OK 之后，对于信箱中的每条消息，POP3 服务器都响应一行包含该消息信息的内容。该行被称为该消息的"唯一标识清单"。

为简化解析，要求所有 POP3 服务器对唯一标识清单使用某种固定格式。唯一标识清单由该消息的报文编号、一个空格，以及该消息的唯一标识（unique-id）组成。唯一标识之后在唯一标识清单中不跟随任何信息。

一条消息的唯一标识是一个由服务器任意确定的字符串，由 0x21 至 0x7E 范围内的 1 到 70 个字符组成，它在某个信箱内唯一地标识一条消息，并在会话之间持久存在。即使会话在未进入更新状态的情况下结束，这种持久性也是必需的。只要使用该唯一标识的实体存在，服务器就永远不应在给定的信箱中重用某个唯一标识。

注意，被标记为已删除的消息不会被列出。

尽管通常更可取的做法是让服务器实现将任意分配的唯一标识存储于信箱中，但本规范也允许将唯一标识计算为消息的哈希值。客户端应能够处理信箱中存在两条相同副本的消息具有同一唯一标识的情况。

UIDL [msg]

   Arguments:
       a message-number (optional), which, if present, may NOT
       refer to a message marked as deleted

   Restrictions:
       may only be given in the TRANSACTION state.

   Possible Responses:
       +OK unique-id listing follows
       -ERR no such message

   Examples:
       C: UIDL
       S: +OK
       S: 1 whqtswO00WBw418f9t5JxYwZ
       S: 2 QhdPYR:00WBw1Ph7x7
       S: .
         ...
       C: UIDL 2
       S: +OK 2 QhdPYR:00WBw1Ph7x7
         ...
       C: UIDL 3
       S: -ERR no such message, only 2 messages in maildrop

USER 命令

讨论：要使用 USER 与 PASS 命令组合进行认证，客户端必须先发出 USER 命令。如果 POP3 服务器以肯定状态指示符（"+OK"）响应，则客户端可以发出 PASS 命令以完成认证，或发出 QUIT 命令以终止 POP3 会话。如果 POP3 服务器对 USER 命令以否定状态指示符（"-ERR"）响应，则客户端可以发出新的认证命令，也可以发出 QUIT 命令。

即使并不存在这样的信箱，服务器也可能返回肯定响应。如果信箱存在但不允许明文口令认证，服务器也可能返回否定响应。

USER name

   Arguments:
       a string identifying a mailbox (required), which is of
       significance ONLY to the server

   Restrictions:
       may only be given in the AUTHORIZATION state after the POP3
       greeting or after an unsuccessful USER or PASS command

   Possible Responses:
       +OK name is a valid mailbox
       -ERR never heard of mailbox name

   Examples:
       C: USER frated
       S: -ERR sorry, no mailbox for frated here
         ...
       C: USER mrose
       S: +OK mrose is a real hoopy frood

PASS 命令

讨论：当客户端发出 PASS 命令时，POP3 服务器使用来自 USER 与 PASS 命令的参数对，来确定是否应给予客户端对相应信箱的访问权。

由于 PASS 命令恰好有一个参数，POP3 服务器可以将参数中的空格视为口令的一部分，而非参数分隔符。

PASS string

   Arguments:
       a server/mailbox-specific password (required)

   Restrictions:
       may only be given in the AUTHORIZATION state immediately
       after a successful USER command

   Possible Responses:
       +OK maildrop locked and ready
       -ERR invalid password
       -ERR unable to lock maildrop

   Examples:
       C: USER mrose
       S: +OK mrose is a real hoopy frood
       C: PASS secret
       S: -ERR maildrop already locked
         ...
       C: USER mrose
       S: +OK mrose is a real hoopy frood
       C: PASS secret
       S: +OK mrose's maildrop has 2 messages (320 octets)

APOP 命令

讨论：通常，每次 POP3 会话都以 USER/PASS 交换开始。这导致一个服务器/用户标识特定的口令以明文形式在网络上传送。对于 POP3 的间歇性使用，这或许不会带来太大风险。然而，许多 POP3 客户端实现会定期连接 POP3 服务器——以检查是否有新邮件。此外，会话发起的间隔可能短至五分钟左右。因此，口令被截获的风险大大增加。

需要一种替代的认证方法，既提供源认证（origin authentication）又提供重放保护（replay protection），但不涉及在网络上以明文发送口令。APOP 命令提供了这一功能。

实现 APOP 命令的 POP3 服务器会在其欢迎横幅（banner greeting）中包含一个时间戳。该时间戳的语法对应于 [RFC822] 中的 `msg-id'，且 MUST（必须）在 POP3 服务器每次发出欢迎横幅时都不同。例如，在一个为每个 POP3 服务器实例使用独立 UNIX 进程的 UNIX 实现中，时间戳的语法可能是：

   <process-ID.clock@hostname>

其中 `process-ID' 是该进程 PID 的十进制值，clock 是系统时钟的十进制值，hostname 是运行 POP3 服务器的主机的完全限定域名。

POP3 客户端记下该时间戳，然后发出 APOP 命令。`name' 参数与 USER 命令的 `name' 参数语义相同。`digest' 参数通过将 MD5 算法 [RFC1321] 应用于一个由时间戳（含尖括号）后跟一个共享密钥组成的字符串来计算得到。该共享密钥是一个仅为 POP3 客户端与服务器所知的字符串。应极为谨慎地防止该密钥被未授权披露，因为一旦知悉该密钥，任何实体都能成功地冒充被命名的用户。`digest' 参数本身是一个 16 八位组的值，以十六进制格式发送，使用小写字 ASCII 字符。

当 POP3 服务器收到 APOP 命令时，它验证所提供的摘要（digest）。如果摘要正确，POP3 服务器发出肯定响应，POP3 会话进入事务状态。否则，发出否定响应，POP3 会话仍停留在授权状态。

注意，随着共享密钥长度的增加，推导出它的难度也随之增加。因此，共享密钥应为长字符串（明显长于下所示例中的 8 个字符）。

APOP name digest

   Arguments:
       a string identifying a mailbox and a MD5 digest string
       (both required)

   Restrictions:
       may only be given in the AUTHORIZATION state after the POP3
       greeting or after an unsuccessful USER or PASS command

   Possible Responses:
       +OK maildrop locked and ready
       -ERR permission denied

   Examples:
       S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
       C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
       S: +OK maildrop has 1 message (369 octets)

       In this example, the shared  secret  is  the  string  `tan-
       staaf'.  Hence, the MD5 algorithm is applied to the string

          <1896.697170952@dbc.mtview.ca.us>tanstaaf

       which produces a digest value of

          c4c9334bac560ecc979e58001b3e22fb

8. 扩展与运维考量

由于上述某些可选特性被加入到 POP3 协议之中，在使用它们的、大多数用户彼此无关的大规模商业邮局运营中已积累了经验。在这些以及其他情境中，POP3 客户端用户与供应商发现，结合使用 UIDL 命令且不发出 DELE 命令，可以提供一种通常关联于 IMAP 的"信箱作为半永久存储库"功能的弱版本。当然，IMAP 的其他能力，例如轮询已有连接以获取新到达的消息，以及支持服务器上的多文件夹，在 POP3 中并不存在。

当临时用户以这种方式使用这些设施时，已读消息有在服务器上无限制累积的趋势。从服务器运营者的角度看，这显然是一种不可取的行为模式。POP3 能力有限这一事实加剧了这种情况——它不允许高效地处理拥有数百或数千条消息的信箱。

因此，建议大规模多用户服务器的运营者，特别是那些用户只能通过 POP3 访问信箱的服务器运营者，考虑如下选项：

9. POP3 命令汇总

   Minimal POP3 Commands:

      USER name               valid in the AUTHORIZATION state
      PASS string
      QUIT

      STAT                    valid in the TRANSACTION state
      LIST [msg]
      RETR msg
      DELE msg
      NOOP
      RSET
      QUIT

   Optional POP3 Commands:

      APOP name digest        valid in the AUTHORIZATION state

      TOP msg n               valid in the TRANSACTION state
      UIDL [msg]

   POP3 Replies:

      +OK
      -ERR

注意，除 STAT、LIST 与 UIDL 命令外，POP3 服务器对任何命令给出的响应，其意义仅在于 "+OK" 和 "-ERR"。该响应之后出现的任何文本都可能被客户端忽略。

10. POP3 会话示例

   S: <wait for connection on TCP port 110>
   C: <open connection>
   S:    +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
   C:    APOP mrose c4c9334bac560ecc979e58001b3e22fb
   S:    +OK mrose's maildrop has 2 messages (320 octets)
   C:    STAT
   S:    +OK 2 320
   C:    LIST
   S:    +OK 2 messages (320 octets)
   S:    1 120
   S:    2 200
   S:    .
   C:    RETR 1
   S:    +OK 120 octets
   S:    <the POP3 server sends message 1>
   S:    .
   C:    DELE 1
   S:    +OK message 1 deleted
   C:    RETR 2
   S:    +OK 200 octets
   S:    <the POP3 server sends message 2>
   S:    .
   C:    DELE 2
   S:    +OK message 2 deleted
   C:    QUIT
   S:    +OK dewey POP3 server signing off (maildrop empty)
   C:  <close connection>
   S:  <wait for next connection>

11. 报文格式

POP3 会话期间传输的所有消息，均假定符合互联网文本消息格式的标准 [RFC822]。

需要注意，由于标识行尾的本地约定不同，服务器主机上某条消息的八位组计数，可能与分配给该消息的八位组计数不同。通常，在 POP3 会话的授权状态期间，POP3 服务器能够在打开信箱时计算每条消息以八位组计的大小。例如，如果 POP3 服务器主机在内部以单个字符表示行尾，那么 POP3 服务器只需将该消息中此字符的每次出现计为两个八位组。注意，以终止八位组开头的消息行无需（也不得）被计数两次，因为 POP3 客户端在接收到多行响应时会移除所有经过字节填充的终止字符。

12. 参考文献

13. 安全性考量

据推测，使用 APOP 命令为 POP3 会话提供了源识别与重放保护。相应地，同时实现了 PASS 与 APOP 命令的 POP3 服务器，不应允许对给定用户同时使用两种访问方式；也就是说，对于给定的信箱名，要么允许 USER/PASS 命令序列，要么允许 APOP 命令，但不能两者都允许。

此外，注意随着共享密钥长度的增加，推导出它的难度也随之增加。

对 USER 命令回答 -ERR 的服务器，正在向潜在的攻击者透露哪些名字是有效的线索。

使用 PASS 命令会在网络上以明文发送口令。

使用 RETR 与 TOP 命令会在网络上以明文发送邮件。

除此之外，本备忘录不讨论安全问题。

14. 致谢

POP 系列有着漫长而曲折的历史。尽管 POP3 主要是对 RFC 1460 的小幅修订，但它基于 RFC 918、937 与 1081 中提出的理念。

此外，Alfred Grimstad、Keith McCloghrie 与 Neil Ostroff 对 APOP 命令提供了重要意见。

15. 作者地址

   John G. Myers
   Carnegie-Mellon University
   5000 Forbes Ave
   Pittsburgh, PA 15213

   EMail: jgm+@cmu.edu


   Marshall T. Rose
   Dover Beach Consulting, Inc.
   420 Whisman Court
   Mountain View, CA  94043-2186

   EMail: mrose@dbc.mtview.ca.us

附录 A. 与 RFC 1725 的差异

本备忘录是对草案标准（Draft Standard）RFC 1725 的一次修订。它相对于该文档作了如下更改：

附录 B. 命令索引

   APOP .......................................................   15
   DELE .......................................................    8
   LIST .......................................................    6
   NOOP .......................................................    9
   PASS .......................................................   14
   QUIT .......................................................    5
   QUIT .......................................................   10
   RETR .......................................................    8
   RSET .......................................................    9
   STAT .......................................................    6
   TOP ........................................................   11
   UIDL .......................................................   12
   USER .......................................................   13