加密标题S / MIME消息/ rfc822

Question

我正在尝试加密以加密邮件形式发送的某些邮件头（Subject和Reply-To）。我正在使用整个MIME（包括标头）并成功对其进行了加密。我可以将此S / MIME加密的邮件成功发送到我的邮件客户端（Thunderbird）。它将成功解密并验证为已签名。

但是，我的邮件客户端未使用在内部加密的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: [email protected]
Sender: senderdomain.com
To: [email protected]
Reply-To: [email protected]
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: [email protected]
From: [email protected]
To: [email protected]
Subject:  A Secret Subject
Reply-To: [email protected]
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

此消息将被正确解密，但是我的客户端无法识别它是加密消息，或者无法验证它是否已签名（不必担心太多）。解密后的邮件被解释为转发并附加为.eml文件。但是，找不到Subject或Reply-To标头（它们在加密的邮件中）。如果我按照RFC的建议添加伪值，则这些伪值将由我的邮件客户端使用，而不是加密的那些。

Content-Type: message/rfc822; forwarded=false; boundary="--_NmP-07c15c542cedfe74-Part_1"
From: [email protected]
Sender: [email protected]
To: [email protected]
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废弃）描述了如何使用该标准来创建加密电子邮件的详细信息。

因此，您按照我的加密邮件中所述对电子邮件进行加密的方法是正确的。

但是，您在我的封装的邮件/ rfc822]中描述的方法并不完全正确。对于如何应用rfc822包装器，您显然对RFC了误解。包装程序必须围绕您的消息之前，它必须经过加密，因此必须位于加密部分内。

在您的示例中，未加密的邮件（稍作修改的版本要加密的邮件

）必须看起来像这样：

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

From: [email protected]
Sender: senderdomain.com
To: [email protected]
Reply-To: [email protected]
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
[...]
因此，您基本上将message / rfc822添加到消息before

中，它已被加密。

我已经能够验证这种方法，并在具有不同结果的两个接收邮件客户端中测试了结果消息。对于macOS Mail应用程序，加密的主题并未用于替换不受保护的“外部”主题，但至少在原始标题下方突出显示了该主题。这符合RFC，RFC的表达方式不是很明确：

由接收客户端决定如何呈现此“内部”标头以及未受保护的“外部”标头。考虑到标头之间的安全性差异，建议接收客户端根据标头字段的位置对标头字段进行区分。

类似地显示一个加密的Reply-To标头，但是在回复该电子邮件时，它的电子邮件地址不被接受。

[使用Thunderbird，内部消息显示为eml附件，但至少内部主题显示为如此突出。但是，Reply-To地址根本没有显示。

老实说，我对通用邮件客户端至少在某种程度上完全支持加密的标头感到惊讶。