forked from pEp.foundation/internet-drafts
393 lines
12 KiB
Plaintext
393 lines
12 KiB
Plaintext
|
||
|
||
|
||
|
||
Network Working Group A. Melnikov
|
||
Internet-Draft Isode Ltd
|
||
Intended status: Informational B. Hoeneisen
|
||
Expires: May 4, 2020 Ucom.ch
|
||
November 01, 2019
|
||
|
||
|
||
IANA Registration of Content-Type Header Field Parameter 'forwarded'
|
||
draft-melnikov-iana-reg-forwarded-00
|
||
|
||
Abstract
|
||
|
||
This document defines a new Content-Type header field parameter with
|
||
name "forwarded" and its registration with IANA.
|
||
|
||
Status of This Memo
|
||
|
||
This Internet-Draft is submitted in full conformance with the
|
||
provisions of BCP 78 and BCP 79.
|
||
|
||
Internet-Drafts are working documents of the Internet Engineering
|
||
Task Force (IETF). Note that other groups may also distribute
|
||
working documents as Internet-Drafts. The list of current Internet-
|
||
Drafts is at https://datatracker.ietf.org/drafts/current/.
|
||
|
||
Internet-Drafts are draft documents valid for a maximum of six months
|
||
and may be updated, replaced, or obsoleted by other documents at any
|
||
time. It is inappropriate to use Internet-Drafts as reference
|
||
material or to cite them other than as "work in progress."
|
||
|
||
This Internet-Draft will expire on May 4, 2020.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (c) 2019 IETF Trust and the persons identified as the
|
||
document authors. All rights reserved.
|
||
|
||
This document is subject to BCP 78 and the IETF Trust's Legal
|
||
Provisions Relating to IETF Documents
|
||
(https://trustee.ietf.org/license-info) in effect on the date of
|
||
publication of this document. Please review these documents
|
||
carefully, as they describe your rights and restrictions with respect
|
||
to this document. Code Components extracted from this document must
|
||
include Simplified BSD License text as described in Section 4.e of
|
||
the Trust Legal Provisions and are provided without warranty as
|
||
described in the Simplified BSD License.
|
||
|
||
|
||
|
||
|
||
|
||
Melnikov & Hoeneisen Expires May 4, 2020 [Page 1]
|
||
|
||
Internet-Draft Content-Type HF Parameter 'forwarded' November 2019
|
||
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
1.2. Implementations . . . . . . . . . . . . . . . . . . . . . 3
|
||
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 3
|
||
1.4. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
|
||
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5
|
||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
|
||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
|
||
8.2. Informative References . . . . . . . . . . . . . . . . . 6
|
||
Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 6
|
||
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 6
|
||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
|
||
1. Introduction
|
||
|
||
This document defines a new Content-Type header field parameter
|
||
[RFC2045] with name "forwarded". The parameter value is case-
|
||
insensitive and can be either "yes", "no" or "unknown". Setting the
|
||
value to "no" is meaningful with media type "message/rfc822" and
|
||
"message/global" [RFC6532] 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" ("message/
|
||
global") is a simple forwarded message. If the value has been set to
|
||
"unknown" (or no such parameter), the default assumption is the
|
||
message has been forwarded.
|
||
|
||
1.1. 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.
|
||
|
||
|
||
|
||
|
||
Melnikov & Hoeneisen Expires May 4, 2020 [Page 2]
|
||
|
||
Internet-Draft Content-Type HF Parameter 'forwarded' November 2019
|
||
|
||
|
||
1.2. 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]
|
||
|
||
1.3. Requirements Language
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in [RFC2119].
|
||
|
||
1.4. Terms
|
||
|
||
The following terms are defined for the scope of this document:
|
||
|
||
o Header Field (HF): cf. [RFC5322]
|
||
|
||
o Header Section (HS): cf. [RFC5322]
|
||
|
||
2. Specification
|
||
|
||
This section defines the new "forwarded" Content-Type header field
|
||
parameter.
|
||
|
||
The Content-Type header field parameter "forwarded" may assume three
|
||
values:
|
||
|
||
o "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".
|
||
|
||
o "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]).
|
||
|
||
o "unknown": 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
|
||
|
||
|
||
|
||
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.
|
||
|
||
3. 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.
|
||
|
||
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: Isode Harrier Web Server
|
||
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--
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Melnikov & Hoeneisen Expires May 4, 2020 [Page 4]
|
||
|
||
Internet-Draft Content-Type HF Parameter 'forwarded' November 2019
|
||
|
||
|
||
4. Security Considerations
|
||
|
||
This document does not define a new protocol, and thus does not
|
||
create new security concerns in and of itself.
|
||
|
||
5. Privacy Considerations
|
||
|
||
This document does not introduce any new issues regarding Privacy.
|
||
|
||
6. IANA Considerations
|
||
|
||
This document requests the registration of the Content-Type header
|
||
field parameter [RFC2045] with name "forwarded" with IANA as
|
||
specified in Section 2 of this document.
|
||
|
||
7. Acknowledgments
|
||
|
||
The authors would like to thank the following people who have
|
||
provided helpful comments and suggestions for this document: David
|
||
Wilson, Kelly Bristol, 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.
|
||
|
||
8. References
|
||
|
||
8.1. Normative References
|
||
|
||
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
||
Extensions (MIME) Part One: Format of Internet Message
|
||
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
|
||
<https://www.rfc-editor.org/info/rfc2045>.
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119,
|
||
DOI 10.17487/RFC2119, March 1997,
|
||
<https://www.rfc-editor.org/info/rfc2119>.
|
||
|
||
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
|
||
DOI 10.17487/RFC5322, October 2008,
|
||
<https://www.rfc-editor.org/info/rfc5322>.
|
||
|
||
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
|
||
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
|
||
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
|
||
April 2019, <https://www.rfc-editor.org/info/rfc8551>.
|
||
|
||
|
||
|
||
|
||
Melnikov & Hoeneisen Expires May 4, 2020 [Page 5]
|
||
|
||
Internet-Draft Content-Type HF Parameter 'forwarded' November 2019
|
||
|
||
|
||
8.2. Informative References
|
||
|
||
[I-D.birk-pep]
|
||
Marques, H., Luck, C., and B. Hoeneisen, "pretty Easy
|
||
privacy (pEp): Privacy by Default", draft-birk-pep-04
|
||
(work in progress), July 2019.
|
||
|
||
[I-D.ietf-lamps-header-protection-requirements]
|
||
Melnikov, A. and B. Hoeneisen, "Problem Statement and
|
||
Requirements for Header Protection", draft-ietf-lamps-
|
||
header-protection-requirements-01 (work in progress),
|
||
October 2019.
|
||
|
||
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
|
||
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
|
||
2012, <https://www.rfc-editor.org/info/rfc6532>.
|
||
|
||
Appendix A. Document Changelog
|
||
|
||
[[ RFC Editor: This section is to be removed before publication ]]
|
||
|
||
o draft-melnikov-iana-reg-forwarded-00
|
||
|
||
o Initial version deruved from draft-ietf-lamps-header-protection-
|
||
requirements-01
|
||
|
||
Appendix B. Open Issues
|
||
|
||
[[ RFC Editor: This section should be empty and is to be removed
|
||
before publication. ]]
|
||
|
||
o Improve document quality, in particular Introduction and
|
||
Specification sections
|
||
|
||
o Refer to specific IANA Registry and its registration specification
|
||
|
||
Authors' Addresses
|
||
|
||
Alexey Melnikov
|
||
Isode Ltd
|
||
14 Castle Mews
|
||
Hampton, Middlesex TW12 2NP
|
||
UK
|
||
|
||
Email: alexey.melnikov@isode.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Melnikov & Hoeneisen Expires May 4, 2020 [Page 6]
|
||
|
||
Internet-Draft Content-Type HF Parameter 'forwarded' November 2019
|
||
|
||
|
||
Bernie Hoeneisen
|
||
Ucom Standards Track Solutions GmbH
|
||
CH-8046 Zuerich
|
||
Switzerland
|
||
|
||
Phone: +41 44 500 52 40
|
||
Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
|
||
URI: https://ucom.ch/
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Melnikov & Hoeneisen Expires May 4, 2020 [Page 7]
|