这个问题是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数字证书可以使用签名算法识别器，这样，发件人的电子邮件客户端软件就可以使用那个信息选择一种适当的算法。这就意味着安全关联能够在电子邮件发送和接收之前就可以建立。最后，请记住，在电子邮件交换过程中使用的加密功能还可以根据包括隐私协议、用户偏爱和法律限制等外部信息建立。
