Network Working Group A. Melnikov, Ed.
Internet-Draft Isode Ltd
Intended status: Informational December 17, 2015
Expires: June 19, 2016
Implementing Draft & Release and Draft & Review in Internet Mail
draft-melnikov-email-draft-and-release-02
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 http://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 June 19, 2016.
Copyright Notice
Copyright (c) 2015 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
(http://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 June 19, 2016 [Page 1]
Internet-Draft Draft & Release email messages December 2015
Table of Contents
1. 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. Message-Draft header field . . . . . . . . . . . . . . . . . 4
6. Registration of new IMAP Keywords . . . . . . . . . . . . . . 4
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8.1. The Message-Draft Header Field registration . . . . . . . 5
8.2. $DraftAuthorized IMAP keyword registration . . . . . . . 6
8.3. $DraftRejected IMAP keyword registration . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
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 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
Melnikov Expires June 19, 2016 [Page 2]
Internet-Draft Draft & Release email messages December 2015
more than one Authorizing User to authorize release of a Draft
Message.
3. Structure of a draft message
Message 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 5. 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". Where a description of the error is
desired in several languages or several media, a "multipart/
alternative" construct can be used.
4. (REQUIRED) The second body part is "message/rfc822" or "message/
global". It wraps the draft message to be released. The draft
message can contain MMHS-Authorizing-Users header field
[I-D.melnikov-mmhs-authorizing-users].
5. (OPTIONAL) The third and subsequent body parts contain comments
from reviewers and/or authorizing users. These body parts are
typically "text/plain" or "text/html".
4. Structure of a confirmation message
1. The media type of the message confirming that the origina draft
message was released, reviewed or rejected can be or any media
type.
2. The message includes the Message-Draft header field Section 5
containing one of "Authorized", "Reviewed" or "Rejected".
3. The message should contain "In-Reply-To:" header field with the
Message-ID of the original draft message.
Melnikov Expires June 19, 2016 [Page 3]
Internet-Draft Draft & Release email messages December 2015
5. Message-Draft header field
Message-Draft specifies what should be done with a draft message or
what was already done with 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"
6. Registration of new IMAP Keywords
This document defines several new IMAP keywords 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.
7. Example
Melnikov Expires June 19, 2016 [Page 4]
Internet-Draft Draft & Release email messages December 2015
Date: 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 msg
--.562b3944-4b07-437f-be7d-1338f523a3a4--
8. IANA Considerations
TBD. Need to register IMAP keywords with IANA.
8.1. The Message-Draft Header Field registration
IANA 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
Melnikov Expires June 19, 2016 [Page 5]
Internet-Draft Draft & Release email messages December 2015
Applicable protocol: mail ([RFC5322])
Status: Standard
Author/Change controller: IETF
Specification document(s): [this RFC]
Related information: none
8.2. $DraftAuthorized IMAP keyword registration
Subject: Registration of IMAP keyword $DraftAuthorized
IMAP 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
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 both
$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
Melnikov Expires June 19, 2016 [Page 6]
Internet-Draft Draft & Release email messages December 2015
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:
$DraftAuthorized 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.
8.3. $DraftRejected IMAP keyword registration
Subject: Registration of IMAP keyword $DraftRejected
IMAP keyword name: $DraftRejected
Purpose (description): The $DraftRejected IMAP keyword designates
the message requiring authorization for release as
rejected by authorizer (processed).
Melnikov Expires June 19, 2016 [Page 7]
Internet-Draft Draft & Release email messages December 2015
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 both
$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
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 June 19, 2016 [Page 8]
Internet-Draft Draft & Release email messages December 2015
$DraftAuthorized 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. Security Considerations
TBD.
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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,
<http://www.rfc-editor.org/info/rfc2045>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<http://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,
<http://www.rfc-editor.org/info/rfc3864>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[I-D.melnikov-mmhs-authorizing-users]
Melnikov, A., "Draft and Release using Internet Email",
draft-melnikov-mmhs-authorizing-users-08 (work in
progress), June 2015.
Melnikov Expires June 19, 2016 [Page 9]
Internet-Draft Draft & Release email messages December 2015
Appendix A. Acknowledgements
Thank 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 June 19, 2016 [Page 10]