`
AliKevin2011
  • 浏览: 118828 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

RFC1939-POP3

 
阅读更多
简介
  对于在网络上的比较小的结点,支持消息传输系统( MTS )是不实际的。例如,一台工作站可能不具有充足的资源允许 SMTP 服务器和相当的本地邮件传送系统保持序驻留,并持续运行。同样的,将一台个人计算机长时间连接在 IP 类型网络上的费用也是可观的(结点缺少的资源被称为 " 联络性 " )。
  虽然如此,在这样的小结点上允许管理邮件是十分有用的,并且这些结点经常支持一个用户代理来管理邮件。为解决这一问题,能够支持 MTS 的结点就为这些不能支持的结点提供了邮件存储功能。邮局协议 - 版本 3就是使这样的工作站可以用一种比较实用的方法来访问存储于服务器上的储存邮件。通常,这意味着工作站可以从服务器上取得邮件,而服务器为它暂时保存邮件。
  在下文中,客户主机指的是利用 POP3 服务的主机,而服务器主机指的是提供 POP3 服务的主机。
2. 简单说明
  在此文档中不指明客户主机如何将邮件送入到传送系统中去。但这里有一个说明:当用户代理需要将信息送到传送系统时,它在接力主机上建立 SMTP 连接(这些接力主机可以是 POP3 主机,也可以不是)。
3. 基本操作
  初始时,服务器通过侦听 TCP 端口 110 开始 POP3 服务。当客户主机需要使用服务时,它将与服务器主机建立 TCP 连接。当连接建立后, POP3 发送确认消息。客户和 POP3 服务器相互(分别)交换命令和响应,这一过程一直要持续到连接终止。
   POP3 命令由一个命令和一些参数组成。所有命令以一个 CRLF 对结束。命令和参数由可打印的 ASCII 字符组成,它们之间由空格间隔。命令一般是三到四个字母,每个参数却可达 40 个字符长。
   POP3 响应由一个状态码和一个可能跟有附加信息的命令组成。所有响应也是由 CRLF 对结束。现在有两种状态码, " 确定 " ("+OK") 和 " 失败 " ("-ERR") 。
  对于特定命令的响应是由许多字符组成的。在这些情况中,下面一一表述:在发送第一行响应和一个 CRLF之后,任何的附加信息行发送,他们也由 CRLF 对结束。当所有信息发送结束时,发送最后一行,包括一个结束字符(十进制码 46 ,也就是 "." )和一个 CRLF 对。如果信息中的任何一行以结束字符开始,此行就是通过在那一行预先装入结束而进行字符填充的。因此,多行响应由五个 CRLF.CRLF 结束。当检测多行响应时,客户检测以确认此行是否以结束字符开始。如果是的,而且其后的字符不是 CRLF ,此行的第一个字符(结束字符)将被抛弃;如果其后紧跟 CRLF ,从 POP 服务器来的响应终止,包括 .CRLF 的行也不被认为是多行响应的一部分了。
  在生命周期中, POP3 会话有几个不同的状态。一旦 TCP 连接被打开,而且 POP3 服务器发送了确认信息,此过程就进入了 " 确认 " 状态。在此状态中,客户必须向 POP3 服务器确认自己是其的客户。一旦确认成功,服务器就获取与客户邮件相关的资源,此时这一过程进入了 " 操作 " 状态。在此状态中,客户提出服务,当客户发出 QUIT 命令时,此过程进入了 " 更新 " 状态。在此状态中, POP3 服务器释放在 " 操作 " 状态中取得的资源,并发送消息,终止连接。
   POP3 服务器可以拥有一个自动退出登录的记时器。此记时器必须至少可以记录 10 分钟。这样从客户发送的消息才可能刷新此记时器。当记时器失效时, POP3 会话并不进入 " 更新 " 状态,而是关闭 TCP 连接,而且不删除任何消息,不向客户发送任何响应。
4. " 确认" 状态
  一时 TCP 连接由 POP3 客户打开, POP3 服务器发送一个单行的确认。这个消息可以是由 CRLF 结束的任何字符。例如,它可以是:
     S: +OK POP3 server ready
  注意:这个消息是一个 POP3 应答。 POP3 服务器应该给出一个 " 确定 " 响应作为确认。
  此时 POP3 会话就进入了 " 确认 " 状态。此时,客户必须向服务器证明它的身份。在文档中介绍两种可能的处理机制,一种是 USER 和 PASS 命令,另一种是在后面要介绍的 APOP 命令。
  用 USER 和 PASS 命令进行确认过程,客户必须首先发送 USER 命令,如果 POP3 服务器以 " 确认 " 状态码响应,客户就可以发送 PASS 命令以完成确认,或者发送 QUIT 命令终止 POP3 会话。如果 POP3 服务器返回" 失败 " 状态码,客户可以再发送确认命令,或者发送 QUIT 命令。
  当客户发送了 PASS 命令后,服务器根据 USER 和 PASS 命令的附加信息决定是否允许访问相应的存储邮件。
  一旦服务器通过这些数据决定允许客户访问储存邮件,服务器会在邮件上加上排它锁,以防止在进入 " 更新 "状态前对邮件的改变。如果成功获得了排它锁,服务器返回一个 " 确认 " 状态码。会话进入 " 操作状态 " ,同时没有任何邮件被标记为删除。如果邮件因为某种原因不能打开(例如,排它锁不能获得,客户不能访问相应的邮件或者邮件不能进行语法分析),服务器将返回 " 失败 " 状态码。在返回 " 失败 " 状态码后,服务器会关闭连接。如果服务器没有关闭连接,客户可以重新发送确认命令,重新开始,或者发送 QUIT 命令。
  在服务器打开邮件后,它为每个消息指定一个消息号,并以八进制表示每个消息的长度。第一个消息被指定为 1 ,第二个消息被指定为 2 ,以此类推,第 N 个消息被指定为 N 。在 POP3 命令和响应中,所以的消息号和长度以十进制表示。
  下面是对上述三条命令的总结:

 
 
5. " 操作" 状态
  一旦客户向服务器成功地确认了自己的身份,服务器将锁住并打开相应的邮件,这时 POP3 会话进入 " 操作" 状态。现在客户可以重复下面的 POP3 命令,对于每个命令服务器都会返回应答。最后,客户发送 QUIT 命令,会话进入 " 更新 " 状态。
下面是在 " 操作 " 状态中可用的命令:
6." 更新" 状态
  当客户在 " 操作 " 状态下发送 QUIT 命令后,会话进入 " 更新 " 状态。(注意:如果客户在 " 确认 " 状态下发送 QUIT 后,会话并不进入 " 更新 " 状态。)
  如果会话因为 QUIT 命令以外的原因中断,会话并不进入 " 更新 " 状态,也不从服务器中删除任何信件。
7. 可选的POP3 命令
  以上讨论的命令是对 POP3 服务的最小实现。以下说明的可选命令允许客户更方便地处理信件,这是一个比较一般的 POP3 服务实现。
  • TOP msg n
  【参数】一个是未被标记为删除的信件数,另一个是非负数(必须提供)
  【限制】仅在 " 操作 " 状态下使用。
  【说明】
  如果服务器返回 " 确认 " ,响应是多行的。在初始的 +OK 后,服务器发送信件头,一个空行将信件头和信件体分开,对于多行响应要注意字节填充终止符。
  注意:如果客户要求的行数比信件体中的行数大,服务器会发送整个信件。
  【响应】 +OK :其后有信件头;
   -ERR :其后无类似消息。
  【例子】
   C: TOP 1 10
   S: +OK
   S: < 服务器发送消息头,一个空行和信件的头 10 行 >
   S: .
   ...
   C: TOP 100 3
   S: -ERR no such message

  • UIDL [msg]
  【参数】信件数(可选)。如果给出信件数,不包括被标记为删除的信件。
  【限制】仅在 " 操作 " 状态下使用。
  【说明】
  如果给出了参数,且 POP3 服务器返回包括上述信息的 " 确认 " ,此行称为信息的 " 独立 -ID 表 " 。
  如果没有参数,服务器返回 " 确认 " 响应,此响应便以多行给出。在初的 +OK 后,对于每个信件,服务器均给出相应的响应。此行叫做信件的 " 独立 -ID 表 " 。
  为简化语法分析,所有服务器要求使用独立 -ID 表的特定格式。它包括空格和信件的独立 -ID 。
  信件的独立 -ID 由 0x21 到 0x7E 字符组成,这个符号在给定的存储邮件中不会重复。
  注意:信件不包括被标记为删除的信件。
  【响应】 +OK :其后是独立 -ID 表;
   -ERR :其后无类似信件。
  【例子】
   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

  • APOP name digest
  【参数】指定邮箱的字串和 MD5 摘要串。
  【限制】仅在 POP3 确认后的 " 确认 " 状态中使用。
  【说明】通常,每个 POP3 会话均以 USER/PASS 互换开始。这导致了用户名和口令在网络上的显式传送,这不会造成什么危险。但是,许多客户经常连接到服务检查信件。通常间隔时间比较短,这就加大了泄密的可能性。
另一种提供 " 确认 " 过程的方法是使用 APOP 命令。
  实现 APOP 命令的服务器包括一个标记确认的时间戳。例如:在 UNIX 上使用 APOP 命令的语法为:process-ID.clock@hostname ,其中进程 -ID 是进程的十进制的数,时钟是系统时钟的十进制表示,主机名与POP3 服务器名一致。
  客户记录下此时间戳,然后以送 APOP 命令。 name 语法和 USER 命令一致。 Digest 是采用 MD5 算法产生的包括时间戳和共享密钥的字串。此密钥是客户和服务器共知的,应该注意保护此密钥,如果泄密,任何人都能够以用户身份进入服务器。
  如果服务器接到 APOP 命令,它验证 digest ,如果正确,服务器返回 " 确认 " ,进入 " 操作 " 状态;否则,给出 " 失败 " 并停留在 " 确认 " 状态。
  注意:共享密钥的长度增加,解读它的难度也相应增加,这个密钥应该是长字符串。
  【响应】 +OK :邮件锁住并准备好;
   -ERR :拒绝请求。
  【例子】
   S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
   C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
   S: +OK maildrop has 1 message (369 octets)
  在此例子中,共享密钥 <1896.697170952@dbc.mtview.ca.us>tanstaaf 由 MD5 算法生成,它产生了 digest值, c4c9334bac560ecc979e58001b3e22fb
8. POP3 命令总结
基础的 POP3 命令:
USER name 在 " 确认 " 状态有效
PASS string
QUIT
 
STAT 在 " 操作 " 状态有效
LIST [msg]
RETR msg
DELE msg
NOOP
RSET
 
QUIT 在 " 更新 " 状态有效
 
可选的 POP3 命令:
APOP name digest 在 " 确认 " 状态有效
TOP msg n 在 " 操作 " 状态有效
UIDL [msg]
 
POP3 响应:
+OK
-ERR
 
注意:除了 STAT , LIST 和 UIDL 的响应外,其它命令的响应均为 "+OK" 和 "-ERR" 。响应后的所有文本将被客户略去。
9. POP3 会话实例
S: < 等待连接到 TCP 端口 110>
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: < 服务器发送信件 1>
S: .
C: DELE 1
S: +OK message 1 deleted
C: RETR 2
S: +OK 200 octets
S: < 服务器发送信件 2>
S: .
C: DELE 2
S: +OK message 2 deleted
C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty)
C: < 关闭连接 >
S: < 等待下一次连接 >
10. 消息格式
  在会话过程中的消息格式都假定与 Internet 文本消息格式标准一致。应该注意的是,由于各个服务器对于换行符的处理不同,因此计数不一定相同。通常,在 " 确认 " 状态中,服务器能够以八进制计算信件的大小。例如,如果在打开储存邮件时服务器内部认定换行符代表一个字符,一般服务器在计算它时作为两个字符计。注意,以终止符开始的消息行不被计数两次,因为客户将在接收到多行响应后删除所有字节填充。
11. 安全性考虑
  可以推测,使用 APOP 命令可以提供会话期间的保护。相应的,同时实现 PASS 和 APOP 命令的服务器只允许用户以一种方式访问;也就是说要么使用 USER/PASS 组合,要么使用 APOP 命令,不能同时使用两个。
而且,注意随着共享密钥长度的增加,解读的难度也就上升了。服务器要提供用户名时不给出任何响应,不给出任何暗示此用户名是否正确。而口令却在网络上显式传送;使用 RETR 和 TOP 命令在网络上显式传送信件。
12. 参考资料
   [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.

14. 致谢
   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.
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
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.

      - 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

组织: 中国互动出版网( http://www.china-pub.com/ )
RFC 文档中文翻译计划( http://www.china-pub.com/compters/emook/aboutemook.htm )
E-mail : ouyang@china-pub.com
译者: 顾国飞( ggfei  ggfei@263.net )
译文发布时间: 2001-4-10
版权: 本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。
分享到:
评论

相关推荐

    RFC1939-POP3.rar_RFC1939_pop3_rfc pop

    RFC1939是互联网工程任务组(IETF)制定的关于POP3的正式文档,定义了该协议的标准操作流程和命令集。在开发与邮件相关的应用程序,特别是涉及到邮件接收时,对RFC1939的理解至关重要。 POP3协议的核心功能是在...

    RFC1939-POP3协议中文版

    RFC1939-POP3协议中文版

    RFC1939-POP3协议

    《POP3协议》RFC1939 是互联网标准草案,主要描述了Post Office Protocol的第三版,即POP3,这是一个用于接收电子邮件的协议。该协议主要用于小型设备或资源有限的节点,比如个人计算机或工作站,这些设备无法长期...

    RFC1939(POP3)

    RFC1939是定义POP3第三版本的规范,它由J. Myers和M. Rose编写,旨在替代之前的RFC1725。尽管RFC1939不被视为互联网标准,但它在邮件服务领域被广泛采用。 ### 1. 简介 POP3协议的设计目的是允许用户通过远程...

    RFC1939.rar_RFC19_pop3 解析

    标题中的"RFC1939.rar"是一个包含有关POP3协议详细信息的压缩文件,而"RFC19_pop3 解析"则表明该文件着重于解释RFC19中关于POP3协议的部分。POP3(Post Office Protocol version 3)是一种广泛应用的邮件接收协议,...

    RFC中文文档全集【RFC1-3093】

    6. **电子邮件系统:** RFC822和RFC5322定义了电子邮件消息格式,RFC1939规定了POP3协议,RFC1035涉及DNS域名系统。 7. **互联网路由:** RFC1149探讨了用鸽子传输数据的互联网协议,而RFC1264和RFC1327则涉及了...

    RFC 1-3093 中文版

    6. **RFC 1939:Post Office Protocol - Version 3 (POP3)** - POP3协议使得用户可以从邮件服务器上接收电子邮件。 7. **RFC 2616:Hypertext Transfer Protocol -- HTTP/1.1** - 定义了HTTP 1.1协议,是Web浏览器...

    node-poplib:Node.js 的 POP3 客户端库

    它目前提供以下功能: 用户、通行证、APOP 列表、顶部、返回、删除UIDL、NOOP、CAPA RSET,退出纯文本和加密 TLS 支持STLS SASL PLAIN CRAM-MD5 它符合: RFC 1939 (POP3) RFC 2595 (STLS); RFC 5034(SASL 认证)...

    PDF版RFC:rfc1501-2000。(共12部分)

    - **RFC1939**:描述了POP3(邮局协议版本3),用于从邮件服务器接收电子邮件。 - **RFC1945**:HTTP/1.0的定义,互联网上最早的超文本传输协议标准。 - **RFC2045-2047**:涉及MIME(多用途互联网邮件扩展),...

    PDF版RFC:rfc3501-4000。(共12部分)

    3. **电子邮件协议**:在3501-4000这个范围内,有许多关于电子邮件处理和传输的RFC,如IMAP4rev1(RFC 3501)、POP3(Post Office Protocol version 3)的扩展(如RFC 2449)以及SMTP(Simple Mail Transfer ...

    RFC 0501-1000

    电子邮件的标准也在这一系列RFC中有所体现,比如SMTP(简单邮件传输协议)和POP3(邮局协议第三版)等。这些协议定义了邮件的发送、接收和存储方式,是现代电子邮件服务的基石。 **四、HTTP和FTP** HTTP(超文本...

    POP&SMTP 学习笔记

    POP&SMTP 学习笔记 MIME TYPE rfc1939--POP3 RFC2045( Mutipurpose Internet Mail Extensions(MIME) Part One telnet操作 smtp pop

    smtp.rar_c smtp_c++ 发邮件_smtp_smtp发邮件_发邮件 C/C++

    4. RFC 1939 - POP3 specification 以上内容涵盖了使用C++和C语言实现SMTP自动发送邮件的基本概念和实现方式,以及相关的邮件接收协议。在实际开发中,还需要结合具体的编程环境和需求进行调整和优化。

    中文版RFC文档1-3093

    - RFC 1939:POP3协议用于接收邮件,而RFC 2176(IMAP4)则允许用户在服务器上管理邮件。 5. **安全与加密** - RFC 1422-1425:PKIX(公钥基础设施)系列文档,为X.509证书提供了标准框架,用于验证网络身份。 -...

    RFC 5501-6000

    3. **电子邮件标准**:如SMTP(简单邮件传输协议)、IMAP(因特网消息访问协议)和POP3(邮局协议第3版),这些都是电子邮件系统的基石。 4. **安全性**:这部分可能包含SSL/TLS(安全套接层/传输层安全)协议的...

    RFC中文文档-txt

    RFC1939 邮局办公协议-版本3 RFC1942 HTML表格 RFC1945 超文本传输协议--HTTP/1.0 RFC1957 邮局协议(POP3)执行的一些观察 RFC1962 PPP压缩控制协议 (CCP) RFC1977 PPP BSD 压缩协议 RFC1979 PPP压缩协议 RFC1981 IP ...

    RFC1939.rar

    RFC1939是其中一个特定的文档,它详细阐述了POP3(邮局协议第3版,Post Office Protocol version 3)的使用和实现。 POP3是一种应用层协议,主要用于从邮件服务器接收电子邮件。在互联网的早期,当个人计算机的存储...

    RFC821-简单邮件传输协议(SMTP)中文版.rar_RFC821_rfc 中文_smtp_smtp协议

    在实际应用中,SMTP常与POP3(Post Office Protocol version 3)或IMAP4(Internet Message Access Protocol version 4)结合使用,前者用于从邮件服务器下载邮件,后者则提供了在线访问邮件的功能。随着电子邮件...

Global site tag (gtag.js) - Google Analytics