Postfix SASL身份验证

分享一下我老师大神的人工智能教程！零基础，通俗易懂！http://blog.csdn.net/jiangjunshow

也欢迎大家转载本篇文章。分享知识，造福人民，实现我们中华民族伟大复兴！

               

基本的smtp协议没有验证用户身份的能力。虽然信封上的寄件人地址已经隐含了发信者的身份，然而，
由于信封地址实在太容易假造，所以不能当成身份凭据。为了判断客户端是否有权使用转发服务（relay），服务器端必须确认客户端（寄件人）是否当真是对方所自称的那个人。在不能以寄件人地址为身份证书的前提下，smtp势必需要其他补充机制，才能验证客户端的身份。

从postfix的角度看，它需要扮演两种角色：当它身为smtp server时，需要能够验证用户个人的身份（让他们能使用smtp server寄出邮件）；当它身为smtp client时，它需要能够提供出自己的身份证书给其他mta检验（以便通过远程mta将邮件递送到最终目的地）。

大多数邮件系统只容许内部网络上的客户端使用转发服务，换言之，ip地址成了客户端身份的识别凭据。然而，并非所有合法用户都具有固定ip地址。比方说，带着笔记本电脑出差远方的同事，他们可能使用领近isp或饭店旅馆提供的临时性ip地址；或者，有些在家工作的用户，他们位于办公室之外的网络，但是需要透过办公室里的邮件系统来寄信。不管你是否能够事先知道用户的ip地址，sasl都能提供可靠的身份验证。

RFC 2554 “smtp service extension for authentication”制定了如何在基本smtp协议上增加验证功能的机制，此机制使得smtp能使用sasl协议来验证客户端身份。   

一、sasl概论
设定sasl时，你必须决定两件事；一是用于交换“标识信 息”（或称身份证书）的验证机制（authentication mechanism)；一是决定标识信息存储方法的验证架构(authentication framework)。SASL验证机制规范client与server之间的应答过程以及传输内容的编码法，sasl验证架构决定服务器本身如何存储客户端的身份证书以及如何核验客户端提供的密码。


1 选择适当的验证机制

Cyrus sasl支持多种验证机制，至于要使用哪一种验证机制，客户端与服务器双方必须事先取得共识。以下是一些比较常见的机制；

PLAIN
    PLAIN是最简单的机制，但同时也是最危险的机制，因为身份证书（登录名称与密码）是以base64字符串格式通过网络，没有任何加密保护措施。使用PLAIN机制时，最好结合TLS。

LOGIN
    LOGIN不是其正式支持的机制，但某些旧版的MUA使用这种机制，所以Cyrus SASL让你可选择其是否支持LOGIN机制。如果你的用户仍在使用这类老掉牙的MUA，你必须在编译SASL函数库时，指定要包含LOGIN的支持。LOGIN的证书交换过程类似PLAIN。

OPT
    OPT是一种使用“单次密码”的验证机制。此机制不提供任何加密保护，因为没必要————每个密码都只能使用一次，每次联机都要改用新密码。SMTP client必须能够产生OPT证书。

DIGEST-MD5
    使用这种机制时，client与server共享同一个隐性密码(seceret password)，而且此密码不通过网络传输。验证过程是从服务器先提出challenge（质询）开始,客户端使用此challenge与隐性密码计算出一个response（应答）。不同的challenge，不可能计算出相同的response；任何拥有secret password的一方，都可以用相同的challenge算出相同的response。因此，服务器只要比较客户端返回的response是否与自己算出的response相同，就可以知道客户端所拥有的密码是否正确。由于真正的密码并没有通过网络，所以不怕网络监测。

KERBEROS
    Kerberos是一种网络型验证协议。除非你的网络已经使用Kerberos，否则你应该用不到kerberos机制；相对的，如果你的网络已经架设了kerberos验证中心，