|
|
|
|
@ -35,7 +35,7 @@ informative:
|
|
|
|
|
# RFC3501: # IMAP #
|
|
|
|
|
RFC4949: # Internet Security Glossary #
|
|
|
|
|
# RFC4880: # OpenPGP #
|
|
|
|
|
RFC5321: # SMTP #
|
|
|
|
|
# RFC5321: # SMTP #
|
|
|
|
|
# RFC5490:
|
|
|
|
|
RFC6376: # DKIM #
|
|
|
|
|
RFC6409:
|
|
|
|
|
@ -217,8 +217,8 @@ mechanism is to be determined by the IETF LAMPS WG.
|
|
|
|
|
(cf. {{inner-msg-hf}}). The Inner Message must be the same on the
|
|
|
|
|
sending and the receiving side.
|
|
|
|
|
|
|
|
|
|
* Outer Message (OuterM): The Message as handed over to the Transport
|
|
|
|
|
or received from the Transport respectively. The Outer Message
|
|
|
|
|
* Outer Message (OuterM): The Message as handed over to the Submission
|
|
|
|
|
Entity or received from the last hop respectively. The Outer Message
|
|
|
|
|
normally differs on the sending and the receiving side (e.g. new
|
|
|
|
|
Header Fields are added by intermediary nodes).
|
|
|
|
|
|
|
|
|
|
@ -226,20 +226,18 @@ mechanism is to be determined by the IETF LAMPS WG.
|
|
|
|
|
at the receiving side. Typically this is the same as the Inner
|
|
|
|
|
Message.
|
|
|
|
|
|
|
|
|
|
* * 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).
|
|
|
|
|
|
|
|
|
|
* Submission Entity: The entity taking care of further processing of
|
|
|
|
|
the Message (incl. transport towards the receiver), after protection
|
|
|
|
|
measures have been applied to. It typically determines the
|
|
|
|
|
destination recipients by reading the To, Cc and Bcc Header Fields
|
|
|
|
|
(of the Outer Message).
|
|
|
|
|
|
|
|
|
|
Note: The Submission Entity varies among implementations, mainly
|
|
|
|
|
depending on the stage, where protection measures are applied to: It
|
|
|
|
|
could be e.g. a Message Submission Agent (MSA) {{RFC6409}} or
|
|
|
|
|
another (proprietary) solution. The latter is particularly relevant,
|
|
|
|
|
if protection is implemented as a plugin solution or for mixnet
|
|
|
|
|
networks, i.e. "onion routing" for email (e.g. {{pEp.mixnet}}).
|
|
|
|
|
|
|
|
|
|
* Data Minimization: Data sparseness and hiding of all technically
|
|
|
|
|
concealable information whenever possible.
|
|
|
|
|
@ -295,33 +293,89 @@ PGP/MIME, etc.) used to achieve HP.
|
|
|
|
|
## Interactions {#interactions}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The following use cases assume that at least the sending side supports
|
|
|
|
|
Header Protection as specified in this document. Receiving sides that
|
|
|
|
|
support this specification are expected to be able to distinguish
|
|
|
|
|
between Messages that Header Protection -- as specified in this
|
|
|
|
|
document -- has been applied to and (legacy) Mail user Agents (MUAs)
|
|
|
|
|
not implementing this specification.
|
|
|
|
|
|
|
|
|
|
\[\[TODO: Verify once solution is stable and update last sentence \]\]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Main Use Case {#uc-ia-main-use-case}
|
|
|
|
|
|
|
|
|
|
Both peers (sending and receiving side) fully support Header
|
|
|
|
|
Protection as specified in this document or the receiving side is at
|
|
|
|
|
least compliant with the MIME specification {{RFC2045}}, ff.;
|
|
|
|
|
cf. {{main-use-case}}.
|
|
|
|
|
Both peers (sending and receiving side) (fully) support Header
|
|
|
|
|
Protection as specified in this document.
|
|
|
|
|
|
|
|
|
|
The main use case is specified in {{main-use-case}}.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Backward Compatibility
|
|
|
|
|
### Backward Compatibility Use Cases {#uc-ia-backward-compatibility-use-cases}
|
|
|
|
|
|
|
|
|
|
<!--
|
|
|
|
|
Alexey: why is the following text talking about not supporting MIME?
|
|
|
|
|
MIME was introduced almost 30 years ago!
|
|
|
|
|
Did you really mean "supports MIME, but doesn't support this specification"?
|
|
|
|
|
-->
|
|
|
|
|
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}}.
|
|
|
|
|
Regarding backwards compatibility the main distinction is based on
|
|
|
|
|
whether or not the receiving side conforms to MIME according to
|
|
|
|
|
{{RFC2046}}, ff., which in particular also includes Section 2 of
|
|
|
|
|
{{RFC2049}} on "MIME Conformance". In the following an excerpt of
|
|
|
|
|
paragraphs relevant in this context:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/fence-line.mkd}
|
|
|
|
|
|
|
|
|
|
A mail user agent that is MIME-conformant MUST:
|
|
|
|
|
|
|
|
|
|
[...]
|
|
|
|
|
|
|
|
|
|
-- Recognize and display at least the RFC822 message
|
|
|
|
|
encapsulation (message/rfc822) in such a way as to
|
|
|
|
|
preserve any recursive structure, that is, displaying
|
|
|
|
|
or offering to display the encapsulated data in
|
|
|
|
|
accordance with its media type.
|
|
|
|
|
|
|
|
|
|
-- Treat any unrecognized subtypes as if they were
|
|
|
|
|
"application/octet-stream".
|
|
|
|
|
|
|
|
|
|
[...]
|
|
|
|
|
|
|
|
|
|
A user agent that meets the above conditions is said to be MIME-
|
|
|
|
|
conformant. The meaning of this phrase is that it is assumed to be
|
|
|
|
|
"safe" to send virtually any kind of properly-marked data to users
|
|
|
|
|
of such mail systems, because such systems will at least be able to
|
|
|
|
|
treat the data as undifferentiated binary, and will not simply
|
|
|
|
|
splash it onto the screen of unsuspecting users.
|
|
|
|
|
|
|
|
|
|
{::include ../shared/fence-line.mkd}
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### Receiving Side MIME-Conformant {#uc-ia-bc-receiving-side-mime-conformant}
|
|
|
|
|
|
|
|
|
|
The sending side (fully) supports Header Protection as specified in
|
|
|
|
|
this document, while the receiving side does not support this
|
|
|
|
|
specification. The receiving side is MIME-conformant according to
|
|
|
|
|
{{RFC2045}}, ff. (cf. {{uc-ia-backward-compatibility-use-cases}}),
|
|
|
|
|
|
|
|
|
|
This use case is specified in {{receiving-side-mime-conformant}}.
|
|
|
|
|
|
|
|
|
|
Note: This case is expected to just work fine, if the sending side applies
|
|
|
|
|
specification for the main use case {{main-use-case}}.
|
|
|
|
|
|
|
|
|
|
\[\[TODO: Verify once solution is stable and update last sentence \]\]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### Receiving Side Not MIME-Conformant {#uc-ia-bc-receiving-side-not-mime-conformant}
|
|
|
|
|
|
|
|
|
|
The sending side (fully) supports Header Protection as specified in
|
|
|
|
|
this document, while the receiving side does not support this
|
|
|
|
|
specification. The receiving side is **not** MIME-conformant according
|
|
|
|
|
to {{RFC2045}}, ff. (cf. {{uc-ia-backward-compatibility-use-cases}})
|
|
|
|
|
either.
|
|
|
|
|
|
|
|
|
|
This use case is specified in {{receiving-side-not-mime-conformant}}.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Protection Levels {#protection-levels}
|
|
|
|
|
|
|
|
|
|
The following protection levels need to be considered:
|
|
|
|
|
@ -383,11 +437,19 @@ receiving side is needed.
|
|
|
|
|
|
|
|
|
|
## Main Use Case {#main-use-case}
|
|
|
|
|
|
|
|
|
|
This section applies to the Interaction (cf. {{interactions}}), where
|
|
|
|
|
all involved parties (sending and receiving side) implement this
|
|
|
|
|
specification or the receiving side is at least compliant with the
|
|
|
|
|
MIME specification {{RFC2045}}, ff. (For backward compatibility cases
|
|
|
|
|
cf. {{backward-compatibility-use-case}}).
|
|
|
|
|
This section applies to the main use case, where both peers (sending
|
|
|
|
|
and receiving side) (fully) support Header Protection as specified
|
|
|
|
|
herein (cf. {{uc-ia-main-use-case}}).
|
|
|
|
|
|
|
|
|
|
Note: The sending side specification of the main use case is also
|
|
|
|
|
applicable to the cases, where the sending side (fully) supports
|
|
|
|
|
Header Protection as specified herein, while the receiving side does
|
|
|
|
|
not support this specification, but is MIME-conformant according to
|
|
|
|
|
{{RFC2045}}, ff. (cf. {{uc-ia-backward-compatibility-use-cases}}) and
|
|
|
|
|
{{uc-ia-bc-receiving-side-mime-conformant}})
|
|
|
|
|
|
|
|
|
|
Further backward compatibility cases are defined in
|
|
|
|
|
{{backward-compatibility-use-cases}}.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### MIME Format {#mime-format}
|
|
|
|
|
@ -444,7 +506,7 @@ prepended by "W: " are the wrapper (MIME Header Section):
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
|
|
|
|
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
|
|
|
|
|
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
|
|
|
|
|
O: Subject: Meeting at my place
|
|
|
|
|
O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
|
|
|
|
|
O: To: somebody@example.net
|
|
|
|
|
@ -459,7 +521,7 @@ prepended by "W: " are the wrapper (MIME Header Section):
|
|
|
|
|
W:
|
|
|
|
|
I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
|
|
|
|
I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
|
|
|
|
|
I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
|
|
|
|
|
I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
|
|
|
|
|
I: MIME-Version: 1.0
|
|
|
|
|
I: MMHS-Primary-Precedence: 3
|
|
|
|
|
I: Subject: Meeting at my place
|
|
|
|
|
@ -513,6 +575,51 @@ Unlike the option described in {{option-smime-spec}}, this option does
|
|
|
|
|
not use a "message/RFC822" wrapper to unambiguously delimit the Inner
|
|
|
|
|
Message.
|
|
|
|
|
|
|
|
|
|
Before choosing this option, two issues must be assessed to ensure, no
|
|
|
|
|
interoperability issues result from it:
|
|
|
|
|
|
|
|
|
|
1. How current MIME parser implementations treat non-MIME Header
|
|
|
|
|
Fields, which are not part of the outermost MIME entity and not
|
|
|
|
|
part of a message wrapped into a MIME entity of media type
|
|
|
|
|
"message/rfc822", and how such messages are rendered to the user.
|
|
|
|
|
|
|
|
|
|
{{I-D.autocrypt-lamps-protected-headers}} provides some examples
|
|
|
|
|
for testing this.
|
|
|
|
|
|
|
|
|
|
2. MIME-conformance, i.e. whether or not this option is (fully)
|
|
|
|
|
MIME-conformant {{RFC2045}} ff., in particular also Section 5.1. of
|
|
|
|
|
{{RFC2046}} on "Multipart Media Type). In the following an excerpt
|
|
|
|
|
of paragraphs that may be relevant in this context:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/fence-line.mkd}
|
|
|
|
|
The only header fields that have defined meaning for body parts
|
|
|
|
|
are those the names of which begin with "Content-". All other
|
|
|
|
|
header fields may be ignored in body parts. Although they
|
|
|
|
|
should generally be retained if at all possible, they may be
|
|
|
|
|
discarded by gateways if necessary. Such other fields are
|
|
|
|
|
permitted to appear in body parts but must not be depended on.
|
|
|
|
|
"X-" fields may be created for experimental or private
|
|
|
|
|
purposes, with the recognition that the information they
|
|
|
|
|
contain may be lost at some gateways.
|
|
|
|
|
{::include ../shared/fence-line.mkd}
|
|
|
|
|
{::include ../shared/fence-line.mkd}
|
|
|
|
|
NOTE: The distinction between an RFC 822 message and a body
|
|
|
|
|
part is subtle, but important. A gateway between Internet and
|
|
|
|
|
X.400 mail, for example, must be able to tell the difference
|
|
|
|
|
between a body part that contains an image and a body part
|
|
|
|
|
that contains an encapsulated message, the body of which is a
|
|
|
|
|
JPEG image. In order to represent the latter, the body part
|
|
|
|
|
must have "Content-Type: message/rfc822", and its body (after
|
|
|
|
|
the blank line) must be the encapsulated message, with its own
|
|
|
|
|
"Content-Type: image/jpeg" header field. The use of similar
|
|
|
|
|
syntax facilitates the conversion of messages to body parts,
|
|
|
|
|
and vice versa, but the distinction between the two must be
|
|
|
|
|
understood by implementors. (For the special case in which
|
|
|
|
|
parts actually are messages, a "digest" subtype is also
|
|
|
|
|
defined.)
|
|
|
|
|
{::include ../shared/fence-line.mkd}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The MIME structure of an Email message looks as follows:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/fence-line.mkd}
|
|
|
|
|
@ -539,7 +646,7 @@ prepended by "O: " are the outer header section. Lines prepended by
|
|
|
|
|
{::include ../shared/fence-line.mkd}
|
|
|
|
|
|
|
|
|
|
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
|
|
|
|
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
|
|
|
|
|
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
|
|
|
|
|
O: Subject: Meeting at my place
|
|
|
|
|
O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
|
|
|
|
|
O: MIME-Version: 1.0
|
|
|
|
|
@ -551,7 +658,7 @@ prepended by "O: " are the outer header section. Lines prepended by
|
|
|
|
|
--.cbe16d2a-e1a3-4220-b821-38348fc97237
|
|
|
|
|
I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
|
|
|
|
I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
|
|
|
|
|
I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
|
|
|
|
|
I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
|
|
|
|
|
I: MIME-Version: 1.0
|
|
|
|
|
I: MMHS-Primary-Precedence: 3
|
|
|
|
|
I: Subject: Meeting at my place
|
|
|
|
|
@ -609,7 +716,7 @@ within any other protected part of the message:
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
type of the wrapper MUST be "message/RFC822" and MUST contain the
|
|
|
|
|
Content-Type header field parameter "forwarded=no" as defined in
|
|
|
|
|
{{I-D.melnikov-iana-reg-forwarded}}. The wrapper delimits unambiguously
|
|
|
|
|
the Inner Message from the rest of the message.
|
|
|
|
|
@ -642,18 +749,19 @@ The following Header Fields are defined as the Essential Header Fields:
|
|
|
|
|
|
|
|
|
|
* Subject
|
|
|
|
|
|
|
|
|
|
Some of these Header Fields are required by RFC 5322 (e.g. Message-ID).
|
|
|
|
|
Furthermore, not including certain Header
|
|
|
|
|
Further processing by the Submission Entity normally depends on part
|
|
|
|
|
of these Header Fields, e.g. From and Date HFs are required by
|
|
|
|
|
{{RFC5322}}. Furthermore, not including certain Header
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
though simply not adding those to the Outer Message Header Section
|
|
|
|
|
SHOULD be 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.
|
|
|
|
|
|
|
|
|
|
The MIME Header Section part is the collection of MIME Header Fields
|
|
|
|
|
describing the following MIME structure as defined in {{RFC2045}}.
|
|
|
|
|
@ -714,14 +822,10 @@ MAY be obfuscated. Those may be replaced by e.g.
|
|
|
|
|
|
|
|
|
|
* To: Obfuscated <anonymous@anonymous.invalid>
|
|
|
|
|
|
|
|
|
|
<!--
|
|
|
|
|
Alexey: transport don't need access to To/Cc header fields, as this
|
|
|
|
|
information is carried separate at SMTP level. (Antispam engines
|
|
|
|
|
might need to access these.)
|
|
|
|
|
So the following statement (as written) is false:
|
|
|
|
|
Such implementations need to ensure that the Transport has access to
|
|
|
|
|
these Header Fields in clear text and is capable of processing those.
|
|
|
|
|
-->
|
|
|
|
|
Such implementations may need to ensure that the Submission Entity has
|
|
|
|
|
access to the content of these Header Fields in clear text and is
|
|
|
|
|
capable of processing those. This is particularly relevant, if
|
|
|
|
|
proprietary Submission Entities are used.
|
|
|
|
|
|
|
|
|
|
A use case for obfuscation of all Outer Message Header Fields is
|
|
|
|
|
mixnet networks, i.e. "onion routing" for email (e.g. {{pEp.mixnet}}).
|
|
|
|
|
@ -778,10 +882,11 @@ from:
|
|
|
|
|
|
|
|
|
|
Legend:
|
|
|
|
|
|
|
|
|
|
* OuterM(S): Outer Message (OuterM) at sending side (before processing
|
|
|
|
|
by Transport)
|
|
|
|
|
* OuterM(S): Outer Message (OuterM) at sending side (before handing it
|
|
|
|
|
over to the Submission Entity)
|
|
|
|
|
|
|
|
|
|
* OuterM(R): Outer Message at receiving side (as received by Transport)
|
|
|
|
|
* OuterM(R): Outer Message at receiving side (as received by the last
|
|
|
|
|
hop, before decryption and/or signature verification is applied to)
|
|
|
|
|
|
|
|
|
|
* InnerM: Inner Message (that protection is applied to)
|
|
|
|
|
|
|
|
|
|
@ -816,7 +921,7 @@ Legend:
|
|
|
|
|
### Sending Side Message Processing {#sending-side-message-processing}
|
|
|
|
|
|
|
|
|
|
For a protected message the following steps are applied before a
|
|
|
|
|
message is handed over to the Transport:
|
|
|
|
|
message is handed over to the Submission Entity:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### Step 1: Decide on Protection Level and Information Disclosure {#sending-side-step-1}
|
|
|
|
|
@ -859,7 +964,7 @@ 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
|
|
|
|
|
Transport.
|
|
|
|
|
Submission Entity.
|
|
|
|
|
|
|
|
|
|
\[\[ TODO: Example \]\]
|
|
|
|
|
|
|
|
|
|
@ -885,23 +990,52 @@ typically involves rendering it for the user.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note: Further study is needed to determine whether or not the Outer
|
|
|
|
|
Message Header Section, as received from the Transport, is
|
|
|
|
|
Message Header Section, as received from the last hop, is
|
|
|
|
|
preserved for the user, and if so, how this is to be achieved.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Backward Compatibility Use Case {#backward-compatibility-use-case}
|
|
|
|
|
## Backward Compatibility Use Cases {#backward-compatibility-use-cases}
|
|
|
|
|
|
|
|
|
|
### Receiving Side MIME-Conformant {#receiving-side-mime-conformant}
|
|
|
|
|
|
|
|
|
|
This section applies to the case where the sending side (fully)
|
|
|
|
|
supports Header Protection as specified in this document, while the
|
|
|
|
|
receiving side does not support this specification, but is
|
|
|
|
|
MIME-conformant according to {{RFC2045}},
|
|
|
|
|
ff. (cf. {{uc-ia-backward-compatibility-use-cases}}) and
|
|
|
|
|
{{uc-ia-bc-receiving-side-mime-conformant}})
|
|
|
|
|
|
|
|
|
|
The sending side specification of the main use case
|
|
|
|
|
(cf. {#main-use-case}}) MUST ensure that receiving sides, that do not
|
|
|
|
|
support this specification, but are MIME-conformant according to
|
|
|
|
|
{{RFC2045}}, ff. can still recognize and display the Inner Message (or
|
|
|
|
|
rather the RUFM) in such a way as to preserve any recursive structure,
|
|
|
|
|
that is, displaying or offering to display the encapsulated data in
|
|
|
|
|
accordance with its media type (cf. {{RFC2049}}, Section 2).
|
|
|
|
|
|
|
|
|
|
\[\[TODO: Verify once solution is stable and update last sentence \]\]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Receiving Side Not MIME-Conformant {#receiving-side-not-mime-conformant}
|
|
|
|
|
|
|
|
|
|
This section applies to the case where the sending side (fully)
|
|
|
|
|
supports Header Protection as specified in this document, while the
|
|
|
|
|
receiving side neither supports this specification and
|
|
|
|
|
**nor** is MIME-conformant according to {{RFC2045}}, ff.
|
|
|
|
|
(cf. {{uc-ia-backward-compatibility-use-cases}) and
|
|
|
|
|
{{uc-ia-bc-receiving-side-not-mime-conformant}}).
|
|
|
|
|
|
|
|
|
|
{{I-D.autocrypt-lamps-protected-headers}} describes a possible way to
|
|
|
|
|
achieve backward compatibility with existing S/MIME (and PGP/MIME)
|
|
|
|
|
implementations that predate this specification (Legacy Display). It
|
|
|
|
|
mainly focuses on email clients that do not render emails using header
|
|
|
|
|
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".)
|
|
|
|
|
implementations that predate this specification and are not
|
|
|
|
|
MIME-conformant (Legacy Display) either. It mainly focuses on email clients
|
|
|
|
|
that do not render emails using header 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 be discovered, the Legacy Display format described in
|
|
|
|
|
@ -934,10 +1068,9 @@ This document requests no action from IANA.
|
|
|
|
|
|
|
|
|
|
The authors would like to thank the following people who have provided
|
|
|
|
|
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 Acknowledgments
|
|
|
|
|
-->
|
|
|
|
|
Luck, Daniel Kahn Gillmor, David Wilson, Hernani Marques, Krista
|
|
|
|
|
Bennett, Kelly Bristol, Robert Williams, Sofia Balicka, Steve Kille,
|
|
|
|
|
Volker Birk, and Wei Chuang.
|
|
|
|
|
|
|
|
|
|
--- back
|
|
|
|
|
|
|
|
|
|
@ -1001,12 +1134,9 @@ the message has to be cloned and adjusted depending on the recipient.
|
|
|
|
|
\[\[ RFC Editor: This section should be empty and is to be removed
|
|
|
|
|
before publication. \]\]
|
|
|
|
|
|
|
|
|
|
<!--
|
|
|
|
|
Alexey: it is compiant!
|
|
|
|
|
* Ensure "protected header" (Ex-Memory-Hole) option is (fully)
|
|
|
|
|
compliant with the MIME standard, in particular also {{RFC2046}},
|
|
|
|
|
Section 5.1. (Multipart Media Type) {{option-ex-memory-hole}}.
|
|
|
|
|
-->
|
|
|
|
|
compliant with the MIME standard, in particular also {{RFC2046}},
|
|
|
|
|
Section 5.1. (Multipart Media Type) {{option-ex-memory-hole}}.
|
|
|
|
|
|
|
|
|
|
* Decide on format of obfuscated HFs, in particular Date HF
|
|
|
|
|
({{obfuscation-outer-HF}})
|
|
|
|
|
@ -1019,9 +1149,6 @@ Section 5.1. (Multipart Media Type) {{option-ex-memory-hole}}.
|
|
|
|
|
* Should Outer Message Header Section (as received) be preserved for
|
|
|
|
|
the user? ({{receiving-side-step-2}})
|
|
|
|
|
|
|
|
|
|
* Do we need to take special care of HFs that may appear multiple
|
|
|
|
|
times, e.g. Received HF? ({{receiving-side-step-2}})
|
|
|
|
|
|
|
|
|
|
* Change adding Content-Type header field parameter "forwarded" from
|
|
|
|
|
SHOULD to MUST ({{wrapper}})?
|
|
|
|
|
|
|
|
|
|
@ -1037,6 +1164,15 @@ Section 5.1. (Multipart Media Type) {{option-ex-memory-hole}}.
|
|
|
|
|
* Decide on whether or not specification for more legacy HP
|
|
|
|
|
requirements should be added to this document
|
|
|
|
|
|
|
|
|
|
* Verify ability to distinguish between Messages with Header
|
|
|
|
|
Protection as specified in this document and legacy clients and
|
|
|
|
|
update {{interactions}} accordingly.
|
|
|
|
|
|
|
|
|
|
* Verify simple backward compatibility case (Receiving Side
|
|
|
|
|
MIME-Conformant) is working; once solution is stable and update
|
|
|
|
|
paragraphs in {#uc-ia-bc-receiving-side-mime-conformant}} and
|
|
|
|
|
{{receiving-side-mime-conformant}} accordingly.
|
|
|
|
|
|
|
|
|
|
* Improve definitions in {{protection-levels}}
|
|
|
|
|
|
|
|
|
|
* Privacy Considerations {{privacy-considerations}}
|
|
|
|
|
|
