這個問題是2006年2月28日提出來的:因為沒有使用S/MIME建立安全關聯，如果收件人不支持發件人使用的信息文摘算法會發生什么事情呢?

答:安全關聯式兩個或者兩個以上實體之間的關系，說明他們如何使用安全服務安全地通信。例如，一個安全關聯是在聯絡期間的SSL會話過程中建立起來的。當一個用戶希望建立一個SSL通信的時候，用戶要發送一個包含他希望使用的或者支持的加密系統的“客戶問候”消息。服務器也將使用“客戶問候”回答，并且也包含它支持的加密系統的信息。然后，這個客戶就負責選擇它將與服務器共享的加密系統以建立安全關聯。當你對電子郵件進行數字簽名的時候，你當然不知道收件人使用什么電子郵件客戶端軟件以及這個軟件支持的加密系統，因此，就不能建立安全關聯。正如你的問題暗示的那樣，這可能導致收件人的電子郵件客戶端軟件不支持創建這封郵件信息的算法或者散列值。

一般來說，當收到一封數字簽名的信息時，電子郵件客戶端軟件將計算自己的這個信息的散列值并且使用公共密鑰解密包含在郵件信息中的這個散列值，并且對比這兩個值。如果這兩個值相匹配，簽名信息的收件人就能夠保證這個信息沒有被篡改并且是由這個專用密鑰的擁有者簽署的。如果收件人的電子郵件客戶端軟件由于不支持發件人的算法而不能計算出這個報文摘要，收件人的電子郵件客戶端軟件就不能驗證發件人的身份或者這封電子郵件的完整性。

S/MIME協議解決了這個問題。大多數電子郵件客戶端軟件都支持的第三版S/MIME協議由幾個RFC組成。其中RFC 3370可識別S/MIME第三版軟件必須支持的算法。這些算法包括:安全散列算法-1(SHA-1)和計算散列值的報文摘要-5(MD5);數字簽名算法和用于簽名的RSA加密算法;RC2和用于報文加密的三次數據加密標準(3DES)。這將確保全部采用S/MIME協議的軟件達到基本兼容的水平。但是，電子郵件客戶端軟件如果正確識別出具體電子郵件使用的算法也可以增加額外的算法。實際上，報文摘要算法用于簽署一個報文，這個算法存儲在包含“SignerInfo digestAlgorithms”(簽名者報文摘要算法)字段的“SignedData”(簽名數據)值中。據這個RFC稱，如果一個電子郵件客戶端軟件不能夠識別或者支持這個算法，它必須通知用戶這個客戶端軟件不能正確地驗證這個郵件報文。

然而，如果發件人已經從以前的報文中獲得了收件人的公共密鑰和數字證書，X.509數字證書可以使用簽名算法識別器，這樣，發件人的電子郵件客戶端軟件就可以使用那個信息選擇一種適當的算法。這就意味著安全關聯能夠在電子郵件發送和接收之前就可以建立。***，請記住，在電子郵件交換過程中使用的加密功能還可以根據包括隱私協議、用戶偏愛和法律限制等外部信息建立。

【編輯推薦】

1. 信息安全防護 從保證電子郵件安全開始
2. 攜手打造安全網絡和電子郵件解決方案
3. 保證電子郵件安全的五個小竅門