|
|
@ -69,7 +69,7 @@ the S/MIME specification for header protection. |
|
|
|
# Introduction |
|
|
|
|
|
|
|
A range of protocols for the protection of electronic mail (email) |
|
|
|
exist, which allow to assess the authenticity and integrity of the |
|
|
|
exists, which allows to assess the authenticity and integrity of the |
|
|
|
email headers section or selected header fields (HF) from the |
|
|
|
domain-level perspective, specifically DomainKeys Identified Mail |
|
|
|
(DKIM) {{RFC6376}} and Sender Policy Framework (SPF) {{RFC7208}}, and |
|
|
@ -79,7 +79,7 @@ a range of attacks on email, do not offer (full) end-to-end protection |
|
|
|
to the header section and are not capable of providing privacy for the |
|
|
|
information contained therein. |
|
|
|
|
|
|
|
The need for means of Data Minimization, which includes data spareness |
|
|
|
The need for means of Data Minimization, which includes data sparseness |
|
|
|
and hiding all technically concealable information whenever possible, |
|
|
|
has grown in importance over the past several years. |
|
|
|
|
|
|
@ -99,9 +99,13 @@ Several varying implementations of end-to-end protections for email |
|
|
|
header sections exist, though the total number of such implementations |
|
|
|
appears to be rather low. |
|
|
|
|
|
|
|
Some LAMPS WG participants expressed the opinion that whatever |
|
|
|
mechanism will be chosen, it should not be limited to S/MIME, but |
|
|
|
also applicable to PGP/MIME. |
|
|
|
Some LAMPS WG participants expressed the opinion that regardless of |
|
|
|
the mechanism chosen, it should not be limited to S/MIME, but also |
|
|
|
applicable to PGP/MIME. |
|
|
|
|
|
|
|
<!-- Suggestion KRB: |
|
|
|
it should be applicable to both S/MIME and PGP/MIME. |
|
|
|
--> |
|
|
|
|
|
|
|
This document describes the problem statement ({{problem-statement}}), |
|
|
|
generic use cases ({{use-cases}}) and the specification for Header |
|
|
@ -113,15 +117,20 @@ requirements that this specification is based on. |
|
|
|
<!-- TODO: Decide whether to add the requirements to this document or |
|
|
|
leave them in a separate document --> |
|
|
|
|
|
|
|
This document is in early draft state and contains a proposal to base |
|
|
|
the upcoming discussions on. In any case, the final solution is to be |
|
|
|
determined by the IETF LAMPS WG. |
|
|
|
This document is in early draft state and contains a proposal on which |
|
|
|
to base future discussions of this topic. In any case, the final |
|
|
|
mechanism is to be determined by the IETF LAMPS WG. |
|
|
|
|
|
|
|
{::include ../shared/text-blocks/key-words-rfc2119.mkd} |
|
|
|
|
|
|
|
|
|
|
|
{::include ../shared/text-blocks/terms-intro.mkd} |
|
|
|
|
|
|
|
Note: To avoid ambiguity, this document does not use the terms |
|
|
|
"Header" or "Headers" in isolation, but instead always uses "Header |
|
|
|
Field" to refer to the individual field and "Header Section" to |
|
|
|
refer to the entire collection; cf. {{RFC5322}}. |
|
|
|
|
|
|
|
<!-- {::include ../shared/text-blocks/handshake.mkd} --> |
|
|
|
<!-- {::include ../shared/text-blocks/trustwords.mkd} --> |
|
|
|
<!-- {::include ../shared/text-blocks/tofu.mkd} --> |
|
|
@ -131,26 +140,10 @@ determined by the IETF LAMPS WG. |
|
|
|
|
|
|
|
* PGP/MIME: MIME Security with OpenPGP (cf. {{RFC3156}}) |
|
|
|
|
|
|
|
* Message: An Email Message consisting of header fields |
|
|
|
(collectively called "the Header Section of the message") followed, |
|
|
|
optionally, by a Body; cf. {{RFC5322}}. |
|
|
|
|
|
|
|
* Transport: The entity taking care of the transport of a Message |
|
|
|
towards the receiver or from the sender. The Transport on the |
|
|
|
sending side typically determines the destination recipients by |
|
|
|
reading the To, Cc and Bcc Header Fields (of the Outer |
|
|
|
Message). The Transport is typically implemented by an MTA (Mail |
|
|
|
Transfer Agent). |
|
|
|
|
|
|
|
* Header Field (HF): cf. {{RFC5322}} Header Fields are lines beginning |
|
|
|
with a field name, followed by a colon (":"), followed by a field |
|
|
|
body (value), and terminated by CRLF; cf. {{RFC5322}}. |
|
|
|
|
|
|
|
Note: To avoid ambiguity, this document does not use the terms |
|
|
|
"Header" or "Headers" in isolation, but instead always uses "Header |
|
|
|
Field" to refer to the individual field and "Header Section" to |
|
|
|
refer to the entire collection; cf. {{RFC5322}}. |
|
|
|
|
|
|
|
* Header Section (HS): The Header Section is a sequence of lines of |
|
|
|
characters with special syntax as defined in {{RFC5322}}. It is the |
|
|
|
(top) section of a message containing the Header Fields. |
|
|
@ -172,6 +165,27 @@ determined by the IETF LAMPS WG. |
|
|
|
MIME Header Fields of a Header Section that - in addition to MIME |
|
|
|
Header Fields - also contains non-MIME Header Fields. |
|
|
|
|
|
|
|
* Essential Header Fields (EHF): The minimum set of Header Fields an |
|
|
|
Outer Message Header Section SHOULD contain; cf. {{outer-msg-hf}}. |
|
|
|
|
|
|
|
* Message: An Email Message consisting of Header Hields |
|
|
|
(collectively called "the Header Section of the message") followed, |
|
|
|
optionally, by a Body; cf. {{RFC5322}}. |
|
|
|
|
|
|
|
* Transport: The entity taking care of the transport of a Message |
|
|
|
towards the receiver or from the sender. |
|
|
|
<!-- Feedback KRB: |
|
|
|
It's confusing to define transport as both an entity and process. I |
|
|
|
realize that's exactly what it is, but it reads awkwardly. Suggest |
|
|
|
"delivery", "transit", "transfer", or similar. The other uses of |
|
|
|
"transport" are okay, just this opening sentence needs help. |
|
|
|
--> |
|
|
|
The Transport on the |
|
|
|
sending side typically determines the destination recipients by |
|
|
|
reading the To, Cc and Bcc Header Fields (of the Outer |
|
|
|
Message). The Transport is typically implemented by an MTA (Mail |
|
|
|
Transfer Agent). |
|
|
|
|
|
|
|
* Header Protection (HP): cryptographic protection of email Header |
|
|
|
Sections (or parts of it) for signatures and/or encryption |
|
|
|
|
|
|
@ -209,9 +223,6 @@ determined by the IETF LAMPS WG. |
|
|
|
at the receiving side. Typically this is the same as the Inner |
|
|
|
Message. |
|
|
|
|
|
|
|
* Essential Header Fields (EHF): The minimum set of Header Fields an |
|
|
|
Outer Message Header Section SHOULD contain; cf. {{outer-msg-hf}}. |
|
|
|
|
|
|
|
* Protected: Protected refers to the parts of a message where |
|
|
|
protection measures of any Protection Level have been applied to. |
|
|
|
|
|
|
@ -224,7 +235,7 @@ determined by the IETF LAMPS WG. |
|
|
|
* Unprotected Message: A message that no protection measures of any |
|
|
|
Protection Levels have been applied to. |
|
|
|
|
|
|
|
* Data Minimization: Data spareness and hiding of all technically |
|
|
|
* Data Minimization: Data sparseness and hiding of all technically |
|
|
|
concealable information whenever possible. |
|
|
|
|
|
|
|
|
|
|
@ -247,7 +258,7 @@ In the following a set of challenges to be addressed: |
|
|
|
|
|
|
|
## Privacy {#privacy} |
|
|
|
|
|
|
|
* Data Minimization, which includes data spareness and hiding all |
|
|
|
* Data Minimization, which includes data sparseness and hiding all |
|
|
|
technically concealable information whenever possible |
|
|
|
|
|
|
|
|
|
|
@ -271,9 +282,8 @@ In the following a set of challenges to be addressed: |
|
|
|
|
|
|
|
In the following, the reader can find a list of the generic use cases |
|
|
|
that need to be addressed for messages with Header Protection |
|
|
|
(HP). These use cases apply independently of whether S/MIME, PGP/MIME |
|
|
|
or any other technology is used to achieve HP. |
|
|
|
|
|
|
|
(HP). These use cases apply regardless of technology (S/MIME, |
|
|
|
PGP/MIME, etc.) used to achieve HP. |
|
|
|
|
|
|
|
|
|
|
|
## Interactions {#interactions} |
|
|
@ -289,13 +299,13 @@ cf. {{main-use-case}}. |
|
|
|
|
|
|
|
### Backward Compatibility |
|
|
|
<!-- explain what is not correct --> |
|
|
|
The sending side fully supports Header protection as specified in this |
|
|
|
The sending side fully supports Header Protection as specified in this |
|
|
|
document, while the receiving side does not support the MIME |
|
|
|
specification {{RFC2045}}, ff. correctly; see |
|
|
|
{{backward-compatibility-use-case}}. |
|
|
|
|
|
|
|
|
|
|
|
Note: The compatibility of legacy HP systems with this new solutions, |
|
|
|
Note: The compatibility of legacy HP systems with this new solution, |
|
|
|
and how to handle issues surrounding future maintenance for these |
|
|
|
legacy systems, will be decided by the LAMPS WG. |
|
|
|
|
|
|
@ -331,7 +341,7 @@ c) Encryption only |
|
|
|
# Specification {#specification} |
|
|
|
|
|
|
|
This section contains the specification for Header Protection in |
|
|
|
S/MIME to update and clarifies Section 3.1 of {{RFC8551}} (S/MIME |
|
|
|
S/MIME to update and it clarifies Section 3.1 of {{RFC8551}} (S/MIME |
|
|
|
4.0). |
|
|
|
|
|
|
|
Furthermore, it is likely that PGP/MIME {{RFC3156}} will also incorprorate |
|
|
@ -488,13 +498,13 @@ to be considered, is described in |
|
|
|
{{I-D.autocrypt-lamps-protected-headers}}. |
|
|
|
|
|
|
|
Unlike the option described in {{option-smime-spec}}, this option does |
|
|
|
not use a "message/RFC822" wrapper to unambigously delimit the Inner |
|
|
|
not use a "message/RFC822" wrapper to unambiguously delimit the Inner |
|
|
|
Message. |
|
|
|
|
|
|
|
Note: More specific on Parsers (as there are two aspects here) |
|
|
|
|
|
|
|
Note: it is for further study, whether or not this option is (fully) |
|
|
|
compliant with the MIME standard, in particuar also {{RFC2046}}, |
|
|
|
compliant with the MIME standard, in particular also {{RFC2046}}, |
|
|
|
Section 5.1. (Multipart Media Type). |
|
|
|
<!-- |
|
|
|
Maybe remove (as suggested by Alexey) |
|
|
@ -515,9 +525,9 @@ The MIME structure of an Email message looks as follows: |
|
|
|
{::include ../shared/fence-line.mkd} |
|
|
|
|
|
|
|
|
|
|
|
The following example demonstrates how header section and payload of a |
|
|
|
protect body part might look like. For example, this will be the |
|
|
|
first body part of a multipart/signed message or the signed and/or |
|
|
|
The following example demonstrates how the header section and payload |
|
|
|
of a protected body part might appear. For example, this will be |
|
|
|
the first body part of a multipart/signed message or the signed and/or |
|
|
|
encrypted payload of the application/pkcs7-mime body part. Lines |
|
|
|
prepended by "O: " are the outer header section. Lines prepended by |
|
|
|
"I: " are the inner header section. |
|
|
@ -580,10 +590,10 @@ Message along with other MIME part(s). |
|
|
|
|
|
|
|
### Inner Message Header Fields {#inner-msg-hf} |
|
|
|
|
|
|
|
It is RECOMMEND that the Inner Messages contains all the Header Fields |
|
|
|
of the Original Message with the exception of the following Header |
|
|
|
Field, which MUST NOT be included to the Inner Message nor to any |
|
|
|
other protected part of the message: |
|
|
|
It is RECOMMENDED that the Inner Messages contains all the Header |
|
|
|
Fields of the Original Message with the exception of the following |
|
|
|
Header Field, which MUST NOT be included within the Inner Message nor |
|
|
|
within any other protected part of the message: |
|
|
|
|
|
|
|
* Bcc |
|
|
|
|
|
|
@ -598,7 +608,7 @@ The wrapper is a simple MIME Header Section followed by an empty line |
|
|
|
preceding the Inner Message (inside the Outer Message Body). The media |
|
|
|
type of the wrapper MUST be "message/RFC822" and SHOULD contain the |
|
|
|
Content-Type header field parameter "forwarded=no" as defined in |
|
|
|
{{I-D.melnikov-iana-reg-forwarded}}. The wrapper delimits unambigously |
|
|
|
{{I-D.melnikov-iana-reg-forwarded}}. The wrapper delimits unambiguously |
|
|
|
the Inner Message from the rest of the message. |
|
|
|
|
|
|
|
|
|
|
@ -615,11 +625,18 @@ per {{RFC8551}}. |
|
|
|
The following Header Fields are defined as the Essential Header Fields: |
|
|
|
|
|
|
|
* From |
|
|
|
* To (if present in the OrigM) |
|
|
|
* Cc (if present in the OrigM) |
|
|
|
* Bcc (if present in the OrigM, see also {{inner-msg-hf}} and {{bcc-handling}}) |
|
|
|
|
|
|
|
* To (if present in the Original Message) |
|
|
|
|
|
|
|
* Cc (if present in the Original Message) |
|
|
|
|
|
|
|
* Bcc (if present in the Original Message, see also {{inner-msg-hf}} |
|
|
|
and {{bcc-handling}}) |
|
|
|
|
|
|
|
* Date |
|
|
|
|
|
|
|
* Message-ID |
|
|
|
|
|
|
|
* Subject |
|
|
|
|
|
|
|
<!-- if not SMTP, it is not relevant to IETF. |
|
|
@ -629,14 +646,14 @@ verify 6409 is a good reference, split to RFC5322 and RFC6409 |
|
|
|
--> |
|
|
|
Some of these Header Fields are required by the submission service |
|
|
|
{{RFC6409}} (e.g. From, Date). Furthermore, not including certain Header |
|
|
|
Fields may trigger spam detection to flag the message as spam and/or |
|
|
|
Fields may trigger spam detection to flag the message and/or |
|
|
|
lead to user experience (UX) issues. |
|
|
|
|
|
|
|
For further Data Minimization the value of the Subject Header Field |
|
|
|
For further Data Minimization, the value of the Subject Header Field |
|
|
|
SHOULD be obfuscated. In addition, the value of other Essential Header |
|
|
|
Fields MAY be obfuscated. Further Header Fields MAY be obfuscated, |
|
|
|
though simply not adding those to the Outer Message Header SHOULD be |
|
|
|
prefered over obfuscation. Header Field obfuscation is further |
|
|
|
preferred over obfuscation. Header Field obfuscation is further |
|
|
|
specified in {{obfuscation-outer-HF}}. Header Fields not obfuscated |
|
|
|
should contain the same values as in the Original Message. |
|
|
|
|
|
|
@ -695,7 +712,7 @@ the same week. \]\] |
|
|
|
|
|
|
|
|
|
|
|
In certain implementations also the From, To, and/or Cc Header Field |
|
|
|
MAY be obfucated. Those may be replaced by e.g. |
|
|
|
MAY be obfuscated. Those may be replaced by e.g. |
|
|
|
|
|
|
|
* To: Obfuscated <anonymous@anonymous.invalid> |
|
|
|
|
|
|
@ -706,11 +723,15 @@ Such implementations need to ensure that the submission service has access to |
|
|
|
these Header Fields in clear text and is capable of processing those. |
|
|
|
|
|
|
|
A use case for obfuscation of all Outer Message Header Fields is |
|
|
|
mixnet netwerks, i.e. "onion routing" for email (e.g.{{pEp.mixnet}}). |
|
|
|
mixnet networks, i.e. "onion routing" for email (e.g.{{pEp.mixnet}}). |
|
|
|
|
|
|
|
Note: It is for further study to what extent Header Field obfuscation |
|
|
|
(adversely) impacts spam filtering. |
|
|
|
adversely impacts spam filtering. |
|
|
|
|
|
|
|
<!-- suggestion KRB: |
|
|
|
"Further studies of the impact that Header Field obfuscation has on |
|
|
|
spam filtering are needed." |
|
|
|
--> |
|
|
|
|
|
|
|
### Receiving User Facing Message Header Fields {#rufm-hf} |
|
|
|
|
|
|
@ -768,7 +789,7 @@ Legend: |
|
|
|
* More-HF: Additional Header Fields (HF) in the Original Message (OrigM) |
|
|
|
|
|
|
|
* Wrapper: MIME Header Section; with media type (message/RFC822) to |
|
|
|
unambigously delimit the inner message from the rest of the |
|
|
|
unambiguously delimit the inner message from the rest of the |
|
|
|
message. |
|
|
|
|
|
|
|
* MIME-HSp: MIME Header Section part to describe the encryption or |
|
|
@ -805,7 +826,7 @@ The entity applying protection to a message must decide: |
|
|
|
the message? This depends on user request and/or local policy as |
|
|
|
well as availability of cryptographic keys. |
|
|
|
|
|
|
|
* Which Header Fields of the Orignial Message shall be part of the |
|
|
|
* Which Header Fields of the Original Message shall be part of the |
|
|
|
Outer Message Header Section? This typically depends on local |
|
|
|
policy. By default the Essential Header Fields are part of the Outer |
|
|
|
Message Header Section; cf. {{outer-msg-hf}}. |
|
|
@ -831,9 +852,9 @@ part, which depends on the protection level selected in |
|
|
|
|
|
|
|
#### Step 3: Apply Protection to the Original Message {#sending-side-step-3} |
|
|
|
|
|
|
|
Depending on the Protection Level selected in {{sending-side-step-1}} |
|
|
|
apply signature and/or encryption to the Original Message including |
|
|
|
the wrapper (as per {{RFC8551}}) and set the result to the message as |
|
|
|
Depending on the Protection Level selected in {{sending-side-step-1}}, |
|
|
|
apply signature and/or encryption to the Original Message, including |
|
|
|
the wrapper (as per {{RFC8551}}), and set the result to the message as |
|
|
|
Outer Message Body. |
|
|
|
|
|
|
|
The resulting (Outer) Message is then typically handed over to the |
|
|
@ -844,12 +865,12 @@ Transport. |
|
|
|
|
|
|
|
### Receiving Side Message Processing |
|
|
|
|
|
|
|
When a protected message is received the following steps are applied: |
|
|
|
When a protected message is received, the following steps are applied: |
|
|
|
|
|
|
|
|
|
|
|
#### Step 1: Decrypt message and/or check signature {#receiving-side-step-1} |
|
|
|
|
|
|
|
Depending on the protection level the received message is decrypted |
|
|
|
Depending on the protection level, the received message is decrypted |
|
|
|
and/or its signature is checked as per {{RFC8551}}. |
|
|
|
|
|
|
|
|
|
|
@ -859,36 +880,36 @@ The Receiving User Facing Message is constructed according to |
|
|
|
{{rufm-hf}}. |
|
|
|
|
|
|
|
The resulting message is handed over for further processing, which |
|
|
|
typically involves rendering it to the user. |
|
|
|
typically involves rendering it for the user. |
|
|
|
|
|
|
|
|
|
|
|
Note: It is for further study whether and, if yes, how the Outer |
|
|
|
Message Header Section (as received from the Transport) is |
|
|
|
preserved for the user. |
|
|
|
Note: Further study is needed to determine whether or not the Outer |
|
|
|
Message Header Section, as received from the Transport, is |
|
|
|
preserved for the user, and if so, how this is to be achieved. |
|
|
|
|
|
|
|
|
|
|
|
## Backward Compatibility Use Case {#backward-compatibility-use-case} |
|
|
|
|
|
|
|
{{I-D.autocrypt-lamps-protected-headers}} describes a possibility to |
|
|
|
{{I-D.autocrypt-lamps-protected-headers}} describes a possible way to |
|
|
|
achieve backward compatibility with existing S/MIME (and PGP/MIME) |
|
|
|
implementations unaware of this specification (Legacy Display). It |
|
|
|
implementations that predate this specification (Legacy Display). It |
|
|
|
mainly focuses on email clients that do not render emails using header |
|
|
|
protection (nicely) and may confuse the user. While this has been |
|
|
|
observed occasionally in PGP/MIME (cf. {{RFC3156}}), the extent of |
|
|
|
this problem with S/MIME implementations is still unclear. (Note: At |
|
|
|
this time, none of the samples in |
|
|
|
{{I-D.autocrypt-lamps-protected-headers}} applies header protection as |
|
|
|
protection (in a user friendly manner) and may confuse the user. While |
|
|
|
this has been observed occasionally in PGP/MIME (cf. {{RFC3156}}), the |
|
|
|
extent of this problem with S/MIME implementations is still |
|
|
|
unclear. (Note: At this time, none of the samples in |
|
|
|
{{I-D.autocrypt-lamps-protected-headers}} apply header protection as |
|
|
|
specified in Section 3.1 of {{RFC8551}}, which is wrapping as Media |
|
|
|
Type "message/RFC822".) |
|
|
|
|
|
|
|
Should serious backward compatibility issues with rendering at the |
|
|
|
receiver reveal, the Legacy Display format described in |
|
|
|
receiver be discovered, the Legacy Display format described in |
|
|
|
{{I-D.autocrypt-lamps-protected-headers}} may serve as a basis to |
|
|
|
mitigate those (backward compatibility use case). |
|
|
|
mitigate those issues (cf. {{backward-compatibility-use-case}}). |
|
|
|
|
|
|
|
Another variant of backward compatibility has been implemented by pEp |
|
|
|
{{I-D.pep-email}}, i.e. pEp Email Format 1.0. At this time pEp |
|
|
|
has implemented this for PGP/MIME (but not yet S/MIME). |
|
|
|
has implemented this for PGP/MIME, but not yet S/MIME. |
|
|
|
|
|
|
|
|
|
|
|
# Security Considerations |
|
|
@ -911,10 +932,11 @@ This document requests no action from IANA. |
|
|
|
# Acknowledgments |
|
|
|
|
|
|
|
The authors would like to thank the following people who have provided |
|
|
|
helpful comments and suggestions for this document: Claudio Luck, |
|
|
|
David Wilson, Hernani Marques, Krista Bennett, Kelly Bristol, Robert |
|
|
|
Williams, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang. |
|
|
|
<!-- TODO: add DKG either to authors or to Acknowledgements --> |
|
|
|
helpful comments and suggestions for this document: Berna Alp, Claudio |
|
|
|
Luck, David Wilson, Hernani Marques, Krista Bennett, Kelly Bristol, |
|
|
|
Robert Williams, Sofia Balicka, Steve Kille, Volker Birk, and Wei |
|
|
|
Chuang. <!-- TODO: add DKG either to authors or to Acknowledgements |
|
|
|
--> |
|
|
|
|
|
|
|
--- back |
|
|
|
|
|
|
@ -939,26 +961,25 @@ header field may appear in up to three different variants: |
|
|
|
field, which depends on the implementation: |
|
|
|
|
|
|
|
a) One message for each recipient in the Bcc header field |
|
|
|
separately with a Bcc header field containing only the address |
|
|
|
of the recipient it is sent to |
|
|
|
separately, with a Bcc header field containing only the address |
|
|
|
of the recipient it is sent to. |
|
|
|
|
|
|
|
b) The same message for each recipient in the Bcc header field with |
|
|
|
a Bcc header field containing an indication such as "Undisclosed |
|
|
|
recipients" (but no addressees) |
|
|
|
recipients", but no addresses. |
|
|
|
|
|
|
|
c) The same message for each recipient in the Bcc header field |
|
|
|
which does not include a Bcc header field (this message is |
|
|
|
identical to 1. / cf. above) |
|
|
|
identical to 1. / cf. above). |
|
|
|
|
|
|
|
3. The message stored in the 'Sent'-Folder of the sender, which |
|
|
|
usually contains the Bcc unchanged from the original message, |
|
|
|
i.e. with all recipient addresses. |
|
|
|
i.e., with all recipient addresses. |
|
|
|
|
|
|
|
The most privacy preserving of the alternatives (2a, 2b, and 2c) |
|
|
|
is to standardize 2a, as in the other |
|
|
|
cases (2b and 2c) information about hidden recipients is revealed via |
|
|
|
keys. In any case the message has to be cloned and adjusted depending |
|
|
|
on the recipient. |
|
|
|
The most privacy preserving method of the alternatives (2a, 2b, and |
|
|
|
2c) is to standardize 2a, as in the other cases (2b and 2c), |
|
|
|
information about hidden recipients is revealed via keys. In any case, |
|
|
|
the message has to be cloned and adjusted depending on the recipient. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@ -980,7 +1001,7 @@ on the recipient. |
|
|
|
before publication. \]\] |
|
|
|
|
|
|
|
* Ensure "protected header" (Ex-Memory-Hole) option is (fully) |
|
|
|
compliant with the MIME standard, in particuar also {{RFC2046}}, |
|
|
|
compliant with the MIME standard, in particular also {{RFC2046}}, |
|
|
|
Section 5.1. (Multipart Media Type) {{option-ex-memory-hole}}. |
|
|
|
|
|
|
|
|
|
|
|