Isode Ltd

14 Castle Mews Hampton Middlesex TW12 2NP UK Alexey.Melnikov@isode.com

MMHS email This document describes how draft messages intended for Draft & Release and Draft & Review environments can be represented in Internet Email.

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 MIME objects .

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 . The formal syntax uses the Augmented Backus-Naur Form (ABNF) notation including the core rules defined in Appendix B of RFC 5234. Terms not defined in this document are taken from .

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 more than one Authorizing User to authorize release of a Draft Message.

Message encapsulating a draft message to be released or reviewed (a.k.a. "outer message") is constructed as follows: The media type of the outer message is "multipart/mixed". The outer message contains the Message-Draft header field . The initial message for release/review would contain "For Release", "For Confirmed Release" or "For Review" in this header field. Is "For Confirmed Release" needed? Use MDN request instead? (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. (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 . (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".

The media type of the message confirming that the origina draft message was released, reviewed or rejected can be or any media type. The message includes the Message-Draft header field containing one of "Authorized", "Reviewed" or "Rejected". The message should contain "In-Reply-To:" header field with the Message-ID of the original draft message.

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.

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: $DraftForRelease corresponds to the "For Release" value of the Message-Draft header field; $DraftForConfirmedRelease corresponds to the "For Confirmed Release" value of the Message-Draft header field; $DraftForReview corresponds to the "For Review" value of the Message-Draft header field; $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.

Message-Draft: For Confirmed Release Message-Id: <634f2005-0bf1-4e07-a789-e78433a985f7@imap.example.com> Mmhs-Primary-Precedence: 2 Subject: Cease Fire To: 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 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: X-Mailer: Harrier Text of cease fire msg --.562b3944-4b07-437f-be7d-1338f523a3a4-- ]]>

TBD. Need to register IMAP keywords with IANA.

IANA is requested to add the Message-Draft header field to the IANA "Permanent Message Header Field Names" registry, per the procedure found in . That entry is to be updated to reference this document. The following is the registration template: Header field name: Message-Draft Applicable protocol: mail () Status: Standard Author/Change controller: IETF Specification document(s): [this RFC] Related information: none

TBD.

This document describes a procedure for when an Military Message Handling System (MMHS) message is composed by one user and is only released to the mail transfer system when one or more authorizing users authorize release of the message by adding the MMHS- Authorizing-Users header field. The resulting message can be optionally signed by the sender and/or reviewer, allowing recipients to verify both the original signature (if any) and review signatures.

Thank you to Steve Kille and Tom Watson for suggestions, comments and corrections on this document.