internet-drafts/forwarded-no/draft-melnikov-iana-reg-forwarded.mkd

coding: utf-8 title: "IANA Registration of Content-Type Header Field Parameter 'forwarded'" abbrev: Content-Type HF Parameter 'forwarded' docname: draft-melnikov-iana-reg-forwarded-01 category: info stand_alone: yes pi: [toc, sortrefs, symrefs, comments] author: {::include ../shared/author_tags/alexey_melnikov.mkd} {::include ../shared/author_tags/bernie_hoeneisen.mkd} normative: # RFC822: # RFC1847: # RFC1341: RFC2045: # MIME part 1 # RFC5322: # Email Format # RFC8551: # S/MIME # informative: I-D.ietf-lamps-header-protection-requirements: # RFC8301: # RFC8463: # RFC2046: # RFC3156: # RFC3501: # IMAP # # RFC4949: # Internet Security Glossary # # RFC4880: # PGP # # RFC5321: # RFC5490: # RFC6376: # DKIM # RFC6532: # internationalized email headers # # RFC7208: # SPF # # RFC7258: # RFC7435: # RFC7489: # DMARC # # RFC7942: # I-D.melnikov-lamps-header-protection: I-D.birk-pep: # I-D.marques-pep-email: # I-D.luck-lamps-pep-header-protection: # I-D.marques-pep-handshake: # I-D.birk-pep-trustwords: # I-D.marques-pep-rating: --- abstract This document defines a new Content-Type header field parameter named "forwarded" for "message/rfc822" and "message/global" media types, and its registration with IANA. --- middle # Introduction This document defines a new Content-Type header field parameter {{RFC2045}} for "message/rfc822" and "message/global" {{RFC6532}} media types with name "forwarded". The parameter value is case- insensitive and can be either "yes" or "no". Setting the value to "no" is meaningful when used within S/MIME or PGP/MIME signed or encrypted body parts (cf. {{I-D.ietf-lamps-header-protection-requirements}}. The value "yes" means that the message nested inside "message/rfc822" (or "message/global") is a simple forwarded message. If the parameter is missing, the default assumption is the message has been forwarded. ## Use Cases Two use cases have been discovered so far: 1. This parameter indicates whether a nested message is signed and/or encrypted (S/MIME or PGP/MIME), which tells the receiving side how to display the message to the user. Currently, many email clients display "weird artefacts" to users due to this missing information. 2. This parameter indicates to mailing lists which email messages are forwarded, and which are signed and/or encrypted (S/MIME or PGP/MIME), and how to handle these respective messages. ## Implementations At this time, there are two known email systems which use this Content-Type header field parameter: 1. Isode with S/MIME {{RFC8551}} 2. pEp with PGP/MIME {{I-D.birk-pep}} {::include ../shared/text-blocks/key-words-rfc2119.mkd} {::include ../shared/text-blocks/terms-intro.mkd} * Header Field (HF): cf. {{RFC5322}} * Header Section (HS): cf. {{RFC5322}} # Specification {#specification} This section defines the new "forwarded" Content-Type header field parameter. The Content-Type header field parameter "forwarded" may assume three values: * "yes": The email message contained in the MIME part is a forwarded message. A MUA (Mail User Agent) that is forwarding a message should add a Content-Type header field parameter "forwarded=yes". * "no": The email message contained in the MIME part is a encapsulated email message that has been signed and/or encrypted for header protection. MUAs SHOULD add a Content-Type header field parameter "forwarded=no" to indicate the message is not forwarded, but encapsulated for header protection (cf. {{I-D.ietf-lamps-header-protection-requirements}}). * absent: If the MUA has no information to determine whether an email message is forwarded or encapsulated, it omits the "forwarded" 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. # Example The following example shows the usage of the Content-Type header field parameter "forwarded" for an email message that is not forwarded, but encapsulated in another email message. {::include ../shared/fence-line.mkd} Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) Message-ID: e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net Subject: Meeting at my place From: "Alexey Melnikov" alexey.melnikov@example.net MIME-Version: 1.0 Content-Type: multipart/signed; charset=us-ascii; micalg=sha1; protocol="application/pkcs7-signature"; boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237 This is a multipart message in MIME format. --.cbe16d2a-e1a3-4220-b821-38348fc97237 Content-Type: message/rfc822; forwarded=no Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) From: "Alexey Melnikov" alexey.melnikov@example.net Message-ID: e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net MIME-Version: 1.0 MMHS-Primary-Precedence: 3 Subject: Meeting at my place To: somebody@example.net X-Mailer: Example Mailer Content-Type: text/plain; charset=us-ascii This is an important message that I don't want to be modified. --.cbe16d2a-e1a3-4220-b821-38348fc97237 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature base-64 encoded signature --.cbe16d2a-e1a3-4220-b821-38348fc97237-- {::include ../shared/fence-line.mkd} {{additional-example}} contains an additional example on the usage of the Content-Type header field parameter "forwarded" as used by pEp {{I-D.birk-pep}}. # Security Considerations This document does not define a new protocol, and thus does not create new security concerns in and of itself. # Privacy Considerations This document does not introduce any new issues regarding Privacy. # IANA Considerations This document requests IANA to register the Content-Type header field parameter {{RFC2045}} with name "forwarded" for "message/rfc822" and "message/global" media types as specified in {{specification}} of this document. # Acknowledgments The authors would like to thank the following people who have provided helpful comments and suggestions for this document: David Wilson, Kelly Bristol, Krista Bennett, Robert Williams, Steve Kille, and Wei Chuang. David Wilson came up with the idea of defining a new Content-Type header field parameter to distinguish forwarded messages from inner header field protection constructs. --- back # Additional Example (pEp) {#additional-example} 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). The inner email message was not forwarded, but encapsulated in another email message. {::include ../shared/fence-line.mkd} Message-ID: pEp.PVUYXR.CEB1A-47AC-4B4D-AC1B-F8F02D49D@example.org From: Alice Spivak Hyatt alice@example.org To: Carol Burnett carol@example.net Subject: pEp [...] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="238e1f2946e87ccd3d1b58ba507ed7ab" --238e1f2946e87ccd3d1b58ba507ed7ab Content-Type: text/plain; charset="utf-8" Content-Disposition: inline; filename="msg.txt" [[ User-Information, e.g. "If you are seeing this message, your client does not support raising message attachments. Please click on the message attachment to view it!" ]] --238e1f2946e87ccd3d1b58ba507ed7ab Content-Type: message/rfc822; forwarded="no" Message-ID: pEp.PVUYXR.CEB1A-47AC-4B4D-AC1B-F8F02D49D@example.org From: Alice Spivak Hyatt alice@example.org To: Carol Burnett carol@example.net Subject: Boom shaka laka [...] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="msg.txt" Don't you get sick of these=3F --238e1f2946e87ccd3d1b58ba507ed7ab Content-Type: application/pgp-keys Content-Disposition: attachment; filename="pEpkey.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFV4PbEBCADTmjGDsoti/VPoZ3w2oCjLBNq1jWIGMkbiUgCGUQjVsNrSZ80U [...] q46bEcclS/gTGHtFweVOiqRnR4H5YEjurCd84h8zF8MAArhxBhAtbg1nYgeHjkKX =t2WB -----END PGP PUBLIC KEY BLOCK----- --238e1f2946e87ccd3d1b58ba507ed7ab-- {::include ../shared/fence-line.mkd} # Document Changelog RFC Editor: This section is to be removed before publication * draft-melnikov-iana-reg-forwarded-00 * Initial version derived from draft-ietf-lamps-header-protection-requirements-01 # 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 before publication. ]]