加密报头S/MIME消息/rfc822 822

Question

我希望加密某些邮件头(Subject和Reply-To)，这些邮件是在加密邮件中发送的。我采取了整个MIME (包括头)，并成功地加密它。我可以成功地将这个S/MIME加密邮件发送给我的邮件客户端(雷鸟)。它将被成功解密并验证为签名。

但是，在内部加密的MIME中发送的任何标头都不会被我的邮件客户端使用。

根据RFC-5751，我应该用message/rfc822邮件包装我的邮件，但是我不知道如何实现这一点。

下面是我正在创建的消息的示例。

我的第一个问题是，我创建message/rfc822的最后一个MIME是否结构正确？这可能是邮件客户端的问题吗？我可以对Reply-To头进行事件加密吗？

如果我能得到一个mesage/rfc822封装消息的示例，这将是非常有帮助的。

邮件将被加密

这将成功地导致接收到的邮件被签名，邮件客户端将正确解释Subject / Reply-To标头。

Content-Type: multipart/signed; protocol="application/pkcs7-signature";
 micalg=sha256; boundary="--_NmP-d017e0e3556f7bbc-Part_1"
From: sender@domain.com
Sender: senderdomain.com
To: recipient@domain.com
Reply-To: keepsecret@domain.com
Subject: A Secret Subject
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
Date: Mon, 24 Feb 2020 15:59:19 +0000
MIME-Version: 1.0

----_NmP-d017e0e3556f7bbc-Part_1
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

My Message that will be encrypted

----_NmP-d017e0e3556f7bbc-Part_1
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s

MIIOCAYJKoZIhvcNAQcCoIIN+TCCDfUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
gguTMIIFCDCCA/CgAwIBAgIQVz2HAGYJcTJNsPiWLx1f/TANBgkqhkiG9w0BAQsFADCBjTELMAkG
.
.
.
17p13e02JxfyCqltdb6lkOdpRZ6ZlHHuQZyBCuRtJhRN83gvcJ4d7WCxKI349NEa2/tOb8ziFGat
gzvgu+o=
----_NmP-d017e0e3556f7bbc-Part_1--

我的加密邮件

此加密邮件将由我的邮件客户端接收并成功解密和验证(签名验证)。Reply-To和Subject仍然按预期工作，因为它们仍然是可见的。注意:来自未加密邮件的所有标头仍然存在于此邮件的加密正文中。

Sender: sender@domain.com
From: sender@domain.com
To: recipient@domain.com
Subject:  A Secret Subject
Reply-To: keepsecret@domain.com
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
 name=smime.p7m
Date: Mon, 24 Feb 2020 16:03:38 +0000
MIME-Version: 1.0

MIIYbwYJKoZIhvcNAQcDoIIYYDCCGFwCAQAxggG/MIIBuwIBADCBojCBjTELMAkG
.
.
.
O+EPVCh1fGDFwiFpDtY/z1Lv8g==

我的封装消息/rfc822 822

这条消息将被正确解密，但我的客户不承认这是一条加密的消息，也没有验证它是否已被签署(不用担心这一点)。解密后的邮件被解释为转发并附加为.eml文件。但是，没有找到Subject或Reply-To头(它们在加密的邮件中)。如果我按照RFC的建议添加虚拟值，这些虚拟值将由我的邮件客户端使用，而不是加密的。

Content-Type: message/rfc822; forwarded=false; boundary="--_NmP-07c15c542cedfe74-Part_1"
From: sender@domain.com
Sender: sender@domain.com
To: recipient@domain.com
Date: Mon, 24 Feb 2020 15:28:07 +0000
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
MIME-Version: 1.0

----_NmP-07c15c542cedfe74-Part_1
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
 name=smime.p7m

MIIYbwYJKoZIhvcNAQcDoIIYYDCCGFwCAQAxggG/MIIBuwIBADCBojCBjTELMAkG
.
.
.
fYU1LuhSBEyymSVRzwWr2T3lrhUe5BZBoY996epZtOPdIYrz2jqUglii1+AUBpUP
UUnpr8+cHTMk/50LHdy3MqMeYA==
----_NmP-07c15c542cedfe74-Part_1

编辑:添加RFC的摘录

在RFC-8551中，它声明如下：

In order to protect outer, non-content-related message header fields (for instance, the "Subject", "To", "From", and "Cc" fields), the
   sending client MAY wrap a full MIME message in a message/rfc822
   wrapper in order to apply S/MIME security services to these header
   fields.  It is up to the receiving client to decide how to present
   this "inner" header along with the unprotected "outer" header.  Given
   the security difference between headers, it is RECOMMENDED that the
   receiving client provide a distinction between header fields,
   depending on where they are located.

   When an S/MIME message is received, if the top-level protected MIME
   entity has a Content-Type of message/rfc822, it can be assumed that
   the intent was to provide header protection.  This entity SHOULD be
   presented as the top-level message, taking into account
   header-merging issues as previously discussed.

Answer 1

RFC 822提供了关于电子邮件的消息头是如何组成的，并且应该由它们通过的系统来处理的一般描述。RFC 5751 S/MIME 3.2 (顺便说一句，被它的继任者RFC 8551 S/MIME 4.0淘汰了)描述了如何使用这个标准来创建加密的电子邮件。

因此，您在“我的加密邮件”中描述的加密电子邮件的方法是有效和正确的。

但是，正如我在封装的message/ not 822中所描述的，您的方法并不完全正确。在如何应用rfc822包装器方面，您显然误解了RFC。包装器需要在您的消息被加密之前包围它，所以它将在加密的部分中。

在您的示例中，未加密的消息(稍微修改了要加密的版本Mail )必须如下所示：

MIME-Version: 1.0
Content-type: message/rfc822

From: sender@domain.com
Sender: senderdomain.com
To: recipient@domain.com
Reply-To: keepsecret@domain.com
Subject: A Secret Subject
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
Date: Mon, 24 Feb 2020 15:59:19 +0000
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="--_NmP-d017e0e3556f7bbc-Part_1"

----_NmP-d017e0e3556f7bbc-Part_1
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

My Message that will be encrypted
[...]

因此，您基本上是在消息加密/ add 822之前将其添加到消息中。

我已经能够验证这种方法，并在两个不同结果的接收邮件客户端中测试结果消息。对于macOS邮件应用程序，加密的主题不用于替换未受保护的“外部”主题，但至少显示在原始标头下面。这与RFC是一致的，因为RFC对介绍不太具体：

由接收客户端决定如何显示这个“内部”标头和不受保护的“外部”标头。鉴于标头之间的安全性差异，建议接收客户端根据标头字段所在的位置对标头字段进行区分。

加密的Reply-To头也会类似地显示，但在回复该电子邮件时它的电子邮件地址不受尊重。

客户支持

客户端对加密头的支持介于弱和不存在之间。一些测试的结果：

• 没有客户端支持用“内部”加密标头替换“外部”标头。
• Apple (macOS)在邮件中显着地显示内部标题
• 雷鸟将加密部分(包括其头部)显示为转发消息。
• Outlook不显示加密的部分，而是混乱地只显示带有附件(即加密消息)的空消息。

替代办法

在这个加密电子邮件的受保护标头草案 (正在进行中的工作)中提出了一种看起来很有希望的方法。其想法是将受保护的头作为多部分消息中的一个单独部分。此部分将由不可知的客户端内联地呈现，同时，支持客户端可以对其进行适当的处理。