4.1. Main Use Case
This section applies to the main use case, where the sending and receiving side (fully) support Header Protection as specified herein (cf. Section 3.1.1).¶
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, but is MIME-conformant according to [RFC2045], ff. (cf. Section 3.1.2 and Section 3.1.2.1).¶
Further backward compatibility cases are defined in Section 4.2.¶
4.1.1. MIME Format
4.1.1.1. Introduction
As per S/MIME version 3.1 and later (cf. [RFC8551]), 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.¶
To help the receiving side to distinguish between a forwarded and a wrapped message, the Content-Type header field parameter "forwarded" is added as defined in [I-D.melnikov-iana-reg-forwarded].¶
The simplified (cryptographic overhead not shown) MIME structure of such an Email Message looks as follows:¶
<Outer Message Header Section (unprotected)>
<Outer Message Body (protected)>
<MIME Header Section (wrapper)>
<Inner Message Header Section>
<Inner Message Body>
¶
The following example demonstrates how an Original Message might be protected, i.e., the Original Message is contained as Inner Message in the Protected Body of an Outer Message. It illustrates the first Body part (of the Outer Message) as a "multipart/signed" (application/pkcs7-signature) media type:¶
Lines are prepended as follows:¶
- "O: " Outer Message Header Section¶
- "I: " Message Header Section¶
- "W: " 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@m.example.net>
O: Subject: Meeting at my place
O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
O: To: somebody@example.net
O: MIME-Version: 1.0
O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
O: protocol="application/pkcs7-signature";
O: boundary=boundary-AM
This is a multipart message in MIME format.
--boundary-AM
W: Content-Type: message/RFC822; forwarded=no
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@m.example.net>
I: MIME-Version: 1.0
I: MMHS-Primary-Precedence: 3
I: Subject: Meeting at my place
I: To: somebody@example.net
I: X-Mailer: Isode Harrier Web Server
I: Content-Type: text/plain; charset=us-ascii
This is an important message that I don't want to be modified.
--boundary-AM
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature
[[base-64 encoded signature]]
--boundary-AM--
¶
The Outer Message Header Section is unprotected, while the remainder (Outer Message Body) is protected. The Outer Message Body consists of the wrapper (MIME Header Section) and the Inner Message (Header Section and Body).¶
The wrapper is a simple MIME Header Section with media type "message/rfc822" containing a Content-Type header field parameter "forwarded=no" followed by an empty line.¶
If the source is an Original (message/rfc822) Message, the Inner Message Header Section is typically the same as (or a subset of) the Original Message Header Section, and the Inner Message Body is typically the same as the Original Message Body.¶
The Inner Message itself may contain any MIME structure.¶
Note: It is still to be decided by the LAMPS WG whether or not to recommend an alternative MIME format as described in Appendix D.1.1.1 (instead of the currently standardized and above defined format).¶
4.1.2. Sending Side
This section describes the process an MUA should use to apply cryptographic protection to an e-mail message with header protection. We start by describing the legacy message composition process as a baseline.¶
4.1.2.1. Composing a Cryptographically-Protected Message Without Header Protection
[I-D.ietf-lamps-e2e-mail-guidance] describes the typical process for a legacy crypto MUA to apply cryptographic protections to an e-mail message. That guidance and terminology is replicated here for reference:¶
-
origbody: the traditional unprotected message body as a well-formed MIME tree (possibly just a single MIME leaf part). As a well-formed MIME tree,origbodyalready has structural headers (Content-*) present.¶ -
origheaders: the intended non-structural headers for the message, represented here as a list of(h,v)pairs, wherehis a header field name andvis the associated value. Note that these are header fields that the MUA intends to be visible to the recipient of the message. In particular, if the MUA uses theBccheader during composition, but plans to omit it from the message (see section 3.6.3 of [RFC5322]), it will not be inorigheaders.¶ -
crypto: The series of cryptographic protections to apply (for example, "sign with the secret key corresponding to X.509 certificate X, then encrypt to X.509 certificates X and Y"). This is a routine that accepts a MIME tree as input (the Cryptographic Payload), wraps the input in the appropriate Cryptographic Envelope, and returns the resultant MIME tree as output.¶
The algorithm returns a MIME object that is ready to be injected into the mail system:¶
4.1.2.2. Header Confidentiality Policy
When composing an encrypted message with protected headers, the composing MUA needs a Header Confidentialiy Policy.
In this document, we represent that Header Confidentiality Policy as a function hcp:¶
-
hcp(name, val_in) --> val_out: this function takes a header field namenameand initial valueval_inas arguments, and returns a replacement header valueval_out. Ifval_outis the special valuenull, it mean that the header in question should be omitted from the set of headers visible outside the Cryptographic Envelope.¶
For example, an MUA that only obscures the Subject header field by replacing it with the literal string [...] and does not offer confidentiality to any other header fields would be represented as (in pseudocode):¶
hcp(name, val_in) → val_out:
if name is 'Subject':
return '[...]'
else:
return val_in
¶
Note that such a policy is only needed when the end-to-end protections include encryption (confidentiality). No comparable policy is needed for other end-to-end cryptographic protections (integrity and authenticity), as they are simply uniformly applied so that all header fields known by the sender have these protections.¶
This asymmetry is an unfortunate consequence of complexities in message delivery systems, some of which may reject, drop, or delay messages where all headers are removed from the top-level MIME object.¶
This document does not mandate any particular Header Confidentiality Policy, though it offers guidance for MUA implementers in selecting one in Section 4.1.3. Future documents may recommend or mandate such a policy for an MUA with specific needs. Such a recommendation might be motivated by descriptions of metadata-derived attacks, or stem from research about message deliverability, or describe new signalling mechanisms, but these topics are out of scope for this document.¶
4.1.2.3. Composing with "Wrapped Message" Header Protection
To compose a message using "Wrapped Message" header protection, we use those inputs described in Section 4.1.2.1 plus the Header Confidentiality Policy hcp defined in Section 4.1.2.2.
The new algorithm is:¶
-
For header name and value
(h,v)inorigheaders:¶- Add header
hoforigbodywith valuev¶
- Add header
-
If any of the header fields in
origbody, including headers in the nested internal MIME structure, contain any 8-bit UTF-8 characters (see section section 3.7 of [RFC6532]):¶- Let
payloadbe a new MIME part with one header:Content-Type: message/global; forwarded=no, and whose body isorigbody.¶
- Let
-
Else:¶
- Let
payloadbe a new MIME part with one header:Content-Type: message/rfc822; forwarded=no, and whose body isorigbody.¶
- Let
- Apply
cryptotopayload, yielding MIME treeoutput¶ -
If
cryptocontains encryption:¶ -
For header name and value
(h,v)inorigheaders:¶- Add header
hofoutputwith valuev¶
- Add header
- Return
output¶
Note that the Header Confidentiality Policy hcp is ignored if crypto does not contain encryption.
This is by design.¶
4.1.2.4. Composing with "Injected Headers" Header Protection
To compose a message using "Injected Headers" header protection, the composing MUA needs one additional input in addition to the Header Confidentiality Policy hcp defined in Section 4.1.2.2.¶
-
legacy: a boolean value, indicating whether any recipient of the message is believed to have a legacy client. If all recipients are known to implement this draft,legacyshould be set tofalse. (How a MUA determines the value oflegacyis out of scope for this document; an initial implementation can simply set it totrue)¶
Enabling visibility of obscured headers for decryption-capable legacy clients requires transforming a header list into a readable form and including it as a "Legacy Display" element in specially-marked parts of the message.
This document recommends two different mechanisms: one for a text/html Main Body part of the e-mail message, and one for a text/plain Main Body part.
This document does not recommend adding a Legacy Display element to any other part.¶
Please see [I-D.ietf-lamps-e2e-mail-guidance] for guidance on identifying the parts of a message that are a Main Body Part.¶
The revised algorithm for applying cryptographic protection to a message is as follows:¶
-
if
cryptocontains encryption, andlegacyistrue:¶- Create
ldlist, an empty list of(header, value)pairs¶ -
For each header name and value
(h,v)inorigheaders:¶-
If
his user-facing (see [I-D.ietf-lamps-e2e-mail-guidance]):¶
-
-
If
ldlistis not empty:¶- Identify each leaf MIME part of
payloadthat represents the "main body" of the message.¶ -
For each "Main Body Part"
bodypartof typetext/plainortext/html:¶- Insert Legacy Display element header list
ldlistinto the content ofbodypart(see Section 4.1.2.4.1 fortext/plainand Section 4.1.2.4.2 fortext/html)¶ - Add
Content-Typeparameterhp-legacy-displaywith value1tobodypart¶
- Insert Legacy Display element header list
- Identify each leaf MIME part of
- Create
-
For each header name and value
(h,v)inorigheaders:¶- Add header
hof MIME partpayloadwith valuev¶
- Add header
- Set the
protected-headersparameter on theContent-Typeofpayloadtov1¶ - Apply
cryptotopayload, producing MIME treeoutput¶ -
If
cryptocontains encryption:¶ -
For each header name and value
(h,v)inorigheaders:¶- Add header
hofoutputwith valuev¶
- Add header
- Return
output¶
Note that both new parameters (hcp and legacy) are effectively ignored if crypto does not contain encryption.
This is by design, because they are irrelevant for signed-only cryptographic protections.¶
4.1.2.4.1. Adding a Legacy Display Element to a text/plain Part
For a list of obscured headers represented as (header, value) pairs, concatenate them as a set of lines, with one newline at the end of each pair.
Add an additional trailing newline after the resultant text, and prepend the entire list to the body of the text/plain part.¶
For example, if the list of obscured headers was [("Cc", "alice@example.net"), ("Subject", "Thursday's meeting")], then a text/plain part that originally contained:¶
I think we should skip the meeting.¶
Would become:¶
Subject: Thursday's meeting Cc: alice@example.net I think we should skip the meeting.¶
4.1.2.4.2. Adding a Legacy Display Element to a text/html Part
Adding a Legacy Display Element to a text/html part is similar to how it is added to a text/plain part (see Section 4.1.2.4.1).
Instead of adding the obscured headers to a block of text delimited by a blank line, the composing MUA injects them in an HTML <div> element annotated with a class attribute of header-protecton-legacy-display.¶
The content and formatting of this decorative <div> have no strict requirements, but they SHOULD represent all the obscured headers in a readable fashion.
A simple approach is to assemble the text in the same way as Section 4.1.2.4.1, wrap it in a verbatim <pre> element, and put that element in the annotated <div>.¶
The annotated <div> should be placed as close to the start of the <body> as possible, where it will be visible when viewed with a standard HTML renderer.¶
For example, if the list of obscured headers was [("Cc", "alice@example.net"), ("Subject", "Thursday's meeting")], then a text/html part that originally contained:¶
<html><head><title></title></head><body> <p>I think we should skip the meeting.</p> </body></html>¶
Would become:¶
<html><head><title></title></head><body> <div class="header-protection-legacy-display"> <pre>Subject: Thursday's meeting Cc: alice@example.net</pre></div> <p>I think we should skip the meeting.</p> </body></html>¶
4.1.2.4.3. Do Not Add a Legacy Display Element to Other Content-Types
The purpose of injecting a Legacy Display element into each Main Body MIME part is to enable rendering of otherwise obscured headers in legacy clients that are capable of message decryption, but don't know how to follow the rest of the guidance in this document.¶
The authors are unaware of any legacy client that would render any MIME part type other than text/plain and text/html as the Main Body.
A generating MUA SHOULD NOT add a Legacy Display element to any MIME part with any other Content-Type.¶
4.1.2.5. Choosing Between Wrapped Message and Injected Headers
When composing a message with end-to-end cryptographic protections, an MUA SHOULD protect the headers of that message as well as the body.¶
An MUA MAY protect the headers of any outbound message using either the "Wrapped Message" or the "Injected Headers" style of protection. See Section 4.2 for more discussion about reasons to choose one mechanism or another.¶
[[ TODO: this document should recommend generation of one particular scheme by default for new implementers ]]¶
4.1.3. Default Header Confidentiality Policy
An MUA SHOULD have a sensible default Header Confidentiality Policy, and SHOULD NOT require the user to select one.¶
The default Header Confidentiality Policy SHOULD provide confidentiality for the Subject header field by replacing it with the literal string [...].
Most users treat the Subject of a message the same way that they treat the body, and they are surprised to find that the Subject of an encrypted message is visible.¶
[[ TODO: select one of the two policies below the recommended default ]]¶
4.1.3.1. Minimalist Header Confidentiality Policy
Accordingly, the most conservative recommended Header Confidentiality Policy only protects the Subject:¶
hcp_minimal(name, val_in) → val_out:
if name is 'Subject':
return '[...]'
else:
return val_in
¶
4.1.3.2. Strong Header Confidentiality Policy
Alternately, a more aggressive (and therefore more privacy-preserving) Header Confidentiality Policy only leaks a handful of fields whose absence is known to increase rates of delivery failure, and simultaneously obscures the Message-ID behind a random new one:¶
hcp_strong(name, val_in) → val_out:
if name in ['From', 'To', 'Cc', 'Date']:
return val_in
else if name is 'Subject':
return '[...]'
else if name is 'Message-ID':
return generate_new_message_id()
else:
return null
¶
The function generate_new_message_id() represents whatever process the MUA typically uses to generate a Message-ID for a new outbound message.¶
4.1.3.3. Offering Stronger Header Confidentiality
A MUA MAY offer even stronger confidentiality for headers of an encrypted message than described in Section 4.1.3.2.
For example, it might implement an HCP that obfuscates the From field, or omits the Cc field, or ensures Date is represented in UTC (obscuring the local timezone).¶
The authors of this document hope that implementers with deployment experience will document their chosen Header Confidentiality Policy and the rationale behind their choice.¶
4.1.4. Receiving Side
An MUA that receives a cryptographically-protected e-mail will render it for the user.¶
The receiving MUA will render the message body, a selected subset of header fields, and (as described in [I-D.ietf-lamps-e2e-mail-guidance]) provide a summary of the cryptographic properties of the message.¶
Most MUAs only render a subset of header fields by default.
For example, few MUAs typically render Message-Id or Received header fields for the user, but most do render From, To, Cc, Date, and Subject.¶
A MUA that knows how to handle a message with protected headers makes the following two changes to its behavior when rendering a message:¶
- If it detects that an incoming message had protected headers, it renders header fields for the message from the protected headers, ignoring the external (unprotected) headers.¶
- It includes information in the message's cryptographic summary to indicate the types of protection that applied to each rendered header field (if any).¶
A MUA that handles protected headers does not need to render any new header fields that it did not render before.¶
4.1.4.1. Identifying that a Message has Protected Headers
An incoming message can be identified as having protected headers based on one of two signals:¶
- The Cryptographic Payload has
Content-Type: message/rfc822orContent-Type: message/globaland the parameterforwardedhas a value ofno. See Section 4.1.4.3 for rendering guidance.¶ - The Cryptographic Payload has some other
Content-Typeand it has parameterprotected-headersset tov1. See Section 4.1.4.4 for rendering guidance.¶
Messages of both types exist in the wild, and a sensible MUA should be able to handle them both. They provide the same semantics and the same meaning.¶
4.1.4.2. Updating the Cryptographic Summary
Regardless of whether a cryptographically-protected message has protected headers, the cryptographic summary of the message should be modified to indicate what protections the headers have.¶
Each header individually has exactly one the following protections:¶
-
unprotected(this is the case for all headers in messages that have no protected headers)¶ -
signed-only(bound into the same validated signature as the enclosing message, but also visible in transit)¶ -
encrypted-only(only appears within the cryptographic payload; the corresponding external header was either omitted or obfuscated)¶ -
encrypted-and-signed(same as encrypted, but additionally is under a validatd signature)¶
Note that while the message itself may be encrypted-and-signed, some headers may be replicated on the outside of the message (e.g. Date)
Those headers would be signed-only, despite the message itself being encrypted-and-signed.¶
Rendering this information is likely to be complex and messy --- users may not understand it. It is beyond the scope of this document to suggest any specific graphical affordances or user experience. Future work should include examples of successful rendering of this information.¶
4.1.4.3. Rendering a Wrapped Message
When the Cryptographic Payload has Content-Type of message/rfc822 or message/global, and the parameter forwarded is set to no, the values of the protected headers are drawn from the headers of the Cryptographic Payload, and the body that is rendered is the body of the Cryptographic Payload.¶
4.1.4.3.1. Example Signed-Only Wrapped Message
Consider a message with this structure, where the MUA is able to validate the cryptographic signature:¶
A └─╴application/pkcs7-mime; smime-type="signed-data" ⇩ (unwraps to) B └┬╴message/rfc822 [Cryptographic Payload] C └┬╴multipart/alternative [Rendered Body] D ├─╴text/plain E └─╴text/html¶
The message body should be rendered the same way as this message:¶
C └┬╴multipart/alternative D ├─╴text/plain E └─╴text/html¶
It should render header fields taken from part C.¶
Its cryptographic summary should indicates that the message was signed and all rendered header fields were included in the signature.¶
The MUA SHOULD ignore header fields from part A for the purposes of rendering.¶
4.1.4.3.2. Example Encrypted-and-Signed Wrapped Message
Consider a message with this structure, where the MUA is able to validate the cryptographic signature:¶
F └─╴application/pkcs7-mime; smime-type="enveloped-data"
↧ (decrypts to)
G └─╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to)
H └┬╴message/rfc822 [Cryptographic Payload]
I └┬╴multipart/alternative [Rendered Body]
J ├─╴text/plain
K └─╴text/html
¶
The message body should be rendered the same way as this message:¶
I └┬╴multipart/alternative J ├─╴text/plain K └─╴text/html¶
It should render headers taken from part I.¶
Its cryptographic summary should indicates that the message was signed and encrypted.
Each rendered header field found in I should be compared against the header field of the same name from F.
If the value found in F matches the value found in I, the header field should be marked as signed-only.
If no matching header field was found in F, or the value found did not match the value from I, the header field should be marked as signed-and-encrypted.¶
4.1.4.4. Rendering a Message with Injected Headers
When the Cryptographic Payload does not have a Content-Type of message/rfc822 or message/global, and the parameter protected-headers is set to v1, the values of the protected headers are drawn from the headers of the Cryptographic Payload, and the body that is rendered is the Cryptographic Payload itself.¶
4.1.4.4.1. Example Signed-only Message with Injected Headers
L └─╴application/pkcs7-mime; smime-type="signed-data" ⇩ (unwraps to) M └┬╴multipart/alternative [Cryptographic Payload + Rendered Body] N ├─╴text/plain O └─╴text/html¶
The message body should be rendered the same way as this message:¶
M └┬╴multipart/alternative N ├─╴text/plain O └─╴text/html¶
It should render header fieldss taken from part M.¶
Its cryptographic summary should indicates that the message was signed and all rendered header fields were included in the signature.¶
The MUA SHOULD ignore header fields from part L for the purposes of rendering.¶
4.1.4.4.2. Example Signed-and-Encrypted Message with Injected Headers
Consider a message with this structure, where the MUA is able to validate the cryptographic signature:¶
P └─╴application/pkcs7-mime; smime-type="enveloped-data"
↧ (decrypts to)
Q └─╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to)
R └┬╴multipart/alternative [Cryptographic Payload + Rendered Body]
S ├─╴text/plain
T └─╴text/html
¶
The message body should be rendered the same way as this message:¶
R └┬╴multipart/alternative S ├─╴text/plain T └─╴text/html¶
It should render headers taken from part R.¶
Its cryptographic summary should indicates that the message was signed and encrypted.
As in Section 4.1.4.3.2, each rendered header field found in R should be compared against the header field of the same name from P.
If the value found in P matches the value found in R, the header field should be marked as signed-only.
If no matching header field was found in P, or the value found did not match the value from R, the header field should be marked as signed-and-encrypted.¶
4.1.4.4.3. Do Not Render Legacy Display Elements
As described in FIXME:SECTION_REFERENCE, a message with cryptographic confidentiality protection MAY include "Legacy Display" elements for backward-compatibility with legacy MUAs. These Legacy Display elements are strictly decorative, unambiguously identifiable, and will be discarded by compliant implementations.¶
The receiving MUA SHOULD avoid rendering the identified Legacy Display elements to the user at all, since it is aware of and can render the actual Protected Headers.¶
If a text/html or text/plain part within the cryptographic envelope is identified as containing Legacy Display elements, those elements should be hidden when rendering or generating a draft reply.¶
4.1.4.4.3.1. Identifying a Part with Legacy Display Elements
A receiving MUA acting on a message that contains an encrypting Cryptographic Layer identifies a MIME subpart with within the Cryptographic Payload as containing Legacy Display elements based on the Content-Type of the subpart.¶
- The subpart's Content-Type contains a parameter
hp-legacy-displaywith value set to1¶ - The subpart's Content-Type is either
text/html(see Section 4.1.4.4.3.3) ortext/plain(see Section 4.1.4.4.3.2)¶
Note that the term "subpart" above is used in the general sense: if the Cryptographic Payload is a single part, that part itself may contain a Legacy Display element if it is marked with the hp-legacy-display=1 parameter.¶
4.1.4.4.3.2. Omitting Legacy Display Elements from text/plain
If a text/plain part within the Cryptographic Payload has the Content-Type parameter hp-legacy-display="1", it should be processed before rendering in the following fashion:¶
- Discard the leading lines of the body of the part up to and including the first entirely blank line.¶
Note that implementing this strategy is depenent on the charset used by the MIME part.¶
See Appendix E.1 for an example.¶
4.1.4.4.3.3. Omitting Legacy Display Elements from text/html
If a text/html part within the Cryptographic Payload has the Content-Type parameter hp-legacy-display="1", it should be processed before rendering in the following fashion:¶
- If any element of the HTML
<body>is a<div>withclassattributeheader-protecton-legacy-display, that entire element should be omitted.¶
A straightforward way for an HTML-capable MUA to do this is to add an entry to the [CSS] stylesheet for such a part:¶
body div.header-protection-legacy-display:firstchild { display: none; }
¶
4.1.4.5. Affordances for Debugging and Troubleshooting
Note that advanced users of an MUA may need access to the original message, for example to troubleshoot problems with the MUA itself, or problems with the SMTP transport path taken by the message.¶
A MUA that applies these rendering guidelines SHOULD ensure that the full original source of the message as it was received remains available to such a user for debugging and troubleshooting.¶
4.1.4.6. Composing a Reply to an Encrypted Message with Protected Headers
When composing a reply to an encrypted message with protected headers, the MUA is acting both as a receiving MUA and as a sending MUA. Special guidance applies here, as things can go wrong in at least two ways: leaking previously-confidential information, and replying to the wrong party.¶
4.1.4.6.1. Avoid Leaking Encrypted Headers in Reply
As noted in [I-D.ietf-lamps-e2e-mail-guidance], an MUA in this position MUST NOT leak previously-encrypted content in the clear in a followup message. The same is true for protected headers.¶
Values from any header field that was identified as either encrypted or signed-and-encrypted based on the steps outlined above MUST NOT be placed in cleartext output when generating a message.¶
In particular, if Subject was encrypted, and it is copied into the draft encrypted reply, the replying MUA MUST obfuscate the Subject field in the cleartext header as described above.¶
[[ TODO: formally describe how a replying MUA should generate a message-specific Header Protection policy based on the cryptographic status of the headers of the incoming message ]]¶
4.1.4.6.2. Avoid Misdirected Replies to Encrypted Messages with Protected Headers
When replying to a message, the Composing MUA typically decides who to send the reply to based on:¶
- the
Reply-To,Mail-Followup-To, orFromheaders¶ - optionally, the other
ToorCcheaders (if the user chose to "reply all")¶
When a message has protected headers, the replying MUA MUST populate the destination fields of the draft message using the protected headers, and ignore any unprotected headers.¶
This mitigates against an attack where Mallory gets a copy of an encrypted message from Alice to Bob, and then replays the message to Bob with an additional Cc to Mallory's own e-mail address in the message's outer header.¶
If Bob knows Mallory's certificate already, and he replies to such a message without following the guidance in this section, it's likely that his MUA will encrypt the cleartext of the message directly to Mallory.¶
4.1.4.7. Implicitly-rendered Header Fields
While From and To and Cc and Subject and Date are often explicitly rendered to the user, some header fields do affect message display, without being explicitly rendered.¶
For example, Message-Id, References, and In-Reply-To header fields may collectively be used to place a message in a "thread" or series of messages.¶
In another example, Section 4.1.4.6.2 observes that the value of the Reply-To field can influence the draft reply message.
So while the user may never see the Reply-To header directly, it is implicitly "rendered" when the user interacts with the message by replying to it.¶
An MUA that depends on any implicitly-rendered header field in a message with protected headers SHOULD use the value from the protected header, and SHOULD NOT use any value found outside the cryptographic protection.¶
4.1.4.8. Unprotected Headers Added in Transit
Some headers are legitimately added in transit, and could not have been known to the sender at message composition time.¶
The most common of these headers are Received and DKIM-Signature, neither of which are typically rendered, either explicitly or implicitly.¶
If a receiving MUA has specific knowledge about a given header field, including that:¶
- the header field would not have been known to the original sender, and¶
- the header field might be rendered explicitly or implicitly,¶
then the MUA MAY decide to operate on the value of that header field from the unprotected header section, even though the message has protected headers.¶
The MUA MAY prefer to verify that the headers in question have additional transit-derived cryptographic protections (e.g., to test whether they are covered by a valid DKIM-Signature) before rendering or acting on them.¶
Specific examples appear below.¶
4.1.4.8.1. Mailing list headers: List-* and Archived-At
If the message arrives through a mailing list, the list manager itself may inject headers (most of which start with List-) in the message:¶
For some MUAs, these headers are implicitly rendered, by providing buttons for actions like "Subscribe", "View Archived Version", "Reply List", "List Info", etc.¶
An MUA that receives a message with protected headers that contains these header fields in the unprotected section, and that has reason to believe the message is coming through a mailing list MAY decide to render them to the user (explicitly or implicitly) even though they are not protected.¶
FIXME: other examples of unprotected transit headers?¶