电子邮件鉴权机制

本文主要是介绍电子邮件鉴权机制，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

邮件传输协议鉴权(SMTP Authentication)
      SMTP鉴权设计是由netscape公司的J. Meyers于1999年提出的，并最终发布到RFC2554("SMTP Service Extension for Authentication")，其中一部分是基于RFC 1869规范中的SMTP Service Extensions。大多数现有的SMTP实现都支持SMTP鉴权，尽管Qmail 1.03不支持(没有补丁),另一方面多数带有SMTP客户端功能的邮件用户代理(Mail User Agents or MUA)都具备鉴权功能。
      SMTP Authentication是由鉴权服务器发起通知，SMTP Authentication要求客户端被鉴权，且双方最终必须互相接受对方访问，且支持可选的鉴权流程。由于原始的SMTP协议设计初衷是主机对主机协议，SMTP Authentication机制下，用户必须标示自己并且在成功鉴权后给邮件收发方授权。
      除了用于子协议交互的可选安全层被提及外，RFC 2554没有明确说明对于一个用户而言鉴权有什么好处，
SMTP 鉴权采用一种简单的鉴权和安全协议层概念，但并没有加入到SMTP规范中，在本文中将简述该鉴权机制。

需求说明(Request for Comments)：
    *RFC 1869为SMTP协议对话定义了扩展协议(ESMTP)，用户说明被SMTP服务器扩展的能力同时或者由客户端传递额外的协议信息。支持ESMTP的smtp服务器必须在SMTP问候对话信息中使用关键字'EHLO',客户端可能仅仅使用服务器提供的这种扩展功能，通过构造对话消息，在一个SMTP对话中，服务器可以发送扩展信息（其作为ESMTP对话协议中的谓词(译者：是协议双方识别的关键字)或者作为'MAIL FROM: ' or 'RCPT TO: '命令的一部分），一个典型的用法是'MAIL FROM: <foobar@example.com> SIZE=1512'。这个例子中'SIZE'是一个扩展协议(ESMTP)关键字，'1512'是扩展协议(ESMTP)值,而整个术语'SIZE=1512'是扩展协议参数(RFC 1870 规范中，用于声明扩展协议下的消息字节数)，在RFC 1869利用两种不同的设计来改进ESMTP值的使用方式:
    1,作为ESMTP动词，使用方式如 "SIZE xxxxx"
    2,在命令'MAIL FROM: <foobar@example.com> SIZE=1512'中通过“关键字=值”方式

    * 在本文中，RFC 2554描述带有一个扩展协议关键字'AUTH'的SMTP鉴权,在传递的文本和RFC 2554的例子中，ESMTP Auth提到的值有'CRAM-MD5', 'DIGEST-MD5'和 'PLAIN'
    每个值对应一个鉴权方法或机制，但是却没有提供任何这方面的参考。

    * 在rfc 2222"Simple Authentication and Security Layer (SASL)" 中几乎找不到以上描述的ESMTP AUTH鉴权机制。在本文中(also published by John Myers)只概括了SASL机制，和如何注册一个新的SASL机制名称，但SASL的机制'KERBEROS_V4', 'GSSAPI', and 'SKEY'是定义了的。

    * 为保证成功，必须深入分析RFC 1731 "IMAP4 Authentication Mechanisms"和RFC 2195 "IMAP/POP Authorize Extension for Simple Challenge/Response",这里将个别给出基于POP3和IMAP4协议上的鉴权例子，这些文档均出自于John Myers，RFC 2060 "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"(John Myers)，说明了IMAP4 'LOGIN'命令的用法，但公众却不知道关于扩展邮件协议(ESMTP)的 'AUTH LOGIN'方法。

    * 基于base64字符编码对ESMTP Auth值进行编码/解码的方法是第一次在RFC 1113文件的"Privacy Enhancement for Internet Electronic Mail: Part I -- Message Encipherment and Authentication Procedures"中描述，尽管没有明确声明成BASE64.在文档RFC 2045的section 6.8中 "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"，给出了同样的base64字符描述.

    * 如果使用一种额外的挑战/相应鉴权机制(或者叫协商机制)，则你必须非常熟悉成为HMAC的流程，该流程出自于RFC 2104文档的"HMAC: Keyed-Hashing for Message Authentication"部分(一种带key的哈希鉴权算法),并另遵循RFC 1321文档中的"The MD5 Message-Digest Algorithm"消息摘要算法，HMAC简单的说就是一种加密/解密设计。

    * 直至今日仍没有一种公共的标准，即怎样在邮件的消息头中拓展smtp鉴权信息。不过在文档RFC3848中有种最小设计以避免SMTP鉴权会话，其中包括一个上次消息头中带有"Received:"的ESMTPA关键字.

从已知的情况来看似乎问题很清楚，即SMTP Authentication鉴权机制依赖于拼凑那些广泛分散在rfc文档中的机制、方法、流程。现在我们必须继续讨论SMTP的鉴权框架并将实现那些更复杂的事情.

鉴权框架
服务器通知，我们采用一个RFC 2554中的例子，"S:" 表示SMTP服务器，"C:"表示客户端

