Content-Type header field parameter. A receiving MUAs default
behavior is to assume the email message contained in the MIME part
is a forwarded message.
<!--[krb: It's suggested to re-add comments about unknown types per Krista, so I would put the part about the "unknown" parameter from prior versions of this docu back in, if all is still applicable. "If the MUA has no information to determine whether an
email message is forwarded or encapsulated, it MAY add a Content-
Type header field parameter "forwarded=unknown" to indicate
support for this Content-Type header field parameter. Email
messages containing a Content-Type header field parameter
"forwarded=unknown" are normally treated the same as messages
<!-- krb: It's suggested to re-add comments about unknown types per
Krista, so I would put the part about the "unknown" parameter
from prior versions of this docu back in, if all is still
applicable.
"If the MUA has no information to determine whether an email
message is forwarded or encapsulated, it MAY add a Content-Type
header field parameter "forwarded=unknown" to indicate support
for this Content-Type header field parameter. Email messages
containing a Content-Type header field parameter
"forwarded=unknown" are normally treated the same as messages
where the Content-Type header field parameter "forwarded" is
missing. The latter is normally the case for legacy clients
unaware of the Content-Type header field parameter "forwarded"
specified herein. A receiving MUAs default behavior is to assume
the email message contained in the MIME part is a forwarded
message."
Melnikov & Hoeneisen Expires May 4, 2020 [Page 3]
Internet-Draft Content-Type HF Parameter 'forwarded' November 2019
where the Content-Type header field parameter "forwarded" is
missing. The latter is normally the case for legacy clients
unaware of the Content-Type header field parameter "forwarded"
specified herein. A receiving MUAs default behavior is to assume
the email message contained in the MIME part is a forwarded
message." ] -->
-->
# Example
@ -241,8 +240,8 @@ header field protection constructs.
The following example shows the usage of the Content-Type header field
parameter "forwarded" as used by pEp {{I-D.birk-pep}} in an email
message (after decryption). This email message was not forwarded, but
encapsulated in another email message.
message (after decryption). The inner email message was not forwarded,
but encapsulated in another email message.
{::include ../shared/fence-line.mkd}
@ -306,5 +305,9 @@ encapsulated in another email message.
# Open Issues
* Determine whether to add an option for "forwarded=unknown" to
indicate support for this Content-Type header field parameter.
\[\[ RFC Editor: This section should be empty and is to be removed
<ahref="#rfc.appendix.A">Appendix A.</a><ahref="#additional-example"id="additional-example">Additional Example (pEp)</a>
</h1>
<pid="rfc.section.A.p.1">The following example shows the usage of the Content-Type header field parameter “forwarded” as used by pEp <ahref="#I-D.birk-pep"class="xref">[I-D.birk-pep]</a> in an email message (after decryption). Said email messge was not forwarded, but encapsulated in another email message.</p>
<pid="rfc.section.A.p.1">The following example shows the usage of the Content-Type header field parameter “forwarded” as used by pEp <ahref="#I-D.birk-pep"class="xref">[I-D.birk-pep]</a> in an email message (after decryption). The inner email message was not forwarded, but encapsulated in another email message.</p>
<pid="rfc.section.C.p.1">[[ RFC Editor: This section should be empty and is to be removed before publication. ]]</p>
<p></p>
<ul><li>Determine whether to add an option for “forwarded=unknown” to indicate support for this Content-Type header field parameter.</li></ul>
<pid="rfc.section.C.p.2">[[ RFC Editor: This section should be empty and is to be removed before publication. ]]</p>
