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://mail.tyyunan.com/

pop3協議auth指令總結