POP3

RFC 1939个定义的POP3是一个极为简单的邮件访问协议。正因为它过于简单，其功能也相当有限。POP3开始于用户代理(客户)打开一个到POP3服务器(服务器)端口号110的TCP连接。POP3服务器与邮件服务器运行在相同的服务器主机上，前者从用户的邮箱中读取并可能删除邮件消息，后者往用户的邮箱中写入邮件消息。TCP连接建立好之后，POP3依次经历授权队证、处理和更新3个阶段。在授权阶段，用户代理分别发出一个用户名和一个口令以认证下载邮件消息的用户。在处理阶段，用户代理获取邮件消息，并可以标记待删除的邮件消息或去掉这些标记，获取邮件统计信息。更新阶段发生在用户代理发出quit命令以结束当前POP3会话之后，期间POP3服务器删除己加过删除标记的邮件消息。

在POP3会话期间，用户代理发出命令，PoP3服务器则对每个命令响应以一个应答。可能的应答有两个:指出刚才的命令执行成功的+oK(有时后跟一个解释性消息)和指出刚才的命令执行有误的-ERR。

授权阶段共有两个基本命令:user <用户名>和pass<口令>。我们可以便用telnet工具指定使用POP端口号110直接登录到某台POP3服务器主机，并发出这些命令来展示它们的用法。假设mailserver是你的邮件服务器主机的名字，这个过程大体如下;

telnet mailserver 110

+OK POP3 server ready

user alice

+OK

pass password

+OK user successfully logged on

当然要是写错了某个命令，POP3服务器将返回一个-ERR应答。

下面查看一下处理阶段。使用POP3的用户代理可由用户配置成“下载并删除”或“下载并保留”两种模式之一。POP3用尸代理发出的一系列命令取决于自己运行在哪种模式。在下载井删除模式中，用户代理会发出list，retr和dele命令。作为例子，我们假设用户的邮箱中已存有两个邮件消息，共POP3处理阶段大体如下(其中前面标以“C:”的是用户代理发出的命令，前面标以“S:”的是POP3服务器返回的应答):

C:list

S:1 498

S:2 912

S:.

C:retr 1

S:(blab ......

S: ............

S: ......)

S:.

C:dele 1

C:retr 2

S:(... ...

S:...

S:......)

S:.

C:dele 2

C:quit

S:+OK POP3 server signing off

用户代理首先要求POP3服务器列出存放在自己的邮箱中的每个邮件消息的大小，接着依次取回并删除每个邮件消息。需注意的是，授权阶段结束之后，用户代理只能发出4个命令:list，retr，deie，quitt。这些命令的具体语法定义在RFC 1939中。处理完quit命令后，POP3服务器进入更新阶段，把邮件消息1和2从相应的邮箱中删除。

下载并删除模式存在一个问题，也就是收信人可能希望从不止一台主机访问自已的邮箱，如既能从办公室PC机访问.也能从家庭PC机访问，还能从使携机访问。下裁并删除模式将导致同一用户的邮件消息散布到他的多台主机上;例如，要是他先在家里的PC机上阅读了某个邮件消息，以后就没法在使携机上阅读同一个邮件消息了。下裁并保留模式则恰好相反，用户代理把己从POP3服务器下载的邮件消息继续保留在邮件服务器中。这种模式下，用户可以在不同的时间从不向的主机访问同样的邮件消息。

在用户代理和邮件服务器之间的POP3会话期间，POP3务器维护一定的状态信息:具体地说，它跟踪哪些邮件消息己被标记成待删除。不过POP3服务器不会跨会话保存状态信息。例如，每次会话开始之时没有任何邮件消息被标记成待删除。这种不跨会话保存状态信息的处理办法极大地简化了PoP3服务器软件的实现。

IMAP

收信人使用POP3把邮件消息下载到本地机之后，就可以把它们移入现行的或新创建的邮件夹中。他然后可以删除邮件消息，跨邮件夹转移邮件消息，按发信人名字或消息主题搜索邮件消息，等等。然而，这种邮件夹和邮件消息都存放在本地机上的模式对于游动用户却构成了问题。游动用户更愿意在远程邮件服务器主机上维护邮件夹，这样从任何主机都可以访问它。使用POP3是不可能做到达一点的。

RFC 2060中定义的IMAP协议正是为解决本问题和其他一些问题而发明的。IMAP提供的特性比POP3多出不少，不过也复杂得多，其客户端和服务器端的实现也相应地更为复杂。IMAP设计成允许用户象对待本地邮箱那样操纵远程邮箱。具体地说，IMAP使得收信人能够在自己的邮件服务器主机中创建并维护多个存放邮件消息的邮件夹。他们可以把邮件消息存入邮件夹，也可以从一个邮件夹到另一个邮件夹转移邮件，还可以在这些远程邮件夹中搜索匹配特定准则的邮件消息。IMAP的实现比POP3的实现复杂得多，原因之一就是IMAP服务器必须为每个用户维护一个邮件夹层次结构。某个用户相继访问自己的IMAP服务器时，这个IMAP服务器为该用户维护的状态信息跨这些相继的访问保持一致。POP3服务器则相反，一旦用户退出当前的POP3会话，它们就不再为他们维护状态信息。

