我对邮件的认识
本人目前参与了也个关于电子邮件系统的项目，在作这个邮件系统之前，我对邮件的认识十分肤浅，平时只是用作于朋友联系的一种手段，至于其发信机制则不太
清楚，只是会用，遇到有乱码邮件，也只是望信兴叹而已。通过这一个月的学习，使我对邮件系统有了一定的认识。不过
我知道现在的认识还是很肤浅的。下面谈谈我对邮件的认识：
一。邮件的发信机制(SMTP):
SMTP( Simple Mail Transfer Protocol),即简单邮件传输协议。SMTP是用来发送电子邮件的TCP/IP协议，
它是Internet上传输电子邮件的标准协议，用于提交和传送电子邮件，规定了主机之间传输电子邮件的标准交换格式和邮件在链路层上的传输机制。
SMTP通常用于把电子邮件从客户机传输到服务器，以及从某一服务器传输到另一个服务器。它的内容由IETF的RFC 821定义。
1.简介
简单邮件传输协议（SMTP）的目标是可靠高效地传送邮件，它独立于传送子系统而且仅要求一条可以保证传送数据单元顺序的通道。
SMTP的一个重要特点是它能够在传送中接力传送邮件，传送服务提供了进程间通信环境（IPCE），此环境可以包括一个网络，几个网络或一个网络的子网。理解到传送系统（或IPCE）不是一对一的是很重要的。进程可能直接和其它进程通过已知的IPCE通信。邮件是一个应用程序或进程间通信。邮件可以通过连接在不同IPCE上的进程跨网络进行邮件传送。更特别的是，邮件可以通过不同网络上的主机接力式传送。
2. SMTP模型
SMTP设计基于以下通信模型：针对用户的邮件请求，发送SMTP建立与接收SMTP之间建立一个双向传送通道。接收SMTP可以是最终接收者也可以是中间传送者。SMTP命令由发送SMTP发出，由接收SMTP接收，而应答则反方面传送。
一旦传送通道建立，SMTP发送者发送MAIL命令指明邮件发送者。如果SMTP接收者可以接收邮件则返回OK应答。SMTP发送者再发出RCPT命令确认邮件是否接收到。如果SMTP接收者接收，则返回OK应答；如果不能接收到，则发出拒绝接收应答（但不中止整个邮件操作），双方将如此重复多次。当接收者收到全部邮件后会接收到特别的序列，如果接收者成功处理了邮件，则返回OK应答。
SMTP提供传送邮件的机制，如果接收方与发送方连接在同一个传送服务下时，邮件可以直接由发送方主机传送到接收方主机；或者，当两者不在同一个传送服务下时，通过中继SMTP服务器传送。为了能够对SMTP服务器提供中继能力，它必须拥有最终目的主机地址和邮箱名称。
3.SMTP的工作流程。
SMTP（端口为25）的过程有一下几个过程有：（Mail）基本发送过程，向前传送邮件，确认邮箱名称和扩展邮件列表，发送到终端和打开关闭交换等。（详细内容可参看RFC821文档）。
4.SMTP的命令。
SMTP 的命令有：HELLO (HELO)，MAIL (MAIL)，RECIPIENT (RCPT)，DATA (DATA)，SEND (SEND)，
SEND OR MAIL (SOML)，SEND AND MAIL (SAML)，RESET (RSET)，VERIFY (VRFY)，EXPAND (EXPN)，HELP (HELP)，NOOP (NOOP)，QUIT (QUIT)等。（详细内容可参看RFC821文档）。
关于SMTP的详细内容，可参看RFC821文档。
二。邮件的收信机制（POP3):
POP3 (Post Office Protocol 3)，即邮局协议3，是最近的关于接收电子邮件的协议。它是Internet上传输电子邮件的第一个标准协议，也是一个离线协议。它提供信息存储功能，负责为用户保存收到的电子邮件，并且从邮件服务器上下载取回这些邮件。
POP3为客户机提供了发送信任状（用户名和口令），这样就可以规范对电子邮件的访问。在其中电子邮件由服务器接收并保存，在一定时间之后，用户（或者是客户电子邮件接收程序）检查邮箱并下传
邮件。遵循RFC1939协议。
1.使用POP3的必要性。
对于在网络上的比较小的结点，支持消息传输系统（MTS）是不实际的。例如，一台工作站可能不具有充足的资源允许SMTP服务器和相当的本地邮件传送系统保持序驻留，并持续运行。同样的，将一台个人计算机长时间连接在IP类型网络上的费用也是可观的（结点缺少的资源被称为"联络性"）。
虽然如此，在这样的小结点上允许管理邮件是十分有用的，并且这些结点经常支持一个用户代理来管理邮件。为解决这一问题，能够支持MTS的结点就为这些不能支持的结点提供了邮件存储功能。邮局协议-版本3就是使这样的工作站可以用一种比较实用的方法来访问存储于服务器上的储存邮件。通常，这意味着工作站可以从服务器上取得邮件，而服务器为它暂时保存邮件。
2.工作流程。
初始时，服务器通过侦听TCP端口110开始POP3服务。当客户主机需要使用服务时，它将与服务器主机建立TCP连接。当连接建立后，POP3发送确认消息。客户和POP3服务器相互（分别）交换命令和响应，这一过程一直要持续到连接终止。
在生命周期中，POP3会话有几个不同的状态。一旦TCP连接被打开，而且POP3服务器发送了确认信息，此过程就进入了"确认"状态。在此状态中，客户必须向POP3服务器确认自己是其的客户。一旦确认成功，服务器就获取与客户邮件相关的资源，此时这一过程进入了"操作"状态。在此状态中，客户提出服务，当客户发出QUIT命令时，此过程进入了"更新"状态。在此状态中，POP3服务器释放在"操作"状态中取得的资源，并发送消息，终止连接。
关于POP3的详细内容，看参看RFC1939文档。
三 邮件中的编码：
由于历史原因，E-mail只允许传送字符，而且是7位字符的E-mail网关时，毫无疑问地会出现问题。这些7位的E-mail网关把汉字内码第八位的1全变成了0，于是形成了一些不可读的文字，进形成了乱码。于是为了便于网络间的通讯，就需要对这些高8位的字符进行编码处理。因此，一个健全的邮件系统就要尽可能多的解出各种编码后的文件。目前比较流行的编码方式有：
1。BASE64编码： 原理是将三个连续的字符（共8*3=24位），平均分成四段，形成四个新的字符，如果最后不够24位，则补零填充。对编码为000000(二进制)的字符用“=“表示，
BASE64编码的判断较复杂，但它也有一个明显的特征，由于BASE64是通过“=”来实现对齐，因而假如你在一个排列非常规则（每行字符数相同，一般为63个），没有任何可识别内容的编码，且若最后一行未满并有一至三个“=”之类字符时即可确认它是BASE64编码；特别的一点是，“.”不属于BASE64编码后的字符，也就是说一个用BASE64正确编码后的字符，也就是说一个用BASE64下确编码后的信件将决不可能在信体部分有“.”出现，否则就是误码。
2.QUOTED-PRINTABLE编码：这种编码是将7FH以上的ASCII字符（即汉字）用它对应的文字串表达出来，即如一个ASCII编码为0ABH的字符，将用=AB来代表它。它的典型特征是文本中有大量的这种用“=”来构成的符号，即=XX=XX=XX等，只要有这种符号，即可确认。
以上的两种编码是最流行的两种。还存在的其他编码有：
3. UUENCODE编码：一些较老的邮件服务器上这种编码使用较多，目前的Ftp Mail等服务器也是使用此编码（如MrCool下载的文件等）。UUENCODE编码的主要特征是编码首行由BeginXXX开始，结束一行为End，且通常其中的每一行开始均为“M”，只要有了以上几个特征，就能确定是UUENCODE编码。
4. HZ编码：这是国外的中国人发明的一种编者按码方式，它把汉字的最高位去掉，然后用一特定符号来表明哪些编码经过了处理。这种编码也极易识别：在信的内容中通常会有这样的一组符号：“~{”和“}~”，其中的内容是不可读的（乱码），而在这一组分界符外的都是可读的英文字符。
5. Bit7码：这并非一种编码，而是网络传输误码。它是由于网络不支持8位传输引起的，通常在局域网的接入方案中较为常见。它跟HZ编码类似，只是没有标明哪些内容是截去了最高位的。识别办法跟随HZ类似，如果一段信件中英文部分是正常的话，即为此种误码。这种误码无法解码，只能要求对方用7位编码（如以上的各种编码）重新发送。
6.Bit8码：也就是带有高8为的编码，它对邮件服务器只是起到声明的作用。
四 邮件文件的格式：
RFC 822定义了用于电子邮件报文的格式。即RFC 822定义了SMTP、POP3、IMAP以及其它电子邮件传输协议所提交、传输的内容。RFC 822定义的邮件由两部分组成：信封和邮件内容。
信封包括与传输、投递邮件有关的信息。邮件内容包括标题和正文。
一般邮件文件大体上分为两个部分邮件头和邮件内容。邮件头和邮件内容之间有回车换行隔开。邮件头包含邮件的基本信息，邮件内容为邮件发送的正文内容和附件内容（如果有的话）；
邮件头包含的内容有：邮件来源（From)，发信日期(Date)，邮件主题(Subject)，邮件目的地址(To)，抄送邮件地址（CC),暗送邮件地址（BCC),邮件优先级（X-Priority），发信人的IP地址（X-Originating-IP），邮件服务器信息（X-Mailer）和回复地址（Return-path)等。当然这些内容有的并不是必须的。
原来的电子邮件系统只能发送文本格式的信息，随着科技的不断发展，对邮件要求发送其它格式格式的信息，于是MIME就应运而生了。
MIME全称Multipurpos e Internet Mail Extensions，即多功能Internet邮件扩展。
Internet上的SMTP传输机制是以7位二进制编码的ASCII码为基础的，适合传送文本邮件。而声音、图象、中文等使用8为二进制编码的电子邮件需要进行ASCII转换（编码）才能够在Internet上正确传输。
MIME增强了在RFC 822中定义的电子邮件报文的能力，允许传输二进制数据。MIME编码技术用于将数据从8位都使用的格式转换成数据使用7位的ASCII码格式。
关于邮件格式和MIME的详细内容可参看RFC822,RFC1521,RFC1522的文档。
五 邮件中的日期处理：
邮件中的日期遵循RFC822标准，标准格式为：
星期缩写，日期号 月份缩写 年（四位） 小时：分钟：秒 时区标志。
特别注意的是邮件日期中的时区标志，由于都在互联网上，大家在各个时区的事件表示有所不同，因此搜到信
的日期要转换到当前时区的日期和时间，在互联网上，大家一般都用CTS(世界标准时间）有称作GMT(格林尼治
时间）。
譬如当我们收到的日期时间为：Sat, 30 Mar 2002 13:27:08 -0800，我们当前所在的时区为正8区（北京时间），则发信时间用我们所在时区表示就是 Sat, 30 Mar 2002 29（13+16）:27:08 即Sun, 31 Mar 2002 6:27:08 +8000。
目前存在的时区有：
GMT 格林威治标准时间 GMT
UTC 全球标准时间 GMT
ECT 欧洲中部时间 GMT+1:00
EET 东欧时间 GMT+2:00
ART （阿拉伯）埃及标准时间 GMT+2:00
EAT 东非时间 GMT+3:00
MET 中东时间 GMT+3:30
NET 近东时间 GMT+4:00
PLT 巴基斯坦拉合尔时间 GMT+5:00
IST 印度标准时间 GMT+5:30
BST 孟加拉国标准时间 GMT+6:00
VST 越南标准时间 GMT+7:00
CTT 中国台湾时间 GMT+8:00
JST 日本标准时间 GMT+9:00
ACT 澳大利亚中部时间 GMT+9:30
AET 澳大利亚东部时间 GMT+10:00
SST 所罗门标准时间 GMT+11:00
NST 新西兰标准时间 GMT+12:00
MIT 中途岛时间 GMT-11:00
HST 夏威夷标准时间 GMT-10:00
AST 阿拉斯加标准时间 GMT-9:00
PST 太平洋标准时间 GMT-8:00
PNT 菲尼克斯标准时间 GMT-7:00
MST 西部山脉标准时间 GMT-7:00
CST 中部标准时间 GMT-6:00
EST 东部标准时间 GMT-5:00
IET 印第安那东部标准时间 GMT-5:00
PRT 波多黎各和美属维尔京群岛时间 GMT-4:00
CNT 加拿大纽芬兰时间 GMT-3:30
AGT 阿根廷标准时间 GMT-3:00
BET 巴西东部时间 GMT-3:00
CAT 中非时间 GMT-1:00
以上是我对邮件系统的一些认识，希望通过阅读该文章，能够使你对电子邮件有个新的认识。
