Я хочу зашифровать определенные почтовые заголовки (Subject и Reply-To), которые отправляются в зашифрованном письме. Я беру весь MIME (включая заголовки) и успешно его шифрую. Я могу успешно отправить это зашифрованное письмо S / MIME своему почтовому клиенту (Thunderbird). Он будет успешно расшифрован и подтвержден как подписанный.
Однако любые заголовки, которые отправляются во внутреннем зашифрованном MIME, не используются моим почтовым клиентом.
Согласно RFC-5751 я должен заключать свою почту в message/rfc822 сообщение, но я нахожусь в потеря в том, как этого добиться.
Ниже приведены примеры моих сообщений, которые я создаю.
Мой первый вопрос: правильно ли структурирован последний MIME, который я создаю message/rfc822? Возможно, это проблема с почтовым клиентом? Могу ли я зашифровать 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.