IMAP的另一个重要特性是，它有一些允许用户代理获取邮件消息部件的命令。例如，用户代理可以只获取邮件消息的信头，或者只获取多部分MIME消息的某个部分。这个特性在用户代理和邮件服务器主机之间为低带宽连接(例如无线连接或低速调制解调器拨号连接)时非常有用。通过低带宽连接访问邮件时，用户很可能不希望下载自己的邮箱中的所有邮件消息，特别是可能含有音频或视频剪辑的长消息。

IMAP会话过程首先是用户代理(客户)发起建立…个到IMAP服务器(服务器)端口号143的TCP连接，然后是服务器返回初始问候消息，接着就是客户和服务器之间的交互了。客户和服务器的交互与POP3的类似，不过要丰富些，由客户发出的命令、服务器返回的数据或命令完成结果响应构成。IMAP服务器在会话期间总是处于以下4个状态之一:未认证(nonauthenticated)、已认证(authenticated)、已选择(selected)和注销(1ogout)。未认证状态是连接刚建立时的初始状合，这种状态下，用户必须提供一个用户名和口令对才能发出更多的命令。在已认证状态下，用户必须选择一个邮件夹才能发出作用于邮件消息的命令。在已选择状态下，用户可以发出作用于邮件消息的任何命令(获取、转移、删除、获取多部分消息的某个部分，等等)。最后的注销状态是会话即将终止时的状态。IMAP命令是按照每个状态下分别能够执行哪些命令来组织的。在IMAP的官方站点可以找到关十IMAP的所有内容。

HTTP邮件

今天，越来越多的用户转向使用基于浏览器的电子邮件服务，例如Hotmail和Yahoo!Mall。使用提供这种服务的服务器时，用户代理是普通的web浏览器，用户与存放在邮件服务器主机上的邮箱之间的交互相应地经由HTTP完成。当收信人(例如Bob)想要查看自己的邮箱中的邮件消息时，这些消息是通过HTTP协议(而不是POP3或IMAP协议)从邮件服务器主机传送到他的浏览器的。当发信人(例如Alice)想要发送电子邮件消息时，这些消息也是通过HTTP(而不是SMTP)从她的浏览器传送到她的邮件服务器主机的。不过邮件消息在邮件服务器主机之间的中转仍然通过SMTP。这种邮件访问办法对于游动用户来说极为方便。游动用户只要能使用浏览器，就能收发邮件消息，而浏览器可以在网吧、朋友家、装有Web Tv的旅馆等地方找到。与IMAP一样，用户可以在远程服务器主机中使用一个邮件夹层次结构组织邮件消息。基于Web的电子邮件既然如此方便，在未来几年内替换掉POP3或IMAP访问办法也是有可能的。它的主要不足之处在于速度比较慢，因为其服务器主机往往远离客户主机，而且用户的浏览器是通过CGl脚本与邮件服务器间接交互的。

持续媒体电子邮件

持续媒体(continuous-media，简称CM)电子邮件是包含音频或视频数据的电子邮件系统，它对于朋友之间和家庭成员之间的异步交流很有吸引力。例如，学龄前儿童更愿意使用CM电子邮件给祖父母发送邮件消息。CM电子邮件在公司也可能受欢迎，因为办公室工作人员录制CM邮件消息的速度要比输入文本消息的速度快许多(使用英语每分钟可以说180个单词，但是普通办公室工作人员每分钟只能输入20一40个单词)。CM电子邮件在某些方面类似电话语音留言，不过功能要强大得多。它不仅给用户提供一个访问邮箱的图形界面，而且允许用户评注并回复CM邮件消息，或者把CM邮件消息转发给多个收信人。

CM电子邮件与传统文本电子邮件在许多方面存在差异。CM电子邮件可能有大得多的邮件消息，对于端到端延迟有更严格的要求，对于收传人干差万别的因特网访问速率和本地存储容量也更为敏感。不幸的是，当前的电子邮件设施存在一些妨碍CM电于邮件推广的不足之处。首先，许多现有的邮件服务器没有存放大的邮件消息的容量;它们一般拒绝接收或中转CM邮件消息，因此不可能给依附它们的收传人发送这样的消息。其次，收信人的用户代理只在取得完整的邮件消息后才表达其内容，对于CM电子邮件，这会导致网络带宽和本地主机存储容量的过度浪费。事实上，仓储的CM邮件消息往往不是完整地表达的，因此接收未作表达的数据显然浪费了网络带宽和本地存储容量(例如，当某人收到来自相当唠叨的同事的长篇语音邮件消息后，可能只听上前15秒就决定不再听，要删除还剩20分钟内容的整个消息)。再次，当前使用的邮件访问协议(POP3，IMAP，HTTP)不适合为收信人流播放CM邮件消息。

具体地说，这些邮件访问协议没有提供这样的功能:允许用户暂停/恢复播放邮件消息内容，或者在邮件消息内重新定位播放点;另外，在TCP上实现流播放往往导致糟糕的接收效果。这些不足之处有望在未来的几年内得到解决。不过近来超大邮箱开始流行起来，如GMAIL等，邮箱容量的限制问题正在得到解决。