发信本来很简单。TCP就是为了这个目的而设计的。但它只能完成机器级别的收发信,不能完成业务级别的收发信。因为收信方在发信方发信时不一定在线,所以必须引入缓冲机制。结果就是邮件服务器的产生。
说邮件的时候,一定要注意,说的是业务,用户级别的邮件。或者说我们大脑中的邮件。不是指邮件服务器要发的邮件。如果这么理解的话,有些概念会理不清楚。
象smtp.163.com与mail.qq.com这样的地址,只是寻址用的。用来寻找发信与收信的主机IP。既然有了寻址,有了缓冲,整个发信过程应该已经没有问题了。为什么还要引入MX记录呢?
因为收方可能有多台收信机器,或者就算是一台,也就是说,就算只有一个IP地址,它仍然存在一个发布的问题。
但是DNS本身已经是一个发布系统,它通过域名发布主机。只是这种发布,只能发布主机,同样地,不能完成业务级别的发布。也就是说,它不能完成邮件作为一种业务与其它所有业务的区别发布。单独设计MX的目的是为了将邮件发布从其它一切业务发布(其实DNS本来并不假设业务,只假设“DOMAIN”即域。至于“域”上面的业务,它并不区分)中独立出来。
从这个意义上讲,DNS是具有一定业务区别能力的发布系统。因为它至少区分了邮件业务与其它业务。
综上,今天的电子邮件核心系统,其实是由三部分组成的:
1,发与收信协议;
2,发与收信“服务器寻址”;
3,邮件“业务寻址”。
也就是说,有两个层次的寻址。一是找机器,一是找服务(指邮件服务)。
服务器寻址是为了完成核心系统与用户端的对接。业务寻址是为了完成在DNS系统中的业务发布(因为DNS本质上只是一个名称式发布系统,不能提供业务级别的语义)。
也就是说,MX记录是在DNS系统中提供邮件业务寻址的一个子系统。是DNS系统的业务化。
关于DNS系统到底要不要业务化,回答是否定的。论据则是今天如此众多的业务种类全部运行在原来那个简单的DNS系统中,并没有碰到任何问题。那么邮件业务是如何得到它的特殊性的呢?
因为它是一种域相关的业务。而域本身就是在DNS系统中定义的,所以最方便的发布域业务的地方及时机就变成了域系统。在这个阶段做业务发布的成本最低。在任何之后的阶段再去做这个事情,成本显然高昂很多。