在使用Pop3协议时用到auth指令，现总结如下:
AUTH机制[初始响应]
机制：标识SASL认证机制的字符串
初始响应：可选的初始客户端响应，如在[RFC4422]的第3节中定义。如果存在， 这个回应必须编码为Base64（在第4节中指定）[RFC4648]），或者仅由单个字符 “=”组成，其中代表一个空初始响应。
限制：
AUTH命令成功完成后，不再需要 AUTH命令在同一会话中被发出。在一个成功的AUTH命令完成后，服务器必须拒绝接下来所有带有-ERR回复的AUTH命令。
AUTH命令只能在授权状态期间给出。
讨论：
AUTH命令启动客户端和服务器之间的SASL认证交换。客户端识别SASL机制与AUTH命令的第一个参数一起使用。如果服务器支持被请求认证机制，它执行SASL交换来验证用户。可选地，它还协商安全层后续的协议交互。如果请求的身份验证机制不受支持，即服务器用-ERR回复拒绝AUTH命令。
认证协议交换由一系列的服务器挑战和特定于选择SASL机制的客户端响应。
服务器质询作为由字符“+”组成的行发送，后跟单个空格和字符串编码
使用Base64，如[RFC4648]的第4节所述。这个行不得包含除BASE64编码的挑战以外的任何文本。
客户端响应由包含编码为Base64的字符串的行组成。如果客户希望取消
认证交换，它发出一行只有一个“*”的数据。如果服务器收到这样的响应，它必须通过发送一个-ERR回复拒绝这样的AUTH命令。
AUTH命令的可选初始响应参数是用于在使用认证机制时保存整个过程
来支持初始的客户端响应。如果初始响应参数被省略并且选择的机制需要
一个初始的客户端响应，服务器务必继续告知这是一个空的挑战，如[RFC4422]的第3部分所定义的。在POP3中，一个空的服务器挑战被定义为一行只有一个“+”，后跟一个空格。它不能包含任何内容的其他数据。
为了初始的客户端响应的目的，单个命令的长度限制为255个8位字节，在[RFC2449]的第4节中定义，并且仍然适用。如果指定了初始响应会导致AUTH命令超过这个长度，即客户端不得使用初始响应参数（并且必须在来自服务器的空挑战之后继续发送其初始响应，如[RFC4422]的第3部分）。
如果客户需要发送一个零长度的初始响应，它必须以单个等号（“=”）传送响应。这个表示响应存在，但不包含数据。
如果客户端使用AUTH命令的初始响应参数与不支持初始化的SASL机制客户端发送，服务器必须使用-ERR回复拒绝AUTH命令。
如果服务器不能Base64解码客户端响应，它必须用-ERR回复拒绝AUTH命令。如果客户不能Base64解码任何服务器的挑战，它必须使用“*”响应取消认证。特别注意的是，服务器和客户端必须拒绝（而不是忽略）任何不在Base64编码表明确允许的字符，并且必须拒绝任何除了字符串结尾之外再任何地方包含填充字符（‘=‘）的Base64字符序列（例如，“= AAA”和“AAA = BBB”是不允许的）。
除了初始的客户端响应，这些BASE64字符串可能是任意长度，根据使用的身份验证机制。客户端和服务器必须能够处理他们支持的认证机制产生的最大的编码挑战和响应。这个要求是独立于客户端或服务器的任何行长限制可能在其协议实施的其他部分。
如果服务器无法验证客户端，它必须用-ERR回复拒绝AUTH命令。如果客户成功完成交换，服务器发出一个+ OK回复。此外，成功后，POP3会话将进入TRANSACTION状态。
SASL交换机制生成的授权标识是一个简单的用户名，并应该使用StringPrep算法（参见[RFC3454]））的SASLprep配置文件（请参阅[RFC4013]）去准备这些名称进行匹配。如果准备好授权身份失败或空字符串的结果（除非它是作为空字符串传输的），服务器必须不通过该认证。
如果安全层在SASL交换期间协商，则它对紧跟在CRLF后的八位字节上的客户端生效，该CRLF结束了客户端的最后一次响应。对于服务器，它将成功答复CRLF后立即生效。
当安全层生效时，服务器必须丢弃任何以前从客户端那里获得的消息，不包括从SASL谈判本身获得的。同样，客户端必须丢弃从服务器获得的任何消息，如可用的POP3服务扩展列表。
当传输层安全性（TLS）（见[RFC4346]）和SASL安全层是有效的时候，在发送数据时TLS编码必须应用于SASL编码之后。（根据到[RFC2595]，STLS在任何情况下都只能在AUTH之前发布。）
请注意，POP3不允许指示成功结果的消息用来发送其他数据（见第3.6节）
[RFC4422]）。
由该协议的SASL配置文件指定的服务名称是“pop”。
如果AUTH命令失败，客户端可能会尝试另一个命令认证机制或通过提供不同的凭证发出另一个AUTH命令（或通过使用其他POP3之一认证机制）。同样，服务器必须表现出来
就好像客户端没有发出AUTH命令一样。
确保互操作性，此扩展的客户端和服务器实现必须实现在TLS [RFC2595]上运行的PLAIN SASL机制[RFC4616]。
服务器实现必须实现一个配置，这个机制不会通告或允许任何明文密码机制，除非STLS命令已用于协商TLS会话（参见[RFC2595]）。如RFC 4616所述，这个配置应该是默认配置。在TLS会话上使用明文密码机制之前，根据RFC 2595第2.4节要求客户端实现必须验证TLS服务器证书。客户端和服务器实现应该实现不会发送明文密码的附加SASL机制，例如GSSAPI
[RFC4752]机制。
目前市场中邮件加密产品，大多需要重新注册一个邮箱，或者重新部署一套邮件系统，导致原来的邮箱不能用，也就是说需要改变用户习惯，对于大型公司来说邮件系统升级比较困难。
选择对于用户透明的邮件加密产品是个不错的选择，比如天御云安推出的隐密邮在确保邮件内容加密的同时，部署对于用户也是透明的，可以说非常人性化。
原文地址：https://blog.51cto.com/14208524/2374364