POP3 学习

http://blog.csdn.net/bukebushuo/article/details/1776220 Network Working Group J. Myers Request for Comments: 1939 Carnegie Mellon STD: 53 M. Rose Obsoletes: 1725 Dover Beach Consulting, Inc. Category: Standards Track May 1996 Post Office Protocol - Version 3 本备忘录状态 本备忘录指明了用于Internet通信的Internet标准协议，它仍然需要讨论和建议以便更好的改进。通过查阅当前版本 的”Internet Official Protocol Standards”(STD 1)可以获取本协议的标准化陈述和状态。传播本备忘录无任何限制。 内容表 1. 简介 ………………………………………… 2 2. 题外话 …………………………………… 2 3. 基础操作 ……………………………………… 3 4. AUTHORIZATION 状态 ………………………………. 4 QUIT 命令 ………………………………………… 5 5. TRANSACTION 状态 ………………………………… 5 STAT 命令 ………………………………………… 6 LIST 命令 ………………………………………… 6 RETR 命令 ………………………………………… 8 DELE 命令 ………………………………………… 8 NOOP 命令 ………………………………………… 9 RSET 命令 ………………………………………… 9 6. UPDATE 状态 …………………………………….. 10 QUIT 命令 ………………………………………… 10 7. 可选 POP3 命令 ……………………………….. 11 TOP 命令 …………………………………………. 11 UIDL 命令 ………………………………………… 12 USER 命令 ………………………………………… 13 PASS 命令 ………………………………………… 14 APOP 命令 ………………………………………… 15 8. Scaling and Operational Considerations …………………. 16 9. POP3 命令汇总…………………………………. 18 10. Example POP3 Session ………………………………… 19 11. 消息格式 ……………………………………… 19 12. References …………………………………………. 20 13. Security Considerations ……………………………… 20 14. Acknowledgements ……………………………………. 20 15. Authors’ Addresses ………………………………….. 21 Appendix A. Differences from RFC 1725 …………………….. 22 Myers & Rose Standards Track [Page 1] RFC 1939 POP3 May 1996 Appendix B. Command Index ……………………………….. 23 1. 简介 对 于Internet上的小结点来说，维护一个信息传输系统(message transport system - MTS)是不切实际的。比如，一个工作站可能没有足够的资源(周期，磁盘空间)来允许SMTP服务器[RFC821]和关联的本地邮件分发系统长期占据磁 盘空间和连续运行。类似的，将一台个人计算机长时间的连接在IP-类型的网络上的费用是昂贵或者说是没有必要的(需要资源的节点被称为连通性). 但 是，如果在这些小结点上可以管理邮件将十分的有用，它们常常支持以用户代理的方式解决邮件处理的任务。为了解决这个问题，支持MTS实体的节点为那些不支 持的节点提供邮件包裹服务。POP3协议是为了允许一个工作站能够动态的访问一个服务器上的邮件包裹。通俗的讲就是POP3协议是用来允许一个工作站能过 获取存储在服务器上的邮件。 POP3并不打算提供额外的邮件处理操作；一般情况下邮件下载后就会被删除。[RFC1730]中介绍了另外一个更加高级（或者说复杂）的协议——IMAP4。 在本备忘录的后面的文字中，”客户主机”指的是使用POP3服务的主机，”服务器主机”指的是提供POP3服务的主机。 2. 一点小的说明 当 位于客户主机上的用户代理希望将一条信息放入传输系统时，它就同它的转播主机之间建立一个SMTP连接，然后把所有的邮件发给转播主机。这个转播主机可能 是，但并不一定是，一台POP3服务器主机。当然了，转播主机必须能够接收要转发到任意地址的邮件，这种功能并不是每台SMTP服务器都要有的。 Myers & Rose Standards Track [Page 2] RFC 1939 POP3 May 1996 3. 基本的操作 首先，服务器主机通过监听TCP的110端口来启动POP3服 务。当客户端主机需要使用这个服务的时候，它就同服务器之间建立一个TCP连接。当连接成功建立后，POP3服务器发送一条问候信息。然后，客户端和 POP3服务器之间就开始交换命令和响应，直到连接关闭或者中断为止。 POP3中的命令是有一些区分大小写的关键字组成的，命令后面可能跟着一个 或多个参数。所有的命令都以一个CRLF对结束。关键字和参数是有可打印的ASCII字符组成的。关键字和参数之间由一个空格字符分割开。关键字一般长度 是3或4个字符，而参数可能达到40个字符长。 POP3中的响应是由一个状态指示和一个可能带有附加信息的关键字组成。所有的响应都以一个 CRLF对结束。响应可以最大为512个字符长（包括最后的CRLF）。目前有两种状态指示：肯定的(”+OK”)和否定的(”-ERR”)。服务器必须 以大写的形式发送”+OK”和”-ERR”。 某些命令的响应可能会有多行，在这种情况下，在发送完第一行的响应和一个CRLF后，接着发送后续行 的响应，并且每行都要以一个CRLF结束。当所有的行都发送完毕后，再发送一个结束行，结束行要以一个字节的结束字符（十进制码046，”.”）和一个 CRLF对结束。如果多行响应中的任何一行以字节的结束符开头，那么一行是把字节结束符填充到这一行的开始达到字节对齐的目的。因此，一个多行的响应以5 个字节”CRLF.CRLF”结束。当检查一个多行响应时，客户端要检查这一行是否以字节的结束符开头。如果是并且紧跟其后的不是CRLF，那么开头的字 节结束符（也就是字节的终止符）就要丢掉。如果是并且紧跟其后的是一个CRLF，那么从POP服务器的响应到此结束，包行”.CRLF”的行不被当作多行 响应的一部分。 一个POP3会话在它的声明期中会在多个状态之间转变。一旦建立了TCP连接，并且POP3服务器发送了欢迎信息，会话就进入了 AUHORIZATION状态。在这种状态下，客户端必须向POP3服务器表明自己的身份。如果客户端成功的做到了这一点，服务器获得了关联到这个客户的 相关邮件信息后，会话进入到TRANSACTION状态。在这个状态下，客户可以在POP3服务器上请求一些操作。 Myers & Rose Standards Track [Page 3] RFC 1939 POP3 May 1996 如果客户发出了QUIT命令，会话就进入UPDATE状态。在这个状态下，POP3服务器释放在TRANSACTION状态中使用的资源，然后发出GoodBye信息，接着连接关闭。 服务器必须对所有的无法识别的、未实现的或者语法无效的命令响应一条否定信息。服务器必须对在不正确的会话状态下的命令响应一个否定信息。并不存在一种方法能够使客户端判断究竟是服务器没有实现一个命令还是不期望、不能执行这个命令。 POP3 服务器可以拥有一个自动登出定时器。这个定时器必须至少持续10分钟。并且在这个间隔内，每从客户端收到一条命令都要重置这个登出定时器。如果到了时间限 制，而会话没有进入UPDATE状态–那么服务器应该关闭这个TCP连接，并且不删除任何消息，也不向客户端发送任何响应。 4. AUTHORIZATION状态(译者注：为方便编写程序，这些术语将不被翻译) 一旦一个POP3客户端建立了TCP连接，POP3服务器就发送一行欢迎信息。它可以是任何确定的响应，下面是一个例子： S: +OK POP3 server ready 现 在POP3会话已经是AUTHORIZATION状态了。现在客户端必须向POP3服务器表明身份。本文档中描述了实现这个机制的两种方法：1是 USER、PASS命令联合使用，2是使用APOP命令。这两种机制将在稍后介绍。[RFC1734]中描述了另外的鉴定身份的机制。虽然并没有强制所有 的POP3服务器必须满足哪种机制，但是一个POP3服务器必须至少支持一种机制。 不管使用哪种审核机制，只要POP3服务器确定客户端可以访问 适当的邮件包裹时，为了防止这个会话进入UPDATE前消息被更改或删除，POP3服务器就使用独占访问锁定这个邮件包裹。如果锁定成功，POP3服务器 响应一个确定指示。接下来这个POP3会话进入TRANSACTION状态，没有消息会标记为删除。如果这个maildrop因为某些原因不能打开（比 如，无法锁定资源，客户端被拒绝访问这个maildrop，又或者这个maildrop不能被解析），POP3服务响应一个否定状态指示。 Myers & Rose Standards Track [Page 4] RFC 1939 POP3 May 1996 （如果成功锁定了资源，但是POP3服务器想要响应一个否定状态指示，那么POP3服务器必须在驳回命令前先释放锁定。）返回了否定状态指示后，服务器可能关闭关闭连接。如果服务器没有关闭连接，客户端可能发送一个新的鉴定命令并重新开始，也可能发送一个QUIT命令。 POP3 服务器打开maildrop后，它为每条消息分配一个序号，并以字节注明消息的长度。maildrop中的第一条消息的序号是”1″,第二条消息是”2″ ,依次类推，因此第n条消息的序号就是”n”。在POP3命令和响应中，所有消息的序号和消息长度都是10进制的方式表示。 下面是在AUTHORIZATION状态中使用的QUIT命令的介绍 QUIT 参数: 无 约束: 无 可能的响应： +OK 例子： C: QUIT S: +OK dewey POP3 server signing off 5. TRANSACTION状态 如 果客户端成功的向POP3服务器表明了身份，POP3服务器也成功的锁定并打开了对应的maildrop，POP3会话就进入了TRANSACTION状 态。接下来客户端可能重复的发送下面POP3命令中的任何一个。对于每个命令，POP3服务器都发送一条响应。最后，客户端发送QUIT命令，然后 POP3会话进入UPDATE状态 Myers & Rose Standards Track [Page 5] RFC 1939 POP3 May 1996 下面是在TRANSACTION 状态中有效的POP3命令： STAT 参数: 无 约束: 只能在TRANSACTION 状态下使用 讨论: POP3服务器发送一个确认响应和一行包含maildrop信息的内容。这一行被称为这个maildrop的”包裹清单”。 为 了简化解析，所有的POP3服务器都应该使用相同的格式显示包裹清单。确认响应由”+OK”+单空格+maildrop中的信息数+单空格+字节数表示的 maildrop大小。本备忘录不对maildrop大小后的信息做规定。最短的方案应该就在它后面加一个CRLF对。高级的实现可以包括一些其他信息。 说明：本备忘录强烈反对在包裹清单中带附加信息。另外，后面将讨论如何使客户端解析消息更加方便。 另外注意一点被标记为已删除的消息不会被算到消息总数里面。 可能的响应: +OK nn mm 比如: C: STAT S: +OK 2 320 LIST [msg] 参数: 信息的序号(可选)，如果给定了这个参数，它不应该指向一条标记为已删 Myers & Rose Standards Track [Page 6] RFC 1939 POP3 May 1996 约束: 只能在TRANSACTION 状态中使用 讨论: 如果指定了参数，POP3服务器发送一条包含一行该message信息的确认响应。这一行被称为这个message的扫描清单。 如 果没指定任何参数，POP3服务器发送一个确定响应，然后给出一个多行响应。在最开始的+OK后面，对于maildrop中的每条消息，POP3服务器给 出一行包含该消息信息的响应。这些行也被称为扫描清单。如果maildrop中没有消息，POP3服务器不响应任何扫描清单–它发送一个确认响应+一行包 含字节中止符+一个CRLF对。 为了简化解析，所有的POP3服务器应该使用相同的格式生成扫描清单。扫描清单由消息号+单空格+字节数表示的消 息的精确大小组成。下面的消息格式化部分介绍了如何计算消息的精确大小。本备忘录不对消息大小后的附加内容做限定。最小的方案就是在那行响应后面加一个 CRLF对。高级的策略可能包含其他信息。 注意：本备忘录强烈反对在扫描清单中附加信息。另外，后面将讨论如何使客户端解析消息更加方便。 注意：标记为已删除的消息不会被列出来。 可能的响应: +OK scan listing follows -ERR no such message 例子: C: LIST S: +OK 2 messages (320 octets) S: 1 120 Myers & Rose Standards Track [Page 7] RFC 1939 POP3 May 1996 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 msg 参数: 消息序号(必须)，并且不能指向标记为已删除的消息 约束: 只能在TRANSACTION 状态下使用 讨论: 如果POP3服务器发送了确认响应，那么接下来就是一个多行响应。在最开始的+OK后，POP3服务器发送对应指定需要的消息，注意字节对齐的中止符（所有的多行响应都是这样）。 可能的响应: +OK message follows -ERR no such message 例子: C: RETR 1 S: +OK 120 octets S: S: . DELE msg 参数: 消息序号(必须)，并且不能指向标记为已删除的消息。 约束: 只能在TRANSACTION 状态下使用 Myers & Rose Standards Track [Page 8] RFC 1939 POP3 May 1996 讨论: POP3服务器把该消息标记为已删除。所有后续的对该消息的引用都将产生一个错误。POP3服务器并不真正的删除该消息直到POP3会话进入UPDATE状态。 可能的响应： +OK message deleted -ERR no such message 例子: C: DELE 1 S: +OK message 1 deleted … C: DELE 2 S: -ERR message 2 already deleted NOOP 参数: 无 约束: 只能在TRANSACTION 状态下使用 讨论: POP3服务器不做任何事情，只是回复一个确认信息。 可能的响应: +OK 例子: C: NOOP S: +OK RSET 参数: 无 限制: 只能在TRANSACTION 状态下使用 讨论: 如果某些消息被POP3服务器标记为已删除，它们将取消标记。然后POP3服务器发送一个确认响应。 Myers & Rose Standards Track [Page 9] RFC 1939 POP3 May 1996 可能的响应: +OK 例子: C: RSET S: +OK maildrop has 2 messages (320 octets) 6. UPDATE 状态 当客户端在TRANSACTION状态下发送了QUIT命令时，POP3会话进入UPDATE状态。(注意，如果客户端在 AUTHORIZATION 状态下发送QUIT命令，POP3服务器将直接中止，并不进入UPDATE状态。) 如果是客户端发送QUIT命令之外的原因而使会话中止，POP3会话将不进入UPDATE状态并且千万不能从maildrop中删除任何消息。 QUIT 参数: 无 约束: 无 讨论: POP3服务器从maildrop中删除所有标记为已删除的消息并响应该操作的结果。如果在删除消息时发生了错误，比如资源短缺，maildrop中的消息可能有几条或者0条标记为已删除的消息被删除。任何情况下服务器都不应该把未标记为已删除的消息删除。 不管删除是否成功，服务器都释放独占访问锁定并关闭TCP连接。 可能的响应: +OK -ERR some deleted messages not removed 例子: C: QUIT S: +OK dewey POP3 server signing off (maildrop empty) … C: QUIT Myers & Rose Standards Track [Page 10] RFC 1939 POP3 May 1996 S: +OK dewey POP3 server signing off (2 messages left) … 7. 可选的POP3命令 所有的POP服务器都应该支持上面描述的POP3命令。 下面描述的POP3可选命令使客户端拥有更多处理消息的自由。 注意：本备忘录强烈推荐支持这些命令。简而言之，本备忘录的中心思想就是把智能放在客户端而不是POP3服务器上。 TOP msg n 参数: 一个不能指向标记为已删除的消息号(必须)和一个非负的行号(必须) 限定: 只能在TRANSACTION 状态中使用 讨论: 如果POP3服务器发送了确认响应，那么响应就是多行的。在最开始的+OK后面，POP3服务器发送消息头，然后是一个空行把消息头跟消息体分割开，然后是指定行数的消息题。注意用于字节对齐的中止符。 注意，如果POP3客户端请求的行数大于消息体的总行数，那么POP3服务器将发送整个消息。 可能的响应: +OK top of message follows -ERR no such message 例子: C: TOP 1 10 S: +OK Myers & Rose Standards Track [Page 11] RFC 1939 POP3 May 1996 S: S: . … C: TOP 100 3 S: -ERR no such message UIDL [msg] 参数: 消息序号(可选)，如果指定了该参数，它不应该指向标记为已删除的消息 约束: 只能在TRANSACTION 状态下使用. 讨论: 如果指定了参数，POP3服务器发送一行包含指定消息信息的确认响应。这一行被称为该消息的唯一ID清单。 如果没有指定参数，POP3服务器将发送多行确认响应。在初始的+OK后面，对于maildrop中的每条消息，POP3服务器回应一行该消息的信息。 为了简化解析，所有的POP3服务器都应该使用的统一的格式打印唯一ID清单。唯一ID清单由消息号+单空格+消息的唯一ID组成。在唯一ID后无任何信息。 消 息的唯一ID是服务器决定的任意字符串，长度在1～70之间，字符在0×21~0×7E之内，该唯一ID用于唯一的标识maildrop中的消息和保持一 个会话。就算会话没有进入UPDATE状态就中止了，也需要持续下去。只要使用唯一ID的实体还存在，服务器就不能重新使用这个唯一ID。 注意标记为已删除的消息不在清单中。 服务器可以把这个任意的唯一ID存储起来，比如对消息计算hash值作为唯一ID。 Myers & Rose Standards Track [Page 12] RFC 1939 POP3 May 1996 客户端应该能处理这种情况：一个消息的两个同样的拷贝在mailbox中有相同的唯一ID 可能的响应: +OK unique-id listing follows -ERR no such message 例子: C: UIDL S: +OK S: 1 whqtswO00WBw418f9t5JxYwZ S: 2 QhdPYR:00WBw1Ph7×7 S: . … C: UIDL 2 S: +OK 2 QhdPYR:00WBw1Ph7×7 … C: UIDL 3 S: -ERR no such message, only 2 messages in maildrop USER name 参数: 标识邮箱的一个字符串(必须),它只对服务器有意义。 限制: 只能在AUTHORIZATION状态下POP3给出欢迎信息后或者使用USER或PASS命令没有成功时使用。 讨论: 在使用USER和PASS命令一起鉴别身份时，用户必须首先发送USER命令。如果POP3服务器响应了确认状态指示 (”+OK”),然后客户可以发送PASS命令完成确认或者QUIT命令中止会话。如果POP3服务器对USER命令响应了一个否定状态指示 (”+ERR”)，那么用户可以发送一个信息的鉴别命令或者发送QUIT命令。 尽管邮箱不存在，服务器也可能反馈一个确定信息。如果邮箱存在，但服务器不支持明文密码鉴别，则也可能反馈一个否定信息。 Myers & Rose Standards Track [Page 13] RFC 1939 POP3 May 1996 可能的响应: +OK name is a valid mailbox -ERR never heard of mailbox name 例子: C: USER frated S: -ERR sorry, no mailbox for frated here … C: USER mrose S: +OK mrose is a real hoopy frood PASS string 参数: 邮箱密码 (必须) 限制: 只能在AUTHORIZATION状态下紧跟在USER命令成功后使用 讨论: 当用户发送了PASS命令后，POP3服务器使用USER命令和PASS命令的参数对来决定这个用户是否应该授权访问适当的maildrop 因为PASS命令只有一个参数，POP3服务器应该可以识别密码中的空格，而不是当作参数分隔符。 可能的响应: +OK maildrop locked and ready -ERR invalid password -ERR unable to lock maildrop 例子: 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) Myers & Rose Standards Track [Page 14] RFC 1939 POP3 May 1996 APOP name digest 参数: 标识邮箱的字符串和MD5加密的字符串(都必须) 限定: 只能在AUTHORIZATION状态下POP3发送了问候语后或者在使用USER、PASS命令不成功后使用。 讨论: 一 般的，每个POP3会话都以一个USER/PASS交换开始。这将导致服务器/用户约定的密码被发送到互联网上。对于断断续续使用POP3，这可能不会引 起大的风险。但是多说的POP3用户经常连接POP3服务器–检查新邮件。更进一步的说，会话的间隔可能每5分钟一次，因此，密码被捕获的可能性是很高 的。 另外一个鉴定身份的方法是双方对原始鉴别信息重新建立保护，而不用把密码原文发送到互联网上。APOP命令提供了这个功能。 支持APOP命令的POP服务器会在它的欢迎信息上包换一个时间戳。时间戳的语法跟[RFC822]中描述的’msg-id’相似，并且要跟其他任何时间发送的问候语区分开。比如在UNIX上会使用独立的UNIX进程，语法可能像下面这样： 其中进程ID是进程的十进制PID，时钟是十进制系统时钟，主机名是POP3服务器运行的完整域名。 POP3用户记录下这个时间戳，然后发送APOP命令。参数’name’跟USER命令的参数’name’意义一样。参数’digest’是对时间戳+一个共享的秘密求MD5值。在[RFC1321]中介绍了MD5加密算法。这个共享的秘密只有服务器和用户知道。 Myers & Rose Standards Track [Page 15] RFC 1939 POP3 May 1996 参数’digest’本身是16进制值，它将以16进制小写ASCII字符格式发送 当POP3服务器接收到APOP命令，它校验接收到的digest。如果digest是对的，POP3服务器发送一个确认响应，POP3状态进入TRANSACTION状态。否则，发送否定响应，POP3状态停留在AUTHORIZATION状态。 注意，共享秘密长度越长，破解它的难度就越大。所以共享秘密应该是长字符串(像下面这样长于8个字符) 可能的回应: +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) 在本例子中，共享秘密是’tanstaaf’。因此对下面的字符串计算MD5 <1896.697170952@dbc.mtview.ca.us>tanstaaf 将得到 c4c9334bac560ecc979e58001b3e22fb 8. Scaling and Operational Considerations Since some of the optional features described above were added to the POP3 protocol, experience has accumulated in using them in large- scale commercial post office operations where most of the users are unrelated to each other. In these situations and others, users and vendors of POP3 clients have discovered that the combination of using the UIDL command and not issuing the DELE command can provide a weak version of the “maildrop as semi-permanent repository” functionality normally associated with IMAP. Of course the other capabilities of Myers & Rose Standards Track [Page 16] RFC 1939 POP3 May 1996 IMAP, such as polling an existing connection for newly arrived messages and supporting multiple folders on the server, are not present in POP3. When these facilities are used in this way by casual users, there has been a tendency for already-read messages to accumulate on the server without bound. This is clearly an undesirable behavior pattern from the standpoint of the server operator. This situation is aggravated by the fact that the limited capabilities of the POP3 do not permit efficient handling of maildrops which have hundreds or thousands of messages. Consequently, it is recommended that operators of large-scale multi- user servers, especially ones in which the user’s only access to the maildrop is via POP3, consider such options as: * Imposing a per-user maildrop storage quota or the like. A disadvantage to this option is that accumulation of messages may result in the user’s inability to receive new ones into the maildrop. Sites which choose this option should be sure to inform users of impending or current exhaustion of quota, perhaps by inserting an appropriate message into the user’s maildrop. * Enforce a site policy regarding mail retention on the server. Sites are free to establish local policy regarding the storage and retention of messages on the server, both read and unread. For example, a site might delete unread messages from the server after 60 days and delete read messages after 7 days. Such message deletions are outside the scope of the POP3 protocol and are not considered a protocol violation. Server operators enforcing message deletion policies should take care to make all users aware of the policies in force. Clients must not assume that a site policy will automate message deletions, and should continue to explicitly delete messages using the DELE command when appropriate. It should be noted that enforcing site message deletion policies may be confusing to the user community, since their POP3 client may contain configuration options to leave mail on the server which will not in fact be supported by the server. One special case of a site policy is that messages may only be downloaded once from the server, and are deleted after this has been accomplished. This could be implemented in POP3 server Myers & Rose Standards Track [Page 17] RFC 1939 POP3 May 1996 software by the following mechanism: “following a POP3 login by a client which was ended by a QUIT, delete all messages downloaded during the session with the RETR command”. It is important not to delete messages in the event of abnormal connection termination (ie, if no QUIT was received from the client) because the client may not have successfully received or stored the messages. Servers implementing a download-and-delete policy may also wish to disable or limit the optional TOP command, since it could be used as an alternate mechanism to download entire messages. 9. POP3 命令汇总 至少支持的 POP3 命令: USER name 在 AUTHORIZATION 状态下有效 PASS string QUIT STAT 在 TRANSACTION 状态下有效 LIST [msg] RETR msg DELE msg NOOP RSET QUIT 可选的 POP3 命令: APOP name digest 在AUTHORIZATION 状态下有效 TOP msg n 在TRANSACTION 状态下有效 UIDL [msg] POP3 响应: +OK -ERR Note that with the exception of the STAT, LIST, and UIDL commands, the reply given by the POP3 server to any command is significant only to “+OK” and “-ERR”. Any text occurring after this reply may be ignored by the client. Myers & Rose Standards Track [Page 18] RFC 1939 POP3 May 1996 10. POP3会话例子 S: C: 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: S: . C: DELE 1 S: +OK message 1 deleted C: RETR 2 S: +OK 200 octets S: S: . C: DELE 2 S: +OK message 2 deleted C: QUIT S: +OK dewey POP3 server signing off (maildrop empty) C: S: 11. 消息格式 在POP3会话中传输的所有消息都是在假定遵守Internet文本消息格式(在[RFC822]中描述)的基础上的。 需要注意的是服务器端计算的消息字节数可能和行尾指定的字节数不一致。一般情况下，在AUTHORIZATION状态期间，POP3服务器在打开 maildrop后可以计算每条消息的字节数。比如，如果POP3服务器内在的程序把行尾计算为一个字符，那么POP3服务器简单的把每个出现这个字符的 地方计算为两个字节。注意，消息中已字节结束符开始的行不应该被计算两次，因此当POP3客户端收到一个多行响应的时候它应该移除所有的用于字节对齐的中 止符。 Myers & Rose Standards Track [Page 19] RFC 1939 POP3 May 1996 12. References [RFC821] Postel, J., “Simple Mail Transfer Protocol”, STD 10, RFC 821, USC/Information Sciences Institute, August 1982. [RFC822] Crocker, D., “Standard for the Format of ARPA-Internet Text Messages”, STD 11, RFC 822, University of Delaware, August 1982. [RFC1321] Rivest, R., “The MD5 Message-Digest Algorithm”, RFC 1321, MIT Laboratory for Computer Science, April 1992. [RFC1730] Crispin, M., “Internet Message Access Protocol - Version 4″, RFC 1730, University of Washington, December 1994. [RFC1734] Myers, J., “POP3 AUTHentication command”, RFC 1734, Carnegie Mellon, December 1994. 13. Security Considerations It is conjectured that use of the APOP command provides origin identification and replay protection for a POP3 session. Accordingly, a POP3 server which implements both the PASS and APOP commands should not allow both methods of access for a given user; that is, for a given mailbox name, either the USER/PASS command sequence or the APOP command is allowed, but not both. Further, note that as the length of the shared secret increases, so does the difficulty of deriving it. Servers that answer -ERR to the USER command are giving potential attackers clues about which names are valid. Use of the PASS command sends passwords in the clear over the network. Use of the RETR and TOP commands sends mail in the clear over the network. Otherwise, security issues are not discussed in this memo. 14. Acknowledgements The POP family has a long and checkered history. Although primarily a minor revision to RFC 1460, POP3 is based on the ideas presented in RFCs 918, 937, and 1081. In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff provided significant comments on the APOP command. Myers & Rose Standards Track [Page 20] RFC 1939 POP3 May 1996 15. Authors’ Addresses 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 Myers & Rose Standards Track [Page 21] RFC 1939 POP3 May 1996 Appendix A. Differences from RFC 1725 This memo is a revision to RFC 1725, a Draft Standard. It makes the following changes from that document: - clarifies that command keywords are case insensitive. - specifies that servers must send “+OK” and “-ERR” in upper case. - specifies that the initial greeting is a positive response, instead of any string which should be a positive response. - clarifies behavior for unimplemented commands. - makes the USER and PASS commands optional. - clarified the set of possible responses to the USER command. - reverses the order of the examples in the USER and PASS commands, to reduce confusion. - clarifies that the PASS command may only be given immediately after a successful USER command. - clarified the persistence requirements of UIDs and added some implementation notes. - specifies a UID length limitation of one to 70 octets. - specifies a status indicator length limitation of 512 octets, including the CRLF. - clarifies that LIST with no arguments on an empty mailbox returns success. - adds a reference from the LIST command to the Message Format section - clarifies the behavior of QUIT upon failure - clarifies the security section to not imply the use of the USER command with the APOP command. - adds references to RFCs 1730 and 1734 - clarifies the method by which a UA may enter mail into the transport system. Myers & Rose Standards Track [Page 22] RFC 1939 POP3 May 1996 - clarifies that the second argument to the TOP command is a number of lines. - changes the suggestion in the Security Considerations section for a server to not accept both PASS and APOP for a given user from a “must” to a “should”. - adds a section on scaling and operational considerations Appendix B. Command Index 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 Myers & Rose Standards Track [Page 23]