S: 220 smtp.example.com ESMTP server ready
C: EHLO jgm.example.com
S: 250-smtp.example.com
S: 250 AUTH CRAM-MD5 DIGEST-MD5
C: AUTH FOOBAR
S: 504 Unrecognized authentication type.
C: AUTH CRAM-MD5
S: 334
PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
S: 235 Authentication successful.

这里RFC 2554用多各关键字AUTH的值作为ESMTP命令，该方式遵循RFC 1869,我们将分解分析ESMTP的客户端实现,一个相关是在AUTH关键字和值之间手工增加一个"=" ,如：AUTH=LOGIN。

这里有三种鉴权机制被广泛的使用.来自Krzysztof Dabrowski的包qmail-smtp-auth-patch的文档中,有一个MUAs概览及其AUTH机制提供了如下几种鉴权方式:

    * AUTH_LOGIN
    * PLAIN
    * CRAM-MD5

1)AUTH LOGIN

最通用的'AUTH LOGIN'机制类似如下：
S: 220 esmtp.example.com ESMTP
C: ehlo client.example.com
S: 250-esmtp.example.com
S: 250-PIPELINING
S: 250-8BITMIME
S: 250-SIZE 255555555
S: 250 AUTH LOGIN PLAIN CRAM-MD5
C: auth login
S: 334 VXNlcm5hbWU6
C: avlsdkfj
S: 334 UGFzc3dvcmQ6
C: lkajsdfvlj
S: 535 authentication failed

从所有的提供的鉴权机制中，客户端选择了'auth login',ESMTP server于是发送了一串'334 VXNlcm5hbWU6'字符,该字符是基于base64编码对字符串'Username:'编码的，客户端提供一个base64编码的用户名称给服务器，服务器响应一个带有'Password:'字符串的消息'334 UGFzc3dvcmQ6'给客户端。在上面的例子中随机给定的用户名称和密码最后被服务器的鉴权请求给拒绝了。

2)AUTH PLAIN

按照IANA的文档,PLAIN鉴权机制定义在RFC 2245的"Anonymous SASL Mechanism"部分,而更好的PLAIN鉴权机制说明可以在文档RFC 2595 "Using TLS with IMAP, POP3 and ACAP" (第六章)中找到,内容:该机制由一个从客户到服务器的的消息组成，客户断发送一个鉴权标识(登陆标识)，其后是一个ASICC码NULL字符，再接一个鉴权标识(用户标识)后代ASICC码NULL字符,再接明文密码.客户端可以使鉴权标识为空,作为鉴权标记.简而言之，正确的AUTH PLAIN值的组织形式是:'authid/0userid/0passwd',其中'/0'标示空字节.
   一些AUTH PLAIN的SMTP扩展鉴权机制没有完全遵循流程，我们如下看到通过Netscape4.8 MUA连接到一个修改过的Qmail 1.03上来执行的PLAIN 鉴权流程

C: ehlo client.example.com
S: 220-esmtp.example.com
C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3RwYXNz
S: 235 ok, go ahead (#2.0.0)
C: RCPT TO:<....>

在这个例子中，用户名称是'test',用户密码是'testpass'.这里的Netscape客户端立即推送一个带有随意输入的鉴权标识'test'的鉴权信息到服务器端，而没有等待服务器告知其SMTP具备的鉴权机制.

3)AUTH CRAM-MD5
AUTH PLAIN 和LOGIN的鉴权方式都是传送明文的用户名称和密码，但重要信息还是需要更安全的CRAM-MD5鉴权机制来保证，我们已经提到CRAM-MD5合并了一个挑战/响应机制方式信息（用于和服务器交换信息）和一个被Digest5加密算法加密过的信息（Digest 5算法用于加密重要信息）,这里用到了一个Markus Stumpf (SpaceNet)发布的一个例子,是一个典型的ESMTP AUTH CRAM-MD5鉴权对话，如下:

S: 220 popmail.space.net ESMTP
C: ehlo client.example.com
S: 250-popmail.space.net
S: 250-PIPELINING
S: 250-8BITMIME
S: 250-SIZE 0
S: 250 AUTH CRAM-MD5
C: auth cram-md5
S: 334 PDI0NjA5LjEwNDc5MTQwNDZAcG9wbWFpbC5TcGFjZS5OZXQ+

与AUTH LOGIN鉴权机制不同，服务器的响应现在是一次性的BASE64编码的'挑战机制',这个挑战信息'PDI0NjA5LjEwNDc5MTQwNDZAcG9wbWFpbC5TcGFjZS5OZXQ+'翻译成'<24609.1047914046@popmail.Space.Net>'.字符串中头和尾的尖括号('<', '>')是强制性的,也是挑战机制的一部分，其中提供了在字符@后的主机名称,'24609.1047914046'是一个随机字符串，典型的是'pid'号，进程号和挡墙的时间戳来创建挑战消息的唯一性.

在用户名称以base64明文形式被传输后，服务器的挑战号也被客户端用于生成digest，digest来自于挑战号和密码(密码通常在上下文中被称为秘密或者共享秘密),digest摘要信息是基于MD5的哈希算法得到，如下：
digest = MD5(('secret' XOR opad), MD5(('secret' XOR ipad), challenge))

如果ESMTP的服务和客户端‘共享’了相同的挑战号和密码，则用户现在可以传输BASE64编码的'user name'和'digest'的方式成功通过服务器的鉴权.