When generating or rendering messages, it is useful to know what parts of the message are likely to be displayed, and how.
This section introduces some common terms that can be applied to parts within the Cryptographic Payload.¶
When an e-mail message is composed or rendered to the user there is typically one main view that presents a (mostly textual) part of the message.¶
While the message itself may be constructed of several distinct MIME parts in a tree, but the part that is rendered to the user is the "Main Body Part".¶
When rendering a message, one of the primary jobs of the recieving MUA is identifying which part (or parts) is the Main Body Part.
Typically, this is found by traversing the MIME tree of the message looking for a leaf node that has a primary content type of
text/html) and is not
MIME tree traversal follows the first child of every
multipart node, with the exception of
When traversing a
multipart/alternative node, all children should be scanned, with preference given to the last child node with a MIME type that the MUA is capable of rendering directly.¶
A MUA MAY offer the user a mechanism to prefer a particular MIME type within
multipart/alternative instead of the last renderable child.
For example, a user may explicitly prefer a
text/plain alternative part over
Note that due to uncertainty about the capabilities and configuration of the receiving MUA, the composing MUA SHOULD consider that multiple parts might be rendered as the Main Body Part when the message is ultimately viewed.¶
When composing a message, an originating MUA operating on behalf of an active user can identify which part (or parts) are the "main" parts: these are the parts the MUA generates from the user's editor.
Tooling that automatically generates e-mail messages should also have a reasonable estimate of which part (or parts) are the "main" parts, as they can be programmatically identified by the message author.¶
For a filtering program that attempts to transform an outbound message without any special knowledge about which parts are Main Body Parts, it can identify the likely parts by following the same routine as a receiving MUA.¶
A message may contain one or more separated MIME parts that are intended for download or extraction.
Such a part is commonly called an "attachment", and is commonly identified by having
Content-Disposition: attachment, and is a subpart of a
An MUA MAY identify a subpart as an attachment, or permit extraction of a subpart even when the subpart does not have
For end-to-end encrypted messages, attachments MUST be included within the Cryptographic Payload.
If an attachment is found outside the Cryptographic Payload, then the message is not well-formed (see Section 6.1).¶
Some MUAs have tried to compose messages where each attachment is placed in its own cryptographic envelope.
Such a message is problematic for several reasons:¶
- The attachments can be stripped, replaced, or reordered without breaking any cryptographic integrity mechanism.¶
- The resulting message may have a mix of cryptographic statuses (e.g. if a signature on one part fails but another succeeds, or if one part is encrypted and another is not).
This mix of statuses is difficult to represent to the user in a comprehensible way.¶
Consider a common message with the folloiwing MIME structure:¶
↧ (decrypts to)
⇩ (unwraps to)
Parts M and N comprise the Cryptographic Envelope.¶
Parts Q and R are both Main Body Parts.¶
If part S is
Content-Disposition: attachment, then it is an attachment.
If part S has no
Content-Disposition header, it is potentially ambiguous whether it is an attachment or not.¶
Consider also this alternate structure:¶
↧ (decrypts to)
⇩ (unwraps to)
In this case, parts M and N are still the Cryptographic Envelope.¶
Parts P and R (the first two leaf nodes within each subtree of part O) are the Main Body Parts.¶
Part S is more likely not to be an attachment, as the subtree layout suggests that it is only relevant for the HTML version of the message.
For example, it might be rendered as an image within the HTML alternative.¶