Network Working Group A. Melnikov, Ed. Internet-Draft Isode Ltd Intended status: Informational February 17, 2021 Expires: August 21, 2021Implementing Draft & Release and Draft & Review in Internet Mail draft-melnikov-email-draft-and-release-04
Abstract
This document describes how draft messages intended for Draft & Release and Draft & Review environments can be represented in Internet Email.
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 August 21, 2021.
Copyright Notice
Copyright (c) 2021 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 Expires August 21, 2021 [Page 1]
Internet-Draft Draft & Release email messages February 2021
Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
3. Structure of a draft message . . . . . . . . . . . . . . . . 3
4. Structure of a confirmation message . . . . . . . . . . . . . 3
5. Structure of a rejection message . . . . . . . . . . . . . . 4
6. Message-Draft header field . . . . . . . . . . . . . . . . . 4
7. Registration of new IMAP Keywords . . . . . . . . . . . . . . 4
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9.1. The Message-Draft Header Field registration . . . . . . . 5
9.2. $DraftReviewed IMAP keyword registration . . . . . . . . 6
9.3. $DraftAuthorized IMAP keyword registration . . . . . . . 7
9.4. $DraftRejected IMAP keyword registration . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. Normative References . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
In some environments email messages can't be released to the MTS (Mail Transfer System) and, thus delivered to recipients, unless they are authorized by one or more authorizing users (e.g. Releasing Officers or Release Authorities). This document describes how such Draft messages can be represented as Internet Email [RFC5322] MIME objects [RFC2045].
2. Conventions Used in This Document
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].The formal syntax uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation including the core rules defined in Appendix B of RFC 5234 [RFC5234]. Terms not defined in this document are taken from [RFC5322].
2.1. Terminology
Drafter: Any email user that composes a message (Draft Message) needing authorisation before it is released to its intended recipients. Authorizing User (also known as Releaser or Authorizer): The mailbox of a user or a group of users that must inspect and authorise the release of Draft Message before it can be sent. An organization may require more than one Authorizing User to authorize release of a Draft Message.
Melnikov Expires August 21, 2021 [Page 2]
Internet-Draft Draft & Release email messages February 2021 3. Structure of a draft messageMessage encapsulating a draft message to be released or reviewed (a.k.a. "outer message") is constructed as follows:
1. The media type of the outer message is "multipart/mixed".
2. The outer message contains the Message-Draft header field Section 6. The initial message for release/review would contain "For Release", "For Confirmed Release" or "For Review" in this header field. [[CREF1: Is "For Confirmed Release" needed? Use MDN request instead?]]
3. (REQUIRED) The first body part of the outer message contains a human-readable message. The purpose of this message is to convey information about the inner draft message from the drafter to authorizing user. This body part can use any IANA-registered MIME media type, charset, or language. But this body part is typically "text/plain" or "text/html". Where a description of the error is desired in several languages or several media, a "multipart/alternative" or "multipart/multilingual" [RFC8255] construct can be used.
4. (REQUIRED) The second body part is "message/rfc822" or "message/ global" [RFC6532]. It wraps the draft message to be released. The draft message can contain MMHS-Authorizing-Users header field [RFC7912].
5. (OPTIONAL) The third and subsequent body parts contain comments from reviewers and/or authorizing users. These body parts are typically "text/plain", "text/html", "message/rfc822" or "message/global", but can be other types (e.g. "multipart/ related").
4. Structure of a confirmation message
The message confirming that the original draft message was released, reviewed or rejected is sent from the reviewer/releaser to the drafter. It is formatted as an Message Disposition Notification (MDN) [RFC8098].
Melnikov Expires August 21, 2021 [Page 3]
Internet-Draft Draft & Release email messages February 2021 5. Structure of a rejection messageThe rejection message provides details on why the original draft message was rejected by the reviewer/releaser. It is sent from reviewer/releaser to the drafter. It has the same structure as a regular draft message (see Section 3), but the first body part contains explanation of why the draft message was rejected.
6. Message-Draft header field
Message-Draft header field specifies what should be done with a draft message or what was action was performed on it.This message header can appear at most once in the header.
Message-Draft = "Message-Draft:"
[FWS] Message-Draft-Type [FWS] CRLF
Message-Draft-Type = "For Release" /
"For Confirmed Release" / "For Review" / "Authorized" / "Reviewed" / "Rejected"
7. Registration of new IMAP Keywords
This document defines several new IMAP keywords [RFC3501] that can be used to override values stored in the Message-Draft header field. (I.e. if one of these mutually exclusive keywords is found, they take precedence over the value specified in the Message-Draft header field.) This allow client developers to implement easier Draft & Release workflow without requiring to re-upload the modified message with IMAP APPEND command.All of the following IMAP keywords are mutually exclusive:
$DraftAuthorized corresponds to the "Authorized" value of the Message-Draft header field;
$DraftReviewed corresponds to the "Reviewed" value of the Message- Draft header field;
$DraftRejected corresponds to the "Rejected" value of the Message- Draft header field.
Melnikov Expires August 21, 2021 [Page 4]
Internet-Draft Draft & Release email messages February 2021 8. ExampleDate: Thu, 23 Oct 2014 10:07:18 -0400 From: TwHarrierTest <harriertest@example.com> Message-Draft: For Confirmed Release Message-Id: <634f2005-0bf1-4e07-a789-e78433a985f7@imap.example.com> Mmhs-Primary-Precedence: 2 Subject: Cease Fire To: <alexey.melnikov@example.com> X-Mailer: Harrier MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=.562b3944-4b07-437f-be7d-1338f523a3a4
This is a multipart message in MIME format.
--.562b3944-4b07-437f-be7d-1338f523a3a4 content-type: text/plain; charset=utf-8
Alexey please release this. --.562b3944-4b07-437f-be7d-1338f523a3a4 Content-Disposition: attachment Content-Type: message/rfc822
Content-type: text/plain; charset=utf-8; delsp=yes; format=flowed From: TwHarrierTest <harriertest@example.com> message-draft: For Confirmed Release message-id: <0a2d822c-0b14-4d02-9215-45292676137f@imap.example.com> MIME-Version: 1.0 mmhs-copy-precedence: 5 mmhs-primary-precedence: 5 Subject: Cease Fire To: <commander@example.com> X-Mailer: Harrier
Text of cease fire message --.562b3944-4b07-437f-be7d-1338f523a3a4--
9. IANA Considerations 9.1. The Message-Draft Header Field registrationIANA is requested to add the Message-Draft header field to the IANA "Permanent Message Header Field Names" registry, per the procedure found in [RFC3864]. That entry is to be updated to reference this document. The following is the registration template:
Header field name: Message-Draft Applicable protocol: mail ([RFC5322])
Melnikov Expires August 21, 2021 [Page 5]
Internet-Draft Draft & Release email messages February 2021
Status: StandardAuthor/Change controller: IETF
Specification document(s): [this RFC]
Related information: none
9.2. $DraftReviewed IMAP keyword registration
Subject: Registration of IMAP keyword $DraftReviewedIMAP keyword name: $DraftReviewed
Purpose (description): The $DraftReviewed IMAP keyword designates
the message requiring review as approved (processed).
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: When this keyword is set, it means that the message is already reviewed and doesn't need any action. Lack of all of $DraftReviewed, $DraftAuthorized and $DraftRejected can cause the client to popup a dialog or show some other UI for authorizing release of a message.
When/by whom the keyword is set/cleared: This keyword is
set by an email client when the message is reviewed.
Related keywords: $DraftRejected Related IMAP capabilities: None
Melnikov Expires August 21, 2021 [Page 6]
Internet-Draft Draft & Release email messages February 2021
Security considerations:Published specification (recommended): [[This-RFC]]
Person & email address to contact for further information:
Alexey Melnikov <alexey.melnikov@isode.com>
Intended usage: COMMON
Owner/Change controller: IESG
Note:
$DraftAuthorized, $DraftReviewed and $DraftRejected are mutually exclusive. If more than one of them is set for a message, the mail client MUST treat this as if neither of them is set and SHOULD remove both of them from the IMAP server.
9.3. $DraftAuthorized IMAP keyword registration
Subject: Registration of IMAP keyword $DraftAuthorizedIMAP keyword name: $DraftAuthorized
Purpose (description): The $DraftAuthorized IMAP keyword designates the message requiring authorization for release as authorized (processed). Private or Shared on a server: SHARED
Melnikov Expires August 21, 2021 [Page 7]
Internet-Draft Draft & Release email messages February 2021
Is it an advisory keyword or may it cause an automatic action: When this keyword is set, it means that the message is already authorized and doesn't need any action. Lack of all of $DraftReviewed, $DraftAuthorized and $DraftRejected can cause the client to popup a dialog or show some other UI for authorizing release of a message.When/by whom the keyword is set/cleared: This keyword is
set by an email client when the message is authorized.
Related keywords: $DraftRejected
Related IMAP capabilities: None
Security considerations:
Published specification (recommended): [[This-RFC]]
Person & email address to contact for further information:
Alexey Melnikov <alexey.melnikov@isode.com>
Intended usage: COMMON
Owner/Change controller: IESG Note:
Melnikov Expires August 21, 2021 [Page 8]
Internet-Draft Draft & Release email messages February 2021
$DraftAuthorized, $DraftReviewed and $DraftRejected are mutually exclusive. If more than one of them is set for a message, the mail client MUST treat this as if neither of them is set and SHOULD remove both of them from the IMAP server.
9.4. $DraftRejected IMAP keyword registration
Subject: Registration of IMAP keyword $DraftRejectedIMAP keyword name: $DraftRejected
Purpose (description): The $DraftRejected IMAP keyword designates the message requiring review or authorization for release as rejected by releaser/reviewer (processed).
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: When this keyword is set, it means that the message is already rejected and doesn't need any action. Lack of all of $DraftReviewed, $DraftAuthorized and $DraftRejected can cause the client to popup a dialog or show some other UI for authorizing release of a message.
When/by whom the keyword is set/cleared: This keyword is
set by an email client when the message is rejected by authorizer.
Related keywords: $DraftAuthorized,
$DraftReviewed
Melnikov Expires August 21, 2021 [Page 9]
Internet-Draft Draft & Release email messages February 2021
Related IMAP capabilities: NoneSecurity considerations:
Published specification (recommended): [[This-RFC]]
Person & email address to contact for further information:
Alexey Melnikov <alexey.melnikov@isode.com>
Intended usage: COMMON
Owner/Change controller: IESG
Note:
$DraftAuthorized, $DraftReviewed and $DraftRejected are mutually exclusive. If more than one of them is set for a message, the mail client MUST treat this as if neither of them is set and SHOULD remove both of them from the IMAP server.
10. Security Considerations
TBD.
11. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet MailExtensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <https://www.rfc-editor.org/info/rfc2045>.
Melnikov Expires August 21, 2021 [Page 10]
Internet-Draft Draft & Release email messages February 2021
[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <https://www.rfc-editor.org/info/rfc3501>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <https://www.rfc-editor.org/info/rfc3864>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[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>.
[RFC7912] Melnikov, A., "Message Authorizing Email Header Field and
Its Use for the Draft and Release Procedure", RFC 7912, DOI 10.17487/RFC7912, June 2016, <https://www.rfc-editor.org/info/rfc7912>.
[RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition
Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098, February 2017, <https://www.rfc-editor.org/info/rfc8098>.
[RFC8255] Tomkinson, N. and N. Borenstein, "Multiple Language
Content Type", RFC 8255, DOI 10.17487/RFC8255, October 2017, <https://www.rfc-editor.org/info/rfc8255>.
Melnikov Expires August 21, 2021 [Page 11]
Internet-Draft Draft & Release email messages February 2021 Appendix A. AcknowledgementsThank you to Steve Kille and Tom Watson for suggestions, comments and corrections on this document.
Author's Address
Alexey Melnikov (editor) Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP UK
EMail: Alexey.Melnikov@isode.com
Melnikov Expires August 21, 2021 [Page 12]
