draft-melnikov-mmhs-profile.xml

<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>

<rfc ipr="trust200902" category="info" docName='draft-melnikov-mmhs-profile-09'>
 <front>
  <title abbrev="MMHS over SMTP">
   Military Message Handling System (MMHS) over SMTP Profile
  </title>
  <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
   <organization>Isode Ltd</organization>
   <address>
    <postal>
     <street>5 Castle Business Village</street>
     <street>36 Station Road</street>
     <city>Hampton</city>
     <region>Middlesex</region>
     <code>TW12 2BX</code>
     <country>UK</country>
    </postal>
    <email>Alexey.Melnikov@isode.com</email>
   </address>
  </author>
  <author initials="G." surname="Lunt" fullname="Graeme Lunt">
   <organization>SMHS Ltd</organization>
   <address>
    <postal>
     <street>Bescar Moss Farm</street>
     <street>Bescar Lane</street>
     <city>Ormskirk</city>
     <code>L40 9QN</code>
     <country>UK</country>
    </postal>
    <email>graeme.lunt@smhs.co.uk</email>
   </address>
  </author>
  <author initials="A." surname="Ross" fullname="Alan Ross">
   <organization>SMHS Ltd</organization>
   <address>
    <postal>
     <street>Bescar Moss Farm</street>
     <street>Bescar Lane</street>
     <city>Ormskirk</city>
     <code>L40 9QN</code>
     <country>UK</country>
    </postal>
    <email>alan.ross@smhs.co.uk</email>
   </address>
  </author>

  <date year="2015"/>

  <keyword>MMHS</keyword>
  <keyword>SMTP</keyword>
  <keyword>email</keyword>
  <keyword>elements of service</keyword>

  <abstract>
   <t>
    A Military Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks. The MMHS Elements of Service have been defined as a set of extensions to the ITU-T X.400 (1992) international standards and are specified in STANAG 4406 Edition 2 or ACP 123.
   </t>
   <t>
    This document specifies how a messaging service that meets these service definitions can be provided using the SMTP family of protocols.   It defines a profile that can be used by those wishing to ensure that these services are provided.
   </t>
  </abstract>

 </front>
 <middle>
  <section title="Introduction">
   <section title="Overview">
    <t>
     A Military Message Handling System (MMHS) processes formal messages ensuring release,
     distribution, security, and timely delivery across national and international
     strategic and tactical networks.  The MMHS Elements of Service are defined as
     a set of extensions to the ITU-T X.400 (1992) international standards and are specified
     in STANAG 4406 Edition 2 or <xref target="ACP123"/>.  This document specifies an MMHS Profile for how a comparable
     messaging service can be provided using Email Message Format <xref target="RFC5322"/>,
     SMTP <xref target="RFC5321"/> and their extensions.
    </t>
   </section>
   <section title="MMHS Profile Summary">
    <t>
     This non-normative section provides a summary of the sections in this document that specifies the MMHS Profile; refer to the sections that follow for a normative specification of the MMHS Profile.
    </t>
    <t>
     The fundamental purpose of STANAG 4406 Edition 2 or <xref target="ACP123"/> is to define a common message service to be provided between all participating organisations (or domains).  STANAG 4406 Edition 2 and <xref target="ACP123"/> achieve this by defining the Military Messaging Elements of Service (EoS) that are required to be supported. <xref target="ACP123"/> defines EoS as 'abstractions that describe features of a system for which the user of that system has direct access'. Note for the purposes of this MMHS Profile a 'user' can be described as: an end user; an organisation (or domain); a Mail User Agent (MUA); a Mail Submission Agent (MSA); a Mail Transfer Agent (MTA); or, Mail Delivery Agent (MDA).
    </t>
    <t>
     The MMHS Profile adopts the EoS defined in <xref target="ACP123"/>.
    </t>
    <t>
     <xref target="Elements-of-Service"/> provides a developer-friendly summary (<xref target="Profile-Support"/>) and a detailed definition (<xref target="Basic-Elements-of-Service"/>, <xref target="Optional-Elements-of-Service"/> and <xref target="Military-Elements-of-Service"/>) that specifies:
     <list style="symbols">
      <t>
       the mandatory and optional EoS to be supported in order to claim conformance to this MMHS Profile; and,
      </t>
      <t>
       the relevant IETF RFC Standard that provides the comparable EoS.
      </t>
     </list>
    </t>
    <t>
     <xref target="Security-Services"/> describes generic security services independent of the mechanisms used to provide the security (<xref target="General-Security-Elements-of-Service"/>) and profiles the use of Secure Multipurpose Internet Mail Extensions (S/MIME) protocols (<xref target="RFC5751"/>, <xref target="RFC5652"/> and <xref target="RFC2634"/>) and DomainKeys Identified Mail (DKIM) Signatures (<xref target="RFC6376"/>) for implementing these security services (<xref target="Security-Profile"/>).
    </t>
    <t>
     In order to implement an MMHS a number of components are typically deployed to support <xref target="ACP123"/>. The MMHS profile (defined in this document) identifies the requirements on the following SMTP MMHS components in order to claim conformance with the EoS specified in <xref target="Elements-of-Service"/> and the security services specified in <xref target="Security-Services"/> (Note: additional SMTP extensions that provide additional SMTP functionality but do not have equivalent <xref target="ACP123"/> EoS are also included in these sections):
     <list style="symbols">
      <t>
       Mail User Agent (<xref target="mua-reqs"/>);
      </t>
      <t>
       Mail Submission Agent (<xref target="msa-reqs"/>); and,
      </t>
      <t>
       Mail Transfer Agent (<xref target="mta-reqs"/>);
      </t>
     </list>
    </t>
   </section>
  </section>

  <section title="Conventions Used in This Document">

   <t>
    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
    <xref target="RFC2119"/>.
   </t>

   <!--
<t>
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.  Line breaks that do not start a new "C:" or
"S:" exist for editorial reasons and are not a part of the protocol.
</t>
-->

  </section>

  <section title="Elements of Service" anchor="Elements-of-Service">
   <section title="Introduction">
    <t>
     The military messaging elements of service are adopted from <xref target="ACP123"/>.
    </t>
    <t>
     Many of these elements of service are derived from the X.400 standards upon which <xref target="ACP123"/> is based.
    </t>
    <t>
     Note that some of the X.400 elements of service do not have an equivalent in a SMTP messaging system. It is not the intention of this profile to define additional SMTP functionality and consequently a number of the military messaging elements of service are not supported by this profile.
    </t>
    <t>
     Specifically, the physical delivery, conversion (implicit or explicit) and alternate recipient elements of service are not supported by this profile.
    </t>
    <t>
     This profile adopts, where appropriate, header fields that are defined in <xref target="RFC2156"/> to support X.400 elements of service that support military messaging elements of service. <xref target="RFC2156"/> has already addressed the issue of conveying many of the X.400 elements of service within an SMTP messaging system.
    </t>
   </section>
   <section title="Profile Support" anchor="Profile-Support">
    <texttable>
     <!--
		<preamble></preamble>
    -->
     <ttcol align="left" width="25%">Element of Service</ttcol>
     <ttcol align="left">ACP123 Reference</ttcol>
     <ttcol align="left">Support</ttcol>
     <ttcol align="left">SMTP Standard</ttcol>
     <ttcol align="left" width="20%">Header Field or SMTP Parameter</ttcol>
     <c>
      <xref target="Access-Management">Access Management</xref>
     </c>
     <c>
      205a
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC4954"/>, <xref target="RFC3207"/>
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Content-Type-Indication">Content Type Indication</xref>
     </c>
     <c>
      205b
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC6477"/>, 3.2
     </c>
     <c>
      MMHS-Extended-Authorization-Info
     </c>
     <c>
      <xref target="Converted-Indication">Converted Indication</xref>
     </c>
     <c>
      205c
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Delivery-Time-Stamp-Indication">Delivery Time Stamp Indication</xref>
     </c>
     <c>
      205d
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC5322"/>, 3.6.7
     </c>
     <c>
      Received
     </c>
     <c>
      <xref target="MM-Identification">MM Identification</xref>
     </c>
     <c>
      205e
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC5322"/>, 3.6.4
     </c>
     <c>
      Message-ID
     </c>
     <c>
      <xref target="Message-Identification">Message Identification</xref>
     </c>
     <c>
      205f
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC3461"/>, 4.4
     </c>
     <c>
      ENVID
     </c>
     <c>
      <xref target="Non-Delivery-Notification">Non-delivery Notification</xref>
     </c>
     <c>
      205g
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC3461"/>, 4.1
     </c>
     <c>
      NOTIFY=FAILURE
     </c>
     <c>
      <xref target="Original-Encoded-Information-Types">Original Encoded Information Types</xref>
     </c>
     <c>
      205h
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC2156"/>, 2.3.1.1
     </c>
     <c>
      Original-Encoded-Information-Types
     </c>
     <c>
      <xref target="Submission-Time-Stamp-Indication">Submission Time Stamp Indication</xref>
     </c>
     <c>
      205i
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC5322"/>, 3.6.7
     </c>
     <c>
      Received
     </c>
     <c>
      <xref target="Typed-Body">Typed Body</xref>
     </c>
     <c>
      205j
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC2045"/>, 5
     </c>
     <c>
      Content-Type
     </c>
     <c>
      <xref target="User-UA-Capabilities-Registration">User/UA Capabilities Registration</xref>
     </c>
     <c>
      205k
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Alternate-Recipient-Allowed">Alternate Recipient Allowed</xref>
     </c>
     <c>
      206a
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Alternate-Recipient-Assignment">Alternate Recipient Assignment</xref>
     </c>
     <c>
      206b
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Authorizing-Users-Indication">Authorizing Users Indication</xref>
     </c>
     <c>
      206c
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="I-D.melnikov-mmhs-authorizing-users"/>
     </c>
     <c>
      MMHS-Authorizing-Users
     </c>
     <c>
      <xref target="Auto-Forwarded-Indication">Auto-forwarded Indication</xref>
     </c>
     <c>
      206d
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC2156"/>, 2.3.1.2
     </c>
     <c>
      Autoforwarded
     </c>
     <c>
      <xref target="Blind-Copy-Recipient-Indication">Blind Copy Recipient Indication</xref>
     </c>
     <c>
      206e
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC5322"/>, 3.6.3
     </c>
     <c>
      Bcc
     </c>
     <c>
      <xref target="Body-Part-Encryption-Indication">Body Part Encryption Indication</xref>
     </c>
     <c>
      206f
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Conversion-Prohibited">Conversion Prohibited</xref>
     </c>
     <c>
      206g
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC2156"/>, 5.3.6
     </c>
     <c>
      Conversion
     </c>
     <c>
      <xref target="Conversion-Prohibition-Loss">Conversion Prohibition in Case of Loss of Information</xref>
     </c>
     <c>
      206h
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC2156"/>, 5.3.6
     </c>
     <c>
      Conversion-With-Loss
     </c>
     <c>
      <xref target="Cross-Referencing-Indication">Cross Referencing Indication</xref>
     </c>
     <c>
      206i
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC5322"/>, 3.6.4
     </c>
     <c>
      References
     </c>
     <c>
      <xref target="Deferred-Delivery">Deferred Delivery</xref>
     </c>
     <c>
      206j
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC4865" />, 3.6.4
     </c>
     <c>
      HOLDUNTIL
     </c>
     <c>
      <xref target="Deferred-Delivery-Cancellation">Deferred Delivery Cancellation</xref>
     </c>
     <c>
      206k
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Delivery-Notification">Delivery Notification</xref>
     </c>
     <c>
      206l
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC3461"/>, 4.1
     </c>
     <c>
      NOTIFY=SUCCESS
     </c>
     <c>
      <xref target="Designation-of-Recipient">Designation of Recipient by Directory Name</xref>
     </c>
     <c>
      206m
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Disclosure-of-Other">Disclosure of Other Recipients</xref>
     </c>
     <c>
      206n
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="DL-Expansion-History-Indication">DL Expansion History Indication</xref>
     </c>
     <c>
      206o
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="DL-Expansion-Prohibited">DL Expansion Prohibited</xref>
     </c>
     <c>
      206p
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Expiry-Date-Indication">Expiry Date Indication</xref>
     </c>
     <c>
      206q
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC2156"/>, 2.3.1.2
     </c>
     <c>
      Expires
     </c>
     <c>
      <xref target="Explicit-Conversion">Explicit Conversion</xref>
     </c>
     <c>
      206r
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Forwarded-MM-Indication">Forwarded MM Indication</xref>
     </c>
     <c>
      206s
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC2046"/>, 5.2
     </c>
     <c>
      Content-Type: message/rfc822
     </c>
     <c>
      <xref target="Grade-Of-Delivery-Selection">Grade of Delivery Selection</xref>
     </c>
     <c>
      206t
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC6758"/>
     </c>
     <c>
      MT-Priority
     </c>
     <c>
      <xref target="Hold-For-Delivery">Hold for Delivery</xref>
     </c>
     <c>
      206u
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Incomplete-Copy-Indication">Incomplete Copy Indication</xref>
     </c>
     <c>
      206v
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC2156"/>, 2.3.1.2
     </c>
     <c>
      Incomplete-Copy
     </c>
     <c>
      <xref target="Language-Indication">Language Indication</xref>
     </c>
     <c>
      206w
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC3282"/>, 2
     </c>
     <c>
      Content-Language
     </c>
     <c>
      <xref target="Latest-Delivery-Designation">Latest Delivery Designation</xref>
     </c>
     <c>
      206x
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC2852"/>, 4
     </c>
     <c>
      BY
     </c>
     <c>
      <xref target="Multi-Destination-Delivery">Multi-destination Delivery</xref>
     </c>
     <c>
      206y
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC5321"/>, 2.1
     </c>
     <c>
      RCPT TO
     </c>
     <c>
      <xref target="Multi-Part-Body">Multi-part Body</xref>
     </c>
     <c>
      206z
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC2046"/>, 25.1.3
     </c>
     <c>
      Content-Type: multipart/mixed
     </c>
     <c>
      <xref target="Non-Receipt-Notification-Request-Indication">Non-receipt Notification Request Indication</xref>
     </c>
     <c>
      206aa
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC3798"/>, 2.1
     </c>
     <c>
      Disposition-Notification-To
     </c>
     <c>
      <xref target="Obsoleting-Indication">Obsoleting Indication</xref>
     </c>
     <c>
      206ab
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC2156"/>, 2.3.1.2
     </c>
     <c>
      Supersedes
     </c>
     <c>
      <xref target="Originator-Indication">Originator Indication</xref>
     </c>
     <c>
      206ac
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC5322"/>, 3.6.2
     </c>
     <c>
      Sender
     </c>
     <c>
      <xref target="Originator-Requested-Alternate-Recipient">Originator Requested Alternate Recipient</xref>
     </c>
     <c>
      206ad
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Prevention-Of-Non-Delivery-Notification">Prevent of Non-delivery Notification</xref>
     </c>
     <c>
      206ae
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC3461"/>, 4.1
     </c>
     <c>
      NOTIFY=NEVER
     </c>
     <c>
      <xref target="Primary-And-Copy-Recipients-Indication">Primary and Copy Recipients Indication</xref>
     </c>
     <c>
      206af
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC5322"/>, 3.6.3
     </c>
     <c>
      To, Cc
     </c>
     <c>
      <xref target="Receipt-Notification-Request-Indication">Receipt Notification Request Indication</xref>
     </c>
     <c>
      206ag
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC3798"/>, 2.1
     </c>
     <c>
      Disposition-Notification-To
     </c>
     <c>
      <xref target="Redirection-Disallowed-By-Originator">Redirection Disallowed By Originator</xref>
     </c>
     <c>
      206ah
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Redirection-Of-Incoming-Messages">Redirection of Incoming Messages</xref>
     </c>
     <c>
      206ai
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="RFC5228"/>, 4.2? Maybe?
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Reply-Request-Indication">Reply Request Indication</xref>
     </c>
     <c>
      206ab
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="RFC5322"/> - no requesting mechanism
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Replying-MM-Indication">Replying MM Indication</xref>
     </c>
     <c>
      206ak
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC2156"/>, 3.6.4
     </c>
     <c>
      In-Reply-To
     </c>
     <c>
      <xref target="Requested-Preferred-Delivery-Method">Requested Preferred Delivery Method</xref>
     </c>
     <c>
      206al
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Subject-Indication">Subject Indication</xref>
     </c>
     <c>
      206am
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC2156"/>, 3.6.5
     </c>
     <c>
      Subject
     </c>
     <c>
      <xref target="Use-Of-Distribution-List">Use of Distribution List</xref>
     </c>
     <c>
      206an
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Primary-Precedence">Primary Precedence</xref>
     </c>
     <c>
      212a
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC6477"/>, 3.8
     </c>
     <c>
      MMHS-Primary-Precedence
     </c>
     <c>
      <xref target="Copy-Precedence">Copy Precedence</xref>
     </c>
     <c>
      212b
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC6477"/>, 3.9
     </c>
     <c>
      MMHS-Copy-Precedence
     </c>
     <c>
      <xref target="Message-Type">Message Type</xref>
     </c>
     <c>
      212c
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC6477"/>, 3.10
     </c>
     <c>
      MMHS-Message-Type
     </c>
     <c>
      <xref target="Exempted-Addresses">Exempted Addresses</xref>
     </c>
     <c>
      212d
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC6477"/>, 3.1
     </c>
     <c>
      MMHS-Exempted-Address
     </c>
     <c>
      <xref target="Extended-Authorization-Info">Extended Authorization Info</xref>
     </c>
     <c>
      212e
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC6477"/>, 3.2
     </c>
     <c>
      MMHS-Extended-Authorisation-Info
     </c>
     <c>
      <xref target="Distribution-Code">Distribution Code</xref>
     </c>
     <c>
      212f
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC6477"/>, 3.3
     </c>
     <c>
      MMHS-Subject-Indicator-Codes
     </c>
     <c>
      <xref target="Message-Instructions">Message Instructions</xref>
     </c>
     <c>
      212g
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC6477"/>, 3.5
     </c>
     <c>
      MMHS-Message-Instructions
     </c>
     <c>
      <xref target="Clear-Service">Clear Service</xref>
     </c>
     <c>
      212h
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC2634"/>, 3 and <xref target="RFC7444"/>
     </c>
     <c>
      eSSSecurityLabel, SIO-Label
     </c>
     <c>
      <xref target="Other-Recipient-Indicator">Other Recipient Indicator</xref>
     </c>
     <c>
      212i
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC6477"/>, 3.11 3.12
     </c>
     <c>
      MMHS-Other-Recipient-Indicator-To, MMHS-Other-Recipients-Indicator-CC
     </c>
     <c>
      <xref target="Originator-Reference">Originator Reference</xref>
     </c>
     <c>
      212j
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC6477"/>, 3.7
     </c>
     <c>
      MMHS-Originator-Reference
     </c>
     <c>
      <xref target="Use-Of-Address-List">Use of Address List</xref>
     </c>
     <c>
      212k
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Handling-Instructions">Handling Instructions</xref>
     </c>
     <c>
      213a
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC6477"/>, 3.4
     </c>
     <c>
      MMHS-Handling-Instructions
     </c>
     <c>
      <xref target="Pilot-Forwarded">Pilot Forwarded</xref>
     </c>
     <c>
      213b
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Corrections">Corrections</xref>
     </c>
     <c>
      213c
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="ACP-127-Message-Identifier">ACP 127 Message Identifier</xref>
     </c>
     <c>
      213d
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC6477"/>, 3.13
     </c>
     <c>
      MMHS-Acp127-Message-Identifier
     </c>
     <c>
      <xref target="Originator-PLAD">Originator PLAD</xref>
     </c>
     <c>
      213e
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC6477"/>, 3.14
     </c>
     <c>
      MMHS-Originator-PLAD
     </c>
     <c>
      <xref target="Codress-Message-Indicator">Codress Message Indicator</xref>
     </c>
     <c>
      213f
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC6477"/>, 3.6
     </c>
     <c>
      MMHS-Codress-Message-Indicator
     </c>
     <c>
      <xref target="ACP-127-Notification-Request">ACP 127 Notification Request</xref>
     </c>
     <c>
      213g
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="ACP-127-Notification-Response">ACP 127 Notification Response</xref>
     </c>
     <c>
      213h
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      N/A
     </c>
     <c>
      <xref target="Access-Control">Access Control</xref>
     </c>
     <c>
      Annex B, 7.1
     </c>
     <c>
      MAY
     </c>
     <c>
      TBD
     </c>
     <c>
      TBD
     </c>
     <c>
      <xref target="Authentication-Of-Origin">Authentication of Origin</xref>
     </c>
     <c>
      Annex B, 7.2
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC5652"/>, 5
     </c>
     <c>
      SignedData
     </c>
     <c>
      <xref target="Non-Repudiation-Of-Origin">Non-repudiation of Origin</xref>
     </c>
     <c>
      Annex B, 7.3
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC5652"/>, 5
     </c>
     <c>
      SignedData
     </c>
     <c>
      <xref target="Message-Integrity">Message Integrity</xref>
     </c>
     <c>
      Annex B, 7.4
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC5652"/>, 5
     </c>
     <c>
      SignedData
     </c>
     <c>
      <xref target="Message-Data-Separation">Message Data Separation</xref>
     </c>
     <c>
      Annex B, 7.5
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC5652"/>, 6
     </c>
     <c>
      EnvelopedData
     </c>
     <c>
      <xref target="Security-Labels">Security Labels</xref>
     </c>
     <c>
      Annex B, 7.6
     </c>
     <c>
      MUST
     </c>
     <c>
      <xref target="RFC2634"/>, 3 and <xref target="RFC7444"/>
     </c>
     <c>
      ESSSecurityLabel, SIO-Label
     </c>
     <c>
      <xref target="Non-Repudiation-Of-Receipt">Non-repudiation of Receipt</xref>
     </c>
     <c>
      Annex B, 7.7
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC2634"/>, 2
     </c>
     <c>
      ReceiptRequest
     </c>
     <c>
      <xref target="Secure-Mailing-Lists">Secure Mailing Lists</xref>
     </c>
     <c>
      Annex B, 7.8
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC2634"/>, 4
     </c>
     <c>
      MLExpansionHistory
     </c>
     <c>
      <xref target="Message-Counter-Signature">Message Counter Signature</xref>
     </c>
     <c>
      Annex B, 7.9
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC5652"/>, 11.4
     </c>
     <c>
      counterSignature
     </c>
     <c>
      <xref target="Certificate-Binding">Certificate Binding</xref>
     </c>
     <c>
      Annex B, 7.10
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC2634"/>,
     </c>
     <c>
      SigningCertificate
     </c>
     <c>
      <xref target="Compressed-Data">Compressed Data</xref>
     </c>
     <c>
      Annex B, 7.11
     </c>
     <c>
      MAY
     </c>
     <c>
      <xref target="RFC3274"/>
     </c>
     <c>
      CompressedData
     </c>
     <!--
		<postamble></postamble>
    -->
    </texttable>
   </section>

   <section title="Basic Elements of Service" anchor="Basic-Elements-of-Service">
    <section title="Access Management" anchor="Access-Management">
     <t>
      This element of service enables an Mail User Agent and an Mail Transfer Agent to establish access and manage information associated with access establishment. This includes the ability to identify and validate the identity of the other.
     </t>
     <t>
      <!--////Add UTA drafts references as appropriate-->
      Strong authentication in the bind operation is mandatory. Strong authentication MUST be supported using SMTP Extension for Authentication <xref target="RFC4954"/> and SMTP Extension for Secure SMTP over TLS <xref target="RFC3207"/>.
     </t>
     <t>
      While the list of recommended authentication mechanisms used with SMTP Extension for Authentication would depend on operating environment
      and would change over time, some recommendations are provided here.
      For environment using X.509 certificates, use of SASL EXTERNAL <xref target="RFC4422"/> authentication mechanism is RECOMMENDED.
      For environment using Kerberos, use of SASL GSSAPI <xref target="RFC4752"/> authentication mechanism is RECOMMENDED.
      Support for SCRAM <xref target="RFC5802"/> is RECOMMENDED for environment using password based authentication.
     </t>
    </section>
    <section title="Content Type Indication" anchor="Content-Type-Indication">
     <t>
      This element of service enables an originating Mail User Agent to indicate the type of each submitted message. In most cases, the content type can be determined from the header fields that are present.
     </t>
     <t>
      A Military Message MUST be indicated using the MMHS-Extended-Authorization-Info header field defined in <xref target="RFC6477"/>.
     </t>
     <t>
      Note that the Content Type Indication element of service is not supported by the MIME Content-Type header field  defined in <xref target="RFC2045"/>, even though they have a similar name.
      The MIME Content-Type header field is to describe only the data contained in the body of the message, and not the whole message itself.
     </t>
    </section>
    <section title="Converted Indication" anchor="Converted-Indication">
     <t>
      This element of service indicates to each recipient UA (i.e., on per-recipient basis) that the performed conversion on the Encoded Information Types (EITs) within a delivered message.
     </t>
     <t>
      Security requirements and mechanisms may not allow conversion to take place within the MMHS.
     </t>
     <t>
      However, messages entering the MMHS from a gateway (e.g., a civilian X.400 domain, an ACP 127 tactical gateway) may carry the converted indication.
     </t>
     <t>
      The Converted Indication, if present, MUST use the X400-Received header field as defined in <xref target="RFC2156"/>.
     </t>
    </section>
    <section title="Delivery Time Stamp Indication" anchor="Delivery-Time-Stamp-Indication">
     <t>
      This element of service indicates to each recipient Mail User Agent (i.e., on a per-recipient basis), the date and time at which the Mail Transfer Agent delivered a message.
     </t>
     <t>
      The delivery time stamp MUST be determined from the first Received header field, defined in <xref target="RFC5322"/>, present in the message.
     </t>
    </section>
    <section title="MM Identification" anchor="MM-Identification">
     <t>
      This element of service enables cooperating Mail User Agents to convey a globally unique identifier for each Military Message sent or received. This identifier is used in subsequent messages to identify the original Military Message.
     </t>
     <t>
      A Military Message MUST be uniquely identified using the Message-ID header field defined in <xref target="RFC5322"/>.
     </t>
    </section>
    <section title="Message Identification" anchor="Message-Identification">
     <t>
      This element of service is used by Mail User Agents and the Mail Transfer Agents to refer to a previously submitted message in connection with other elements of service such as delivery and non-delivery notification.
     </t>
     <t>
      Message Identification MUST be specified by the Mail User Agent using the ENVID parameter, as defined in <xref target="RFC3461"/>. The Mail Transfer Agent MUST return the message identification in the Original-Envelope-Id field of a message/delivery status as defined in <xref target="RFC3461"/>.
     </t>
    </section>
    <section title="Non-delivery Notification" anchor="Non-Delivery-Notification">
     <t>
      This element of service allows a Mail User Agent to ask for the MTS to notify the originator if a submitted message was not delivered to the specified recipient Mail User Agent. The MMHS must, with a high degree of certainty, deliver a message to the intended recipient(s). If the system cannot deliver a message within a determined period of time , a non-delivery report will be returned to the originating Mail User Agent by the MMHS. The non-delivery report contains information to enable it to be mapped to the appropriate message (i.e., the message identification), recipient information, as well as information about why the message could not be delivered.
     </t>
     <t>
      Non-Delivery notifications MUST be generated in accordance with <xref target="RFC3461"/>.
     </t>
    </section>
    <section title="Original Encoded Information Types" anchor="Original-Encoded-Information-Types">
     <t>
      This element of service enables the originating Mail User Agent to indicate the various formats of the bodyparts of a message.
     </t>
     <t>
      The Original Encoded Information Types, if present, MUST use the Original-Encoded-Information-Types header field as defined in <xref target="RFC2156"/>.
     </t>
    </section>
    <section title="Submission Time Stamp Indication" anchor="Submission-Time-Stamp-Indication">
     <t>
      This element of service enables the Message Transfer Agent to indicate to the originating Mail User Agent and each recipient Mail User Agent the date and time at which is which was submitted to the Message Transfer Agent.
     </t>
     <t>
      The Submission Time Stamp Indication MUST be determined from the last Received header field, as defined in <xref target="RFC5322"/>, present in the message.
      Note that this is distinct from the Date header field, defined in <xref target="RFC5322"/>, which is more likely to be displayed by a receiving Mail User Agent but which indicates the date and time at which the originator of the message indicated that the message was complete and ready to submitted.
     </t>
    </section>
    <section title="Typed Body" anchor="Typed-Body">
     <t>
      <!--////Not sure what this mean!-->
      This element of service allows the nature and attributes of the body of the message to be conveyed along with the body.
     </t>
     <t>
      The MMHS MUST support this element of service whereby:
      <list style="symbols">
       <t>
        A Mail User Agent MUST support Multipurpose Internet Mail Extensions (MIME) <xref target="RFC2045"/>, <xref target="RFC2046"/>, <xref target="RFC2047"/>, <xref target="RFC2049"/>, <xref target="RFC2231"/> and <xref target="RFC3676"/>; and,
       </t>
       <t>
        A Mail Submission Agent MUST support SMTP Extension for 8-bit MIME transport <xref target="RFC6152"/>.
       </t>
      </list>
     </t>
    </section>
    <section title="User/UA Capabilities Registration" anchor="User-UA-Capabilities-Registration">
     <t>
      This element of service enables a MUA to indicate to the MMHS unrestricted use of any or all of the following capabilities with respect to received messages:
      <list style="symbols">
       <t>
        the content type(s) of messages it is willing to accept;
       </t>
       <t>
        the maximum content length of a message it is willing to accept; and
       </t>
       <t>
        the Encoded Information Type(s) of messages it is willing to accept.
       </t>
      </list>
     </t>
     <t>
      There is no current SMTP service that supports this element of service. Therefore this profile does not support this element of service.
     </t>
     <t>
      However, this element of service MAY be supported by MUAs and other MMHS components that provide proprietary mechanisms (i.e Directory Services).
     </t>
    </section>
   </section>
   <section title="Optional Elements of Service" anchor="Optional-Elements-of-Service">
    <section title="Alternate Recipient Allowed" anchor="Alternate-Recipient-Allowed">
     <t>
      This element of service enables an originating Mail User Agent to specify that the message being submiited can be redirected to an alternate recipient. Unless an originator specifically request that an alternate recipient be disallowed, all Military Messages will indicate that an alternate recipient is allowed.
     </t>
     <t>
      There is no current SMTP service that supports allows the originator to disallow the redirection of a message to an alternate recipient. Therefore this profile does not support the Alternate Recipient Allowed element of service.
      <!--[[ We could refer to MIXER field to allow control within X.400 domains, even though not supported within SMTP domains?]]-->
     </t>
    </section>
    <section title="Alternate Recipient Assignment" anchor="Alternate-Recipient-Assignment">
     <t>
      This element of service enables a receiving Mail User Agent to be given the capability to have certain messages delivered to it for which there is not an exact match between the recipient address specified in the message and the valid addresses within the recipient domain. This service allows a message that would otherwise be undeliverable to be delivered to a "default mailbox" within the recipient domain.
     </t>
     <t>
      There is no current SMTP service that supports allows the Alternate Recipient Assignment element of service. Therefore this profile does not support the Alternate Recipient Assignment element of service. Note that some Mail Transfer Agent products may provide propriertary mechanisms that support the element of service.
     </t>
    </section>
    <section title="Authorizing Users Indication" anchor="Authorizing-Users-Indication">
     <t>
      This element of service allows the originator to indicate to the recipient the names or one or more persons who authorized the sending of the messages.
     </t>
     <t>
      The Authorizing Users Indication element of service MUST be conformant with the Draft and Release using Internet Email specification <xref target="I-D.melnikov-mmhs-authorizing-users"/>. In addition, the Sender header field as defined in <xref target="RFC5322"/> (carrying the Originator Indication) MUST also be present in accordance with <xref target="RFC2156"/>.
     </t>
    </section>
    <section title="Auto-forwarded Indication" anchor="Auto-Forwarded-Indication">
     <t>
      This element of service allows a recipient to determine that the body of an incoming Military Message contains a Military Message that has been auto-forwarded by an autonomous Mail Submission Agent. This is used to distinguish the incoming Military Message that contains a Military Message that was manually forwarded by the original recipient. If automatic forwarding of Military Messages is supported by a Mail Submission Agent, then the Auto-forwarded Indication MUST be supported on origination.
     </t>
     <!--////Sadly, Sieve implementations don't add this - so do we want to change this to not supported.-->
     <t>
      The Auto-forwared Indication MUST use the Autoforwarded header field, as defined in <xref target="RFC2156"/>.
     </t>
    </section>
    <section title="Blind Copy Recipient Indication" anchor="Blind-Copy-Recipient-Indication">
     <t>
      This element of service enable the originator to  provide the address of one or more additional intended recipients of the message being sent. These names are not disclosed to the primary, copy or other blind copy recipients. This service can be used to keep some recipient names and addressed hidden from other recipients. This service can be used to send a courtesy copy to drafters or reviewers of a message, when internal information, such as who drafted or reviewed the message, is not to be disclosed to the recipient(s).
      Separate copies of the mesage MUST be submitted to the Mail Transfer Agent for the open recipients (primary and copy recipients) and for each blind copy recipient. The messages sent to each of blind copy recipients MUST contain same MM Identification as the message sent to the open recipients.
     </t>
     <t>
      The Blind Copy Recipient Indication MUST use the Bcc header field, as defined in <xref target="RFC5322"/>.
     </t>
    </section>
    <section title="Body Part Encryption Indication" anchor="Body-Part-Encryption-Indication">
     <t>
      This element of service allows the originator to indicate to the recipient that a particular body of the message has been sent encrypted.
     </t>
     <t>
      There is no current SMTP service that supports allows the Body Part Encryption Indication element of service. Therefore this profile does not support the Body Part Encryption Indication element of service.
     </t>
    </section>
    <section title="Conversion Prohibited" anchor="Conversion-Prohibited">
     <t>
      This element of service enables an originating Mail User Agent to instruct the Mail Transfer Agent that the implicit conversion of the military message should not be performed.
     </t>
     <t>
      This element of service is not supported by an SMTP Mail Transfer Agent. A Mail User Agent MAY use the Conversion header field, as defined in <xref target="RFC2156"/> to control the conversion to an X.400 message at a MIXER gateway and further within the X.400 domain at X.400 Mail Transfer Agents.
     </t>
    </section>
    <section title="Conversion Prohibition in Case of Loss of Information" anchor="Conversion-Prohibition-Loss">
     <t>
      This element of service enables and originating Mail User Agent to instruct the Mail Transfer Agent that the implicit conversion of the military message should not be performed, if such conversion would result in the loss of information.
     </t>
     <t>
      This element of service is not supported by an SMTP Mail Transfer Agent. A Mail User Agent MAY use the Conversion-With-Loss header field, as defined in <xref target="RFC2156"/> to control the conversion to an X.400 message at a MIXER gateway and further within the X.400 domain at X.400 Mail Transfer Agents.
     </t>
    </section>
    <section title="Cross Referencing Indication" anchor="Cross-Referencing-Indication">
     <t>
      This element of service allows the originator to associate the globally unique identifiers of one or more other messages with the message being sent. This enables the recipient's Mail User Agent, for example, to retrieve a copy of the referenced messages.
     </t>
     <t>
      The Cross Referencing Indication MUST use the References header field, as defined in <xref target="RFC5322"/>.
     </t>
    </section>
    <section title="Deferred Delivery" anchor="Deferred-Delivery">
     <t>
      This element of service enables an originating Mail User Agent to instruct the Mail Transfer Agent that a military message being submitted shall be delivered no sooner than a specified date and time. When this service is requested, it MUST be logged for audit and tracing purposes.
     </t>
     <t>
      Deferred Delivery MUST be specified in accordance with <xref target="RFC4865"/>.
     </t>
    </section>
    <section title="Deferred Delivery Cancellation" anchor="Deferred-Delivery-Cancellation">
     <t>
      This element of service enables an orginating MUA to instruct the MTA to cancel a previously submitted military message that contained a Deferred Delivery date and time.
     </t>
     <t>
      Deferred Delivery Cancellation is not supported by this profile.
     </t>
    </section>
    <section title="Delivery Notification" anchor="Delivery-Notification">
     <t>
      This element of service enables the originating MUA to request that the originating MUA be explicitly notified when a submitted military message has been successfully delivered to a recipient MUA. This notification is conveyed by a delivery report. The delivery report is related to the submitted message by means of a message identifier and includes the date and time of delivery. Receipt of a delivery report at the originating MUA results in the the generation of a delivery notification to the originator. In the case of multi-destination military messages, this service shall be selectable on a per recipient basis.
     </t>
     <t>
      This element of service MUST be supported using the NOTIFY parameter of the ESMTP RCPT command with as value of SUCCESS, as defined in <xref target="RFC3461"/>.
     </t>
     <t>
      Note that while this element of service is selectable on a per recipient basis, an MUA MAY only allow it to be selected on a per message basis.
     </t>
    </section>
    <section title="Designation of Recipient by Directory Name" anchor="Designation-of-Recipient">
     <t>
      This element of service enables an originating UA to use, on a per-recipient basis, a directory name in place of an individual recipient's address. This implies the support of a directory service. The directory name must be translated to an email address for delivery to take place. However, the directory lookup may take place at the MTA rather than at the MUA.
     </t>
     <t>
      Designation of Recipient by Directory Name is not suppoted by this profile.
     </t>
     <t>
      However the designation of a recipient by a directory name MAY be supported by a MUA that can retrieve an address from a directory service.
     </t>
    </section>
    <section title="Disclosure of Other Recipients" anchor="Disclosure-of-Other">
     <t>
      This element of service enables the originating MTA to instruct the MTS to disclose the address of all other recipient of a multi-recipient military message to each recipient MUA, upon delivery of the message. The addresses disclosed are as supplied by the originating MUA or the results of address list expansion.
     </t>
     <t>
      Disclosure of Other Recipients is not supported by this profile.
     </t>
    </section>
    <section title="DL Expansion History Indication" anchor="DL-Expansion-History-Indication">
     <t>
      This element of service provides information to a recipient about the DL(s) that resulted in the message being delivered to this recipient. This element of service also provides a mechanism to protect against potential nested DL looping.
     </t>
     <t>
      DL Expansion History Indication is not supported by this profile.
     </t>
     <t>
      The DL-Expansion-History header defined in <xref target="RFC2156"/> SHALL NOT be used. DL-Expansion-History header MAY be present in messages gatewayed from X.400.
     </t>
    </section>
    <section title="DL Expansion Prohibited" anchor="DL-Expansion-Prohibited">
     <t>
      This element of service allows an originating user to specify that if any of the recipient names can directly, or by reassignment, refer to a distribution, then no expansion of the distribution shall occur. Instead, a non-delivery notification shall be returned to the originating Mail User Agent.
     </t>
     <t>
      DL Expansion Prohibited is not supported by this profile.
     </t>
    </section>
    <section title="Expiry Date Indication" anchor="Expiry-Date-Indication">
     <t>
      This element of service allows the originator to indicate to the recipient the date and time after which the message is considered invalid. The intent of this element of service is to state the originator's assessment of the current applicability of a message. If the Expiry Date Indication is present, it shall be displayed to the recipients(s) to indicate the time after which this message should be longer be acted upon. It is left to the discretion of the recipient as to whether or not the message is discarded.
     </t>
     <!--DELIVERBY SMTP extension is used to satisfy another requirement.-->
     <t>
      The Expiry Date Indication element of service SHALL use the Expires header field, as defined in <xref target="RFC2156"/>.
     </t>
    </section>
    <section title="Explicit Conversion" anchor="Explicit-Conversion">
     <t>
      This element of service enables an originating MUA to request, on a per-recipient basis, that the MTA perform a specified Encoded Information Type conversion.
     </t>
     <t>
      Explicit Conversion is not supported by this profile.
     </t>
    </section>
    <section title="Forwarded MM Indication" anchor="Forwarded-MM-Indication">
     <t>
      This element of service allows a message, plus its delivery information to be sent as a body part inside another message. In a multi-part body the forwarded message may be one of serveral body parts of various types.
     </t>
     <t>
      The Forwarded MM Indication element of service, if supported by the MMHS, SHALL use the Content-Type header field, as defined in <xref target="RFC2045"/> with the value "message/rfc822" and use the Content Type Indication <!--////But this is marked as unsupported?-->
      , as defined in <xref target="Content-Type-Indication"/>, within the headers of the embedded message.
     </t>
     <t>
      Note that the Content-Type header field may be embedded within an outer "multipart/mixed" MIME body where, for example, the fowarding Military Message also includes delivery information, covering text or additional attachments.
     </t>
    </section>
    <section title="Grade of Delivery Selection" anchor="Grade-Of-Delivery-Selection">
     <t>
      This element of service enables an originating MUA to request that transfer through the MMHS take place at a selected priority. The time periods defined for each grade of delivery must be specified in an organisation (or domain) policy and bilaterally agreed between participating organisations (or domains).
     </t>
     <t>
      The Grade of Delivery Selection element of service MUST be supported by the MMHS, using the MT-Priority header field, as defined in <xref target="RFC6758"/>.
     </t>
     <t>
      The Grade of Delivery Selection MT-Priority header field value MUST be derived from the Primary Precedence (<xref target="Primary-Precedence"/>) MMHS-Primary-Precedence <xref target="RFC6477"/> header field value.
     </t>
     <t>
      The MMHS message may have no primary recipients (therefore no Primary Precedence); the Grade of Delivery Selection MT-Priority header field value MUST be derived from the Copy Precedence (<xref target="Copy-Precedence"/>) MMHS-Copy-Precedence <xref target="RFC6477"/> header field value.
     </t>
     <t>
      The mapping between the Grade of Delivery Selection MT-Priority header field values and the Primary Precedence MMHS-Primary-Precedence header field values (and subsequently the Copy Precedence MMHS-Copy-Precedence header field values) MUST support the "STANAG4406" Priority Assignment Policy specified in <xref target="RFC6758"/> Appendix A.
     </t>
     <t>
      The Grade of Delivery Selection MT-Priority doesn't have to be displayed to the recipient by the MUA, as an indication of the Grade of Delivery selection element of service is provided to the recipient MUA by the Primary and Copy Precedence.
     </t>
    </section>
    <section title="Hold for Delivery" anchor="Hold-For-Delivery">
     <t>
      This element of service enables a recipient MUA to request that the MTA hold its MMHS messages and returning notifications for delivery until a later time. The MUA can indicate to the MTA when it is unavailable to take delivery of messages and notifications, and also, when it is again ready to accept delivery of messages and notifications from the MTA. The MTA can indicate to the MUA that messages are waiting due to the criteria the MUA established for holding messages. The MMHS message will be held until the maximum delivery time for that MMHS message expires, unless the recipient releases the hold prior to its expiry.
     </t>
     <t>
      There is no current SMTP service that supports the Hold for Delivery element of service. Therefore this profile does not support this element of service.
     </t>
     <t>
      <!--////Additionally, an IMAP mailbox can be used for holding messages pending submission-->
      However, this element of service MAY be partially supported by MTA products that provide proprietary mechanisms to schedule delivery times based on MMHS message size and MMHS message priority.
     </t>
    </section>
    <section title="Incomplete Copy Indication" anchor="Incomplete-Copy-Indication">
     <t>
      This element of service allows an originator to indicate that this MMHS message is an incomplete copy of a MMHS message with the same Message-ID header field in that one or more body parts or header fields of the original MMHS message are absent.
     </t>
     <t>
      The Incomplete Copy Indication element of service MAY be supported by the MMHS, using the Incomplete-Copy header field, as defined in <xref target="RFC2156"/>.
     </t>
    </section>
    <section title="Language Indication" anchor="Language-Indication">
     <t>
      This element of service enables an originating MUA to indicate the language type(s) of a submitted message.
     </t>
     <t>
      The Language Indication element of service MAY be supported by the MMHS, using the Content-Language header field, as defined in <xref target="RFC3282"/>.
     </t>
    </section>
    <section title="Latest Delivery Designation" anchor="Latest-Delivery-Designation">
     <t>
      This element of service enables an originating MUA to specify the latest time by which the MMHS message is to be delivered. If the MTA cannot deliver by the time specified, the MMHS message is canceled and a non-delivery report returned to the originating MUA.
     </t>
     <t>
      The Latest Delivery Designation element of service MUST be supported by the MMHS as defined in the Deliver By SMTP extension <xref target="RFC2852"/>.
     </t>
    </section>
    <section title="Multi-destination Delivery" anchor="Multi-Destination-Delivery">
     <t>
      This element of service allows an originating MUA to specify that a message being submitted is to be delivered to more than one recipient MUA. This does not imply simultaneous delivery to all specified recipient MUAs.
     </t>
     <t>
      The Multi-destination Delivery element of service is supported by the SMTP RCPT command as defined in <xref target="RFC5321"/>.
     </t>
    </section>
    <section title="Multi-part Body" anchor="Multi-Part-Body">
     <t>
      This element of service allows an originator to send a message that is partitioned into several parts. The nature and attributes, or type, of each body part are conveyed along with the body part. This enables the multiple parts to be of different encoded information types.
     </t>
     <t>
      The MMHS MUST support this element of service whereby:
      <list style="symbols">
       <t>
        A Mail User Agent MUST support Multipurpose Internet Mail Extensions (MIME) <xref target="RFC2045"/>, <xref target="RFC2046"/>, <xref target="RFC2047"/>, <xref target="RFC2049"/> and <xref target="RFC2231"/>; and,
       </t>
       <t>
        A Mail Submission Agent MUST support SMTP Extension for 8-bit MIME transport <xref target="RFC6152"/>.
       </t>
      </list>
     </t>
    </section>
    <section title="Non-receipt Notification Request Indication" anchor="Non-Receipt-Notification-Request-Indication">
     <t>
      This element of service allows the originator to ask, on a per-recipient basis, for notification if the MMHS message is deemed unreceivable by any of the recipients.
     </t>
     <t>
      The Non-Receipt Notification Request Indication MUST be supported by the MMHS, using the Disposition-Notification-To header field as defined in <xref target="RFC3798"/>.
     </t>
     <t>
      In the case where the Non-Receipt Notification Request Indication element of service is required for a subset of the recipients the MSA MUST: submit a MMHS message to those recipients that a non-receipt notification is requested with a Disposition-Notification-To header field; and, submit a MMHS message(s) to those recipients that a non-receipt notification is not requested without a Disposition-Notification-To header field.
     </t>
     <t>
      Note that while this element of service is selectable on a per recipient basis, an MUA MAY only allow it to be selected on a per message basis.
     </t>
     <t>
      Note that this element of service will be supported in conjunction with the Receipt Notification Request Indication as profiled in <xref target="Receipt-Notification-Request-Indication"/>.
     </t>
    </section>
    <section title="Obsoleting Indication" anchor="Obsoleting-Indication">
     <t>
      This element of service allows the originator to indicate to the recipient that one or more previously sent MMHS messages are obsolete. The intention of this element of service is for the MUA to display to the user reading the original MMHS message that the original MMHS message is obsolete. It is the responsibility of the user for discarding the original MMHS message.
     </t>
     <t>
      The Obsoleting Indication element of service MAY be supported by the MMHS, using the Supersedes header field, as defined in <xref target="RFC2156"/>.
     </t>
    </section>
    <section title="Originator Indication" anchor="Originator-Indication">

     <t>
      The Originator Indication MUST use the MMHS-Authorizing-Users header field, as defined in <xref target="I-D.melnikov-mmhs-authorizing-users"/>, when the Authorizing Users Indication is present in the message and the Sender header field, as defined in <xref target="RFC5322"/>, when the Authorizing Users Indication is not present in the message.
     </t>
     <t>
      This conditional use of different header fields is required to support interoperability with <xref target="ACP123"/> and <xref target="STANAG-4406"/> X.400 systems that utilise a MIXER compliant gateway, <xref target="RFC2156"/>.
     </t>

    </section>
    <section title="Originator Requested Alternate Recipient" anchor="Originator-Requested-Alternate-Recipient">
     <t>
      This element of service enables the originating MUA to specify, for each intended recipient, one alternate recipient to whom the MTA can deliver the message, if delivery to the intended recipient is not possible. This service allows a MMHS message that would otherwise be delayed or non-delivered to be delivered to an alternative message recipient.
     </t>
     <t>
      There is no current SMTP service that supports the Originator Requested Alternate Recipient element of service. Therefore this profile does not support this element of service. Note that some MTAs may provide propriertary mechanisms that support this element of service. <!--ALTRECIP--> <!-- All MTAs MUST support this EoS -->
     </t>
    </section>
    <section title="Prevention of Non-delivery Notification" anchor="Prevention-Of-Non-Delivery-Notification">
     <t>
      This element of service enables an originating MUA to instruct a MTA not to return a non-delivery report to the originating MUA in the event that the message being submitted is judged undeliverable.
     </t>
     <t>
      This element of service MUST be supported by the MMHS, using the NOTIFY parameter of the ESMTP RCPT command with as value of NEVER, as defined in <xref target="RFC3461"/>.
     </t>
     <t>
      Note that while this element of service is selectable on a per recipient basis, an MUA MAY only allow it to be selected on a per message basis.
     </t>
    </section>
    <section title="Primary and Copy Recipients Indication" anchor="Primary-And-Copy-Recipients-Indication">
     <t>
      Primary and Copy recipients, within the MMHS, are known as action and information addressees, respectively. A primary recipient has a responsibility to act upon a delivered MMHS message, whereas a Copy recipient has been sent the MMHS message for information purposes only.
     </t>
     <t>
      The Primary and Copy Recipients Indication element of service MUST be supported by the MMHS, using the To and Cc header fields, respectively, as defined in <xref target="RFC5322"/>.
     </t>
    </section>
    <section title="Receipt Notification Request Indication" anchor="Receipt-Notification-Request-Indication">
     <t>
      This element of service allows the originator of a MMHS message to request, on a per-recipient basis, for notification when a particular MMHS message is received. The recipient MUA MUST prominently display the request for this element of service and permit the recipient to honour the request or reject the request.
     </t>
     <t>
      The Receipt Notification Request Indication MUST be supported by the MMHS, using the Disposition-Notification-To header field as defined in <xref target="RFC3798"/>.
     </t>
     <t>
      In the case where the Receipt Notification Request Indication element of service is required for a subset of the recipients the MUA MUST: submit a MMHS message to those recipients that a receipt notification is requested with a Disposition-Notification-To header field; and, submit a MMHS message(s) to those recipients that a receipt notification is not requested without a Disposition-Notification-To header field.
     </t>
     <t>
      Note that while this element of service is selectable on a per recipient basis, an MUA MAY only allow it to be selected on a per message basis.
     </t>
     <t>
      Note that this element of service will be supported in conjunction with the Receipt Notification Request Indication as profiled in <xref target="Non-Receipt-Notification-Request-Indication"/>.
     </t>
     <t>
      In the case where the MMHS supports S/MIME security services profiled in <xref target="Security-Services"/> the originating MUA MAY use the Non-repudiation of Receipt element of service as specified in <xref target="Non-Repudiation-Of-Receipt"/>.
     </t>
    </section>
    <section title="Redirection Disallowed by Originator" anchor="Redirection-Disallowed-By-Originator">
     <t>
      This element of service enables an originating MUA to instruct the MTA that redirection should not be applied to a particular submitted MMHS message.
     </t>
     <t>
      There is currently no SMTP service that supports this element of service. Therefore, the Redirection Disallowed by Originator element of service is not supported by this profile.
     </t>
    </section>
    <section title="Redirection of Incoming Messages" anchor="Redirection-Of-Incoming-Messages">
     <t>
      This element of service enables a MUA to instruct the MTA to redirect incoming MMHS messages addressed to it, to another MUA or to an Address List (AL), for a specified period of time, or until revoked.
     </t>
     <t>
      <!--////Sieve can be used for this.
Also update the table if we are not going to reference Sieve.-->
      There is currently no SMTP service that supports this element of service. Therefore the Redirection of Incoming Messages element of service is not supported by this profile. However, note that some MTA and/or MDA products are able to enforce a local security policy supporting this element of service with proprietary mechanisms.
     </t>
    </section>
    <section title="Reply Request Indication" anchor="Reply-Request-Indication">
     <t>
      This element of service allows the originator to request, on a per-recipient basis, that a recipient send a message in reply to the MMHS message that carries the request. The originator can also optionally specify the date by which any reply should be sent and the names of one or more users and ALs who the originator requests be included among the preferred recipients of any reply.
     </t>
     <t>
      The Reply Request Indication element of service is not supported by this profile.
     </t>
     <t>
      This element of service MAY be procedurally defined by a MMHS. Hence the Reply Request Indication MAY be supported by including the request within the body of the MMHS message.
     </t>
     <t>
      Blind Copy recipients of the MMHS message, that includes support for this element of service within the message body, SHOULD be careful to consider the recipients of the reply MMHS message honoring the Blind Copy Recipient Indication element of service profiled in <xref target="Blind-Copy-Recipient-Indication"/>.
     </t>
    </section>
    <section title="Replying MM Indication" anchor="Replying-MM-Indication">
     <t>
      This element of service allows the originator of a MMHS message to indicate to the recipients that the message is being sent in reply to another MMHS message.
     </t>
     <t>
      The Replying MM Indication element of service MAY be supported by the MMHS, using the In-Reply-To header field as defined in <xref target="RFC5322"/>.
     </t>

    </section>
    <section title="Requested Preferred Delivery Method" anchor="Requested-Preferred-Delivery-Method">
     <t>
      This element of service allows an originator to request, on a per-recipient basis, the preference of method or methods of delivery.
     </t>
     <t>
      Requested Preferred Delivery Method is not supported by this profile.
     </t>
    </section>
    <section title="Subject Indication" anchor="Subject-Indication">
     <t>
      This element of service allows the originator to indicate to the recipient(s) a user specified short description of the message.
     </t>
     <t>
      The Subject Indication element of service MAY be supported by the MMHS, using the Subject header field as defined in <xref target="RFC5322"/>.
     </t>
    </section>
    <section title="Use of Distribution List" anchor="Use-Of-Distribution-List">
     <t>
      This element of service enables an origintaing MUA to specify, on a per-recipient basis, a Distribution List in place of all the individual recipients (users or nested DLs).
      The MTA will add the member of the list to the recipients and send it to those members. Support for this service shall be optional.
      Determination of where in the MMHS the DL expansion takes place may be the subject of national policy based upon security requirements.
      National policy may also dictate the preferential support of the <xref target="Use-Of-Address-List">Use of Address List</xref> and <xref target="Exempted-Addresses">Exempted Addsresses</xref>Elements of Service instead of the Use of Distribution List Element of Service.
     </t>
     <t>
      Use of Distribution List is not supported by this profile.
     </t>
    </section>
   </section>
   <section title="Military Elements of Service" anchor="Military-Elements-of-Service">
    <t>
     This section profiles the MMHS Header Fields for use in the MMHS as specified in <xref target="RFC6477"/>.
    </t>
    <section title="Primary Precedence" anchor="Primary-Precedence">
     <t>
      The MMHS-Primary-Precedence header field defined in <xref target="RFC6477"/> MUST be supported and included by the MMHS if the military message contains "To:" ("action") addresses.
     </t>
    </section>
    <section title="Copy Precedence" anchor="Copy-Precedence">
     <t>
      The MMHS-Copy-Precedence header field defined in <xref target="RFC6477"/> MUST be supported and included by the MMHS if the military message contains "Cc:" or "Bcc:" ("information") addresses.
     </t>
    </section>
    <section title="Message Type" anchor="Message-Type">
     <t>
      The MMHS-Message-Type header field defined in <xref target="RFC6477"/> MUST be supported by the MMHS.
     </t>
    </section>
    <section title="Exempted Addresses" anchor="Exempted-Addresses">
     <t>
      The MMHS-Exempted-Address header field defined in <xref target="RFC6477"/> MAY be supported by the MMHS.
     </t>
    </section>
    <section title="Extended Authorization Info" anchor="Extended-Authorization-Info">
     <t>
      <!--////This is listed as MAY in the table-->
      The MMHS-Extended-Authorisation-Info header field defined in <xref target="RFC6477"/> MUST be supported and included by the MMHS in a military message.
     </t>
    </section>
    <section title="Distribution Code" anchor="Distribution-Code">
     <t>
      <!--////This is listed as MAY in the table-->
      The MMHS-Subject-Indicator-Codes header field defined in <xref target="RFC6477"/> MUST be supported by the MMHS.
     </t>
    </section>
    <section title="Message Instructions" anchor="Message-Instructions">
     <t>
      The MMHS-Message-Instructions header field defined in <xref target="RFC6477"/> MAY be supported by the MMHS.
     </t>
    </section>
    <section title="Clear Service" anchor="Clear-Service">
     <t>
      This element of service indicates to the recipient that the military message containing classified information has been transmitted over non-secure communications links.
      This element of service, if permitted by the security policy, MAY be supported by using the printable string "CLEAR" in the privacy mark component of the security label (see <xref target="Security-Labels"/>) along with an appropriate security policy identifier.
      If this element of service is supported by the MMHS, the MUA MUST prominently display to the user that the military message has been transmitted over non-secure communication links.
     </t>
    </section>
    <section title="Other Recipient Indicator" anchor="Other-Recipient-Indicator">
     <t>
      The MMHS-Other-Recipients-Indicator-To and MMHS-Other-Recipients-Indicator-CC header fields defined in <xref target="RFC6477"/> MAY be supported by the MMHS.
     </t>
    </section>
    <section title="Originator Reference" anchor="Originator-Reference">
     <t>
      The MMHS-Originator-Reference header field defined in <xref target="RFC6477"/> MAY be supported by the MMHS.
     </t>
    </section>
    <section title="Use of Address List" anchor="Use-Of-Address-List">
     <t>The Address List Indication element of service is not supported by this profile.</t>
    </section>
   </section>
   <section title="Transition Elements of Service">
    <section title="Handling Instructions" anchor="Handling-Instructions">
     <t>
      The MMHS-Handling-Instructions header field defined in <xref target="RFC6477"/> MAY be supported by the MMHS only to support interoperability with ACP 127 systems.
     </t>
    </section>
    <section title="Pilot Forwarded" anchor="Pilot-Forwarded">
     <t>
      The Pilot Forwarded element of service is not supported by this profile.
     </t>
    </section>
    <section title="Corrections" anchor="Corrections">
     <t>
      <!--////A new MIME type or a Content-Type parameter to text/plain can be defined in the future, if needed.-->
      The Corrections element of service is not supported by this profile.
     </t>
    </section>
    <section title="ACP 127 Message Identifier" anchor="ACP-127-Message-Identifier">
     <t>
      The MMHS-Acp127-Message-Identifier header field defined in <xref target="RFC6477"/> MAY be supported by the MMHS only to support interoperability with ACP 127 systems.
     </t>
    </section>
    <section title="Originator PLAD" anchor="Originator-PLAD">
     <t>
      The MMHS-Originator-PLAD header field defined in <xref target="RFC6477"/> MAY be supported by the MMHS only to support interoperability with ACP 127 systems.
     </t>
    </section>
    <section title="Codress Message Indicator" anchor="Codress-Message-Indicator">
     <t>
      The MMHS-Codress-Message-Indicator header field defined in <xref target="RFC6477"/> MAY be supported by the MMHS only to support interoperability with ACP 127 systems.
     </t>
    </section>
    <section title="ACP 127 Notification Request" anchor="ACP-127-Notification-Request">
     <t>The ACP 127 Notification Request element of service is not supported by this profile.</t>
    </section>
    <section title="ACP 127 Notification Response" anchor="ACP-127-Notification-Response">
     <t>The ACP 127 Notification Response element of service is not supported by this profile.</t>
    </section>
   </section>
  </section>
  <section title="Security Services" anchor="Security-Services">
   <t>
    An MMHS MAY support security services. The security services specified in this profile are based on the Secure Multipurpose Internet Mail Extensions (S/MIME) protocols and DomainKeys Identified Mail (DKIM) Signatures specified in <xref target="RFC6376"/>. The S/MIME protocols Message Specification <xref target="RFC5751"/>, Cryptographic Message Syntax <xref target="RFC5652"/> and Enhanced Security Services for S/MIME <xref target="RFC2634"/> specify a consistent way to securely send and receive MIME messages providing end to end integrity, authentication, non-repudiation and confidentiality. DKIM's primary purpose is to define an organization-level digital signature authentication framework for Internet email, using public key cryptography and using the domain name service as its key server technology. However, it is possible to administer DKIM to support user-level signature granularity. This section describes the generic security services and profiles the use of <xref target="RFC5751"/>, <xref target="RFC5652"/>, <xref target="RFC2634"/> and <xref target="RFC6376"/>.
   </t>
   <section title="General Security Elements of Service" anchor="General-Security-Elements-of-Service">
    <t>
     The general security services and implementation requirements for providing these security services for an MMHS are detailed below.
    </t>
    <section title="Access Control" anchor="Access-Control">
     <t>
      The Access Control security service provides a means of enforcing the authorization of users to originate and receive messages. Access controls are performed in each MMHS domain in accordance with the security policy in force. MMHS systems MAY enforce their own native security policies, plus any other security policies that have been bilaterally agreed.
     </t>
     <t>
      An MMHS providing the access control service MUST perform access control decisions based on comparing the sensitivity information conveyed in a security label (<xref target="Security-Labels"/>) with a user's authorizations.
     </t>
    </section>
    <section title="Authentication of Origin" anchor="Authentication-Of-Origin">
     <t>
      The Authentication of Origin security service provides assurance that the message was originated by the user indicated as the sender by digitally signing the message. However, it must be noted that the implementation of the MMHS security services is dependent upon the security and assurance requirements that are to be met by those MMHS security services. As such, the identity of the signer of the MMHS message may be the user, the role the user is performing or the organization (or domain) the user belongs to.
     </t>
     <t>
      If the MMHS provides security services it MUST support the Authentication of Origin service.
     </t>
     <t>
      The MMHS SHOULD implement this service on origination supporting the SignedData content type (profiled in <xref target="Signed-Data-CT"/>) to apply a digital signature to a MMHS message or, in a degenerate case where there is no signature information, to convey certificates.
     </t>
     <t>
      Alternatively the MMHS MAY implement this service on origination supporting DKIM (profiled in <xref target="DKIM-Signatures"/>) to apply a digital signature to a MMHS message.
     </t>
     <t>
      On reception the MMHS MUST support verification of S/MIME and DKIM digital signatures.
     </t>
    </section>
    <section title="Non-repudiation of Origin" anchor="Non-Repudiation-Of-Origin">
     <t>
      The Non-repudiation of Origin security service provides the recipient with evidence that demonstrates, to a third-party, who originated the message, and will protect against any attempt by the message originator to falsely deny having sent the message. However, it must be noted that the implementation of the MMHS security services is dependent upon the security and assurance requirements that are to be met by those MMHS security services. As such, the identity of the signer of the MMHS message may be the user, the role the user is performing or the organization (or domain) the user belongs to.
     </t>
     <t>
      If the MMHS provides security services it MUST support the Non-repudiation of Origin service.
     </t>
     <t>
      The MMHS SHOULD implement this service on origination as profiled in <xref target="Signed-Data-CT"/>.
     </t>
     <t>
      Alternatively the MMHS MAY implement this service on origination supporting DKIM (profiled in <xref target="DKIM-Signatures"/>) to apply a digital signature to a MMHS message.
     </t>
     <t>
      On reception the MMHS MUST support verification of S/MIME and DKIM digital signatures.
     </t>
    </section>
    <section title="Message Integrity" anchor="Message-Integrity">
     <t>
      The Message Integrity security service provides a method of ensuring the content that was received by the recipient(s) is the same as that which was sent by the originator. However, it must be noted that the implementation of the MMHS security services is dependent upon the security and assurance requirements that are to be met by those MMHS security services. As such, the identity of the signer of the MMHS message may be the user, the role the user is performing or the organization (or domain) the user belongs to.
     </t>
     <t>
      If the MMHS provides security services it MUST support the Message Integrity service.
     </t>
     <t>
      The MMHS SHOULD implement this service on origination as profiled in <xref target="Signed-Data-CT"/>.
     </t>
     <t>
      Alternatively the MMHS MAY implement this service on origination supporting DKIM (profiled in <xref target="DKIM-Signatures"/>) to apply a digital signature to a MMHS message.
     </t>
     <t>
      On reception the MMHS MUST support verification of S/MIME and DKIM digital signatures.
     </t>
    </section>
    <section title="Message Data Separation" anchor="Message-Data-Separation">
     <t>
      The Message Data Separation security service protects against unauthorized disclosure of the message, and separates data contained in one message from that contained in another message. This service can help to enforce need to know restrictions, or enables multiple different user communities to share the same secure network. The service is independent of the network and systems transporting the message.
     </t>
     <t>
      The MMHS MAY implement this service supporting the EnvelopedData content type (profiled in <xref target="Enveloped-Data-CT"/>) to apply privacy protection to a message. A sender needs to have access to a public key for each intended message recipient to use this service. This content type does not provide authentication.
     </t>
    </section>
    <section title="Security Labels" anchor="Security-Labels">
     <t>
      The Security Label security service provides a method for associating security labels with objects in the MMHS. This then allows a security policy to define what entities can handle messages containing associated security labels. The security label associated with a message MUST indicate the security policy to be followed along with the sensitivity, compartments, and other handling caveats associated with the message. This service can be used for purposes such as access control or a source of routing information.
     </t>
     <t>
      If the MMHS supports security services then the MMHS MUST implement this service as profiled in <xref target="SP-Security-Labels"/>.
     </t>
    </section>
    <section title="Non-repudiation of Receipt" anchor="Non-Repudiation-Of-Receipt">
     <t>
      The Non-repudiation of Receipt security service provides the originator with evidence that demonstrates, to a third-party, who received the message, and will protect against any attempt by the message recipient to falsely deny having received the message. This evidence is the signed receipt, which includes a digital signature and the certificates necessary to verify it.
     </t>
     <t>
      The MMHS MAY implement this service supporting the ReceiptRequest attribute as specified in <xref target="RFC2634"/> Section 2.
     </t>
    </section>
    <section title="Secure Mailing Lists" anchor="Secure-Mailing-Lists">
     <t>
      The Secure Mailing Lists security service allows a Mail List Agent (MLA) to take a single message, perform recipient-specific security processing, and then redistributes the message to each member of the Address List (AL) or Mail List (ML).
     </t>
     <t>
      The MMHS MAY implement this service supporting the mlExpansionHistory attribute as specified in <xref target="RFC2634"/> Section 4.
     </t>
    </section>
    <section title="Message Counter Signature" anchor="Message-Counter-Signature">
     <t>
      The Message Counter Signature security service allows multiple signatures to be applied to the original signature value in a sequential manner. Thus, the Message Counter-signature service allows supervising users or release authorities to countersign for an originator without invalidating the original signature.
     </t>
     <t>
      The MMHS MAY implement this service supporting the countersignature attribute as specified in <xref target="RFC5652"/> Section 11.4.
     </t>
    </section>
    <section title="Certificate Binding" anchor="Certificate-Binding">
     <t>
      The Certificate Binding security service allows for a certificate, which is sent with the message to be cryptographically bound to the message.
     </t>
     <t>
      The MMHS MAY implement this service supporting the SigningCertificate attribute as specified in <xref target="RFC2634"/> Section 5. The SigningCertificate attribute SHOULD only contain the leaf end-user certificate except where some prior agreement (possibly bilateral) exists to ensure that path validation is not adversely affected.  Differing treatment in <xref target="RFC2634"/> Section 5.3, paragraph 3 avoids impact to path validation if only the leaf certificate is included.
     </t>
    </section>
    <section title="Compressed Data" anchor="Compressed-Data">
     <t>
      The Compressed Data security service reduces message size, which helps to protect MMHS availability and may provide an element of robustness in the event of denial of service attacks.
     </t>
     <t>
      If the MMHS provides security services it MAY support the Compressed Data service.
     </t>
     <t>
      The MMHS SHOULD include support for the Compressed Data content type on origination profiled in <xref target="Compressed-Data-CT"/>.
     </t>
     <t>
      Alternatively the MMHS MAY support the application/zlib and application/gzip MIME media types on origination as defined in <xref target="RFC6713"/>.
     </t>
     <t>
      On reception the MMHS MUST support the Compressed Data content type, application/zlib media type and application/gzip media type.
     </t>
    </section>
   </section>
   <section title="Security Profile" anchor="Security-Profile">
    <t>
     This section profiles the use of the S/MIME protocols <xref target="RFC5751"/>, <xref target="RFC5652"/> and <xref target="RFC2634"/> and DKIM protocol <xref target="RFC6376"/> for adding cryptographic services to the MMHS. The relevant sections of <xref target="RFC5751"/>, <xref target="RFC5652"/>, <xref target="RFC2634"/> and <xref target="RFC6376"/> are listed with further clarifications and amendments specific to the implementation of an MMHS conformant with this profile.
    </t>
    <t>
     This security profile is aligned with the "Profile for the Use of the Cryptographic Message Syntax (CMS) and Enhanced Security Services (ESS) for S/MIME", <xref target="STANAG-4631"/>.
    </t>
    <t>
     In order for participating organisations (or domains) to obtain secure interoperability additional bilateral agreements on the labeling, cryptographic algorithms and Public Key Infrastructure (PKI) need to be achieved.
    </t>
    <section title="S/MIME Cryptographic Message Syntax Content Types">
     <t>
      If the MMHS supports the S/MIME protocols for implementing the security services then the MMHS MUST support the Data, SignedData, EnvelopedData, and CompressedData content types as specified in <xref target="RFC5751"/>.
     </t>
     <t>
      In accordance with <xref target="RFC5652"/> ContentInfo MUST be supported to encapsulate the outer most SignedData or EnvelopedData content type. Conventions for inner wrappers MUST comply with <xref target="RFC5751"/>.
     </t>
     <t>
      The clarifications and refinements are as follows:
      <list style="symbols" >
       <t>
        The ContentInfo contentType field MUST be supported.
       </t>
       <t>
        The ContentInfo content field MUST be supported.
       </t>
      </list>
     </t>
     <section title="Data Content Type">
      <t>
       The MMHS MUST use the id-data content type identifier to identify the "inner" MIME message content as specified in <xref target="RFC5751"/>.
      </t>
     </section>
     <section title="Signed-data Content Type" anchor="Signed-Data-CT">
      <t>
       The signedData content type is specified in <xref target="RFC5652"/> Section 5, consisting of MIME content (identified by the id-data content type) and zero or more signature values.
      </t>
      <section title="SignedData Type">
       <t>
        The MMHS MUST support the SignedData type as specified in <xref target="RFC5652"/> Section 5.1. The clarifications and refinements are as follows:
        <list style="symbols" >
         <t>
          The MMHS MUST support the EncapsulatedContentInfo type eContentType attribute. The value of the eContentType MUST be id-data unless the content is compressed according to <xref target="Compressed-Data-CT"/>.
         </t>
         <t>
          The MMHS MUST support the EncapsulatedContentInfo type eContent attribute. The value of the eContent MUST contain the content to be signed. If the content is compressed using the compressed-data content type as defined in <xref target="Compressed-Data-CT"/>, the CompressedData.encapContentInfo.eContentType MUST be set to the id-data content type identifier of the compressed MIME content and the CompressedData.encapContentInfo.eContent MUST contain the MIME content to be compressed and protected by S/MIME.
         </t>
         <t>
          The MMHS MUST support X.509 version 3 certificates. An MMHS with high throughput MUST include certificates within the message. An MMHS with impoverished communications SHOULD NOT send certificates with the message.
         </t>
         <t>
          The MMHS MUST support the certificate profile and CRL profile specified in <xref target="RFC5280"/> <xref target="RFC6818"/>.
         </t>
         <t>
          The MMHS MUST support X.509 version 3 certificate processing specified in <xref target="RFC5750"/>.
         </t>
        </list>
       </t>
      </section>
      <section title="SignerInfo Type">
       <t>
        The SignerInfo type is specified in <xref target="RFC5652"/> Section 5.3 allowing the inclusion of unsigned and signed attributes along with a signature. The clarifications and refinements are as follows:
        <list style="symbols">
         <t>
          The MMHS MUST support signed attributes. As a minimum the MMHS MUST support processing and handling of the following signed attributes: contentType (<xref target="RFC5751"/> Section 2.5.1); eSSSecurityLabel (<xref target="RFC2634"/> Section 3.2; messageDigest (<xref target="RFC5652"/> Section 11.2); signingTime (<xref target="RFC5751"/> Section 2.5.1); sMIMECapabilities (<xref target="RFC5751"/> Section 2.5.2); and, sMIMEEncryptionKeyPreference (<xref target="RFC5751"/> Section 2.5.3).
         </t>
         <t>
          The MMHS MUST support the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms and signature algorithms as specified in <xref target="RFC5754"/> and <xref target="RFC5751"/>.
         </t>
         <t>
          The MMHS MUST support both the SignerIdentifier type attributes issuerAndSerialNumber and subjectKeyIdentifier.
         </t>
        </list>
       </t>
      </section>
     </section>
     <section title="Enveloped-data Content Type" anchor="Enveloped-Data-CT">
      <t>
       The envelopedData content type is specified in <xref target="RFC5652"/> Section 6, consisting of an encrypted MIME content (identified by the id-data content type) and encrypted content-encryption keys for one or more recipients.
      </t>
      <section title="EnvelopedData Type">
       <t>
        The MMHS MUST support the EnvelopedData type as specified in <xref target="RFC5652"/> Section 6.1. The clarifications and refinements are as follows:<list style="symbols" >
         <t>
          The MMHS MUST support the EncryptedContentInfo type eContentType attribute. The value of the eContentType MUST be id-data unless the content is compressed according to <xref target="Compressed-Data-CT"/>.
         </t>
         <t>
          The MMHS MUST support the EncryptedContentInfo type eContent attribute. The value of the eContent MUST contain the content to be encrypted. If the content is compressed using the compressed-data content type as defined in <xref target="Compressed-Data-CT"/>, the CompressedData.encapContentInfo.eContentType MUST be set to the id-data content type identifier of the compressed MIME content and the CompressedData.encapContentInfo.eContent MUST contain the MIME content to be compressed and protected by S/MIME.
         </t>
         <t>
          The MMHS MUST support the originatorInfo attribute if required by the key-management algorithm (refer to <xref target="Recipient-Info"/>).
         </t>
         <t>
          The MMHS MUST support X.509 version 3 certificates. An MMHS with high throughput MUST include certificates within the message. An MMHS with impoverished communications SHOULD NOT send certificates with the message.
         </t>
         <t>
          The MMHS MUST support the certificate profile and CRL profile specified in <xref target="RFC5280"/> <xref target="RFC6818"/>.
         </t>
         <t>
          The MMHS MUST support X.509 version 3 certificate processing specified in <xref target="RFC5750"/>.
         </t>
        </list>
       </t>
       <section title="RecipientInfo Type" anchor="Recipient-Info">
        <t>
         The RecipientInfo type is specified in <xref target="RFC5652"/> Section 6.2. The clarifications and refinements are as follows:
         <list style="symbols">
          <t>
           The MMHS MAY support KeyTransRecipientInfo.
          </t>
          <t>
           The MMHS MUST support KeyAgreeRecipientInfo. The originatorKey attribute MUST be supported as the choice for the originator to specify the sender's key agreement public key.
          </t>
          <t>
           The MMHS MAY support KEKRecipientInfo.
          </t>
          <t>
           The MMHS MAY support PasswordRecipientinfo.
          </t>
          <t>
           The MMHS MAY support OtherRecipientInfo.
          </t>
         </list>
        </t>
       </section>
      </section>
     </section>
     <section title="Compressed-Data Content Type" anchor="Compressed-Data-CT">
      <t>
       The MMHS MUST support the compressedData content type as specified in <xref target="RFC3274"/>.
      </t>
      <section title="CompressedData Type">
       <t>
        In the cases where the MMHS uses compressedData, it MUST only be used once for every message and MUST only be used around the content of the innermost security wrapper.
       </t>
      </section>
     </section>
    </section>
    <section title="S/MIME Triple Wrapping">
     <t>
      If the MMHS supports S/MIME protocols for providing the security services (defined in this profile) the MMHS MUST support military messages that are triple wrapped or signed only. A triple wrapped message is one that has been signed, then encrypted, then signed again. The signers of the inner and outer signatures may be different entities or the same entity. If a military message is triple wrapped, the SignedData and EnvelopedData wrappers MUST follow the specifications described in <xref target="Signed-Data-CT"/> and <xref target="Enveloped-Data-CT"/> of this profile, respectively.
     </t>
    </section>
    <section title="Organisation to Organisation Security">
     <t>
      The implementation of the MMHS security services is dependent upon the security and assurance requirements that are to be met by those MMHS security services. As such, the identity of the signer of the MMHS message may be the user, the role the user is performing or the organization the user belongs to.  If the MMHS supports S/MIME protocols for providing the security services (defined in this profile) and the MMHS is providing organisation to organisation security services then the MMHS MUST support Domain-based signing using S/MIME as specified in <xref target="I-D.melnikov-smime-msa-to-mda"/>.
     </t>
    </section>
    <section title="DKIM Digital Signatures" anchor="DKIM-Signatures">
     <t>
      DKIM <xref target="RFC6376"/> defines an organization-level digital signature authentication framework for Internet email, using public key cryptography and using the domain name service as its key server technology. However, it is possible to administer DKIM to support user-level signature granularity. This profile specifies the use of DKIM defined in <xref target="RFC6376"/> for providing an alternative security mechanism to S/MIME to deliver the Authentication of Origin (<xref target="Authentication-Of-Origin"/>), Non-repudiation of Origin (<xref target="Non-Repudiation-Of-Origin"/>) and Message Integrity (<xref target="Message-Integrity"/>) security services to the MMHS. However, the implementation of DKIM is dependent upon the security and assurance requirements that are to be met by the MMHS security services. An MMHS MAY implement DKIM (to apply digital signatures for the MMHS message header fields and message body) to meet those security and assurance requirements based on one of the following use cases:
     </t>
     <t>
      <list style="numbers">
       <t>
        Share the organization signing identity (identified by the Signing Domain Identifier (SDID)) private key for signing the MMHS message. The MMHS message is digitally signed by the organization MSA component. This profile does not provide end to end security services. This profile supports organization to organization Authentication of Origin, Non-repudiation of Origin and Message Integrity security services.
       </t>
       <t>
        Share the organization signing identity private key for signing the MMHS message. The email address of the MMHS message originator can be specified as the Agent or User Identifier (AUID). The semantics for performing per-user identity differentiation with this approach MUST be agreed out-of-band and is outside the scope of this MMHS profile. The MMHS message is digitally signed by the organization MSA component. This profile does not provide end to end security services. This profile supports organization to organization Authentication of Origin, Non-repudiation of Origin and Message Integrity security services.
       </t>
       <t>
        Generate per-user public/private key pairs where the public key is published to distinct subdomains (of the organization domain). The MMHS message is signed with the user's private key and the signing identity is identifiable by the user's subdomain value in the SDID. The MMHS message is digitally signed by the MUA. This profile supports end to end Authentication of Origin, Non-repudiation of Origin and Message Integrity security services.
       </t>
       <t>
        Generate per-user public/private key pairs where the public key is published to a unique resource record under the organization domain. The MMHS message is signed with the user's private key and the signing identity is identifiable by the domain value in the SDID and the unique resource record identified by the selector value. The MMHS message is digitally signed by the MUA. This profile supports end to end Authentication of Origin, Non-repudiation of Origin and Message Integrity security services.
       </t>
      </list>
     </t>
     <t>
      <!--////Change the SHOULD to MUST? ("MUST support one and/or another")-->
      To provide organization to organization security services: the recipient MUA SHOULD support DKIM digital signature verification or the MUA MUST support the Authentication-Results header field as specified in <xref target="RFC7601"/> according to the security policy; and the organization border MTA (or MDA) MUST support DKIM digital signature verification and output the verification results (according to the security policy) to the Authentication-Results header field compliant with <xref target="RFC7601"/>.
     </t>
     <t>
      To provide end to end security services the recipient MUA MUST support DKIM digital signature verification specified in <xref target="RFC6376"/>.
     </t>
     <t>
      DKIM does not provide confidentiality security services.
     </t>
    </section>
    <section title="Security Labels" anchor="SP-Security-Labels">
     <t>
      If the MMHS supports S/MIME protocols for implementing security services then the MMHS MUST support on origination the ESSSecurityLabel specified in Section 3 of <xref target="RFC2634"/>. The MMHS MUST support the security-policy-identifier, security-classification, privacy-mark and security-categories attributes of the ESSSecurityLabel. The MMHS MAY support the Equivalent Security Labels EquivalentLabels as specified in <xref target="RFC2634"/> Section 3.4.
     </t>
     <t>
      An MMHS MAY on origination support the SIO-Label header field as specified in <xref target="RFC7444"/>.
     </t>
     <t>
      On reception the MMHS MUST support the ESSSecurityLabel and SIO-Label. In the case where a military message contains a SIO-Label and an ESSSecurityLabel the MMHS MUST assert that the policy conveyed in both are the same and that the sensitivity, compartments, and other handling caveats that can be conveyed in both are the same.
     </t>
    </section>
    <section title="Message Header Fields">
     <t>
      By default, <xref target="RFC5751"/> secures MIME message body parts, excluding the message header fields. If the MMHS implements S/MIME security services then the MMHS SHOULD provide a mechanism for securing the message header fields. <xref target="RFC5751"/> includes a mechanism for protecting the header fields where the whole message is wrapped in a message/rfc822 MIME media type. However, this approach can be problematic for non-S/MIME aware MUAs and does not provide a mechanism for signing a subset of message header fields.
     </t>
     <t>
      If the MMHS provides security services this profile requires that the MMHS MUST support the protection for the integrity and authenticity of MMHS message header fields.
      </t>
     <t>
      The MMHS MUST support the mechanism for protecting the header fields as defined in <xref target="RFC5751"/> based on the considerations specified in <xref target="I-D.melnikov-smime-header-signing"/> and/or the MMHS MUST support DomainKeys Identified Mail (DKIM) Signatures profiled in <xref target="DKIM-Signatures"/> for digitally signing the MMHS message header fields.
     </t>
     <t>
      In the case of DKIM for digitally signing the MMHS message header fields a subset or all of the MMHS message header fields MAY be digitally signed. The MMHS message headers that are required to be digitally signed are to be specified in the security policy being enforced, however a recommended set of MMHS message headers that are to be digitally signed (if present) are listed below (note that if a header field is absent, DKIM will provide protection from insertion of the header field):
     </t>
     <t>
      <list style="symbols">
       <t>
        From
       </t>
       <t>
        Reply-To
       </t>
       <t>
        Subject
       </t>
       <t>
        Date
       </t>
       <t>
        To, Cc, Bcc
       </t>
       <t>
        Sender
       </t>
       <t>
        Expires
       </t>
       <t>
        Supersedes
       </t>
       <t>
        Message-ID
       </t>
       <t>
        In-Reply-To, References
       </t>
       <t>
        SIO-Label
       </t>
       <t>
        MMHS-Primary-Precedence, MMHS-Copy-Precedence, MMHS-Message-Type, MMHS-Extended-Authorisation-Info, MMHS-Authorizing-Users
       </t>
       <t>
        <!--////Signing this header field might cause inability to change priorities, which might be a bad thing for some deployments.-->
        MT-Priority
       </t>
      </list>
     </t>
     <t>
      DKIM does not provide confidentiality security services.
     </t>
    </section>
   </section>
  </section>

  <section title="Requirements on Mail User Agents" anchor="mua-reqs">

   <section title="Standards Compliance">
    <t>
     A Mail User Agent (MUA) compliant with this specification MUST support

     <list style="numbers">

      <t>
       Internet Message Format <xref target="RFC5322"/>.
      </t>

      <t>
       Multipurpose Internet Mail Extensions (MIME)
       <xref target="RFC2045"/>
       <xref target="RFC2046"/>
       <xref target="RFC2047"/>
       <xref target="RFC2049"/>
       <xref target="RFC2231"/>.
       In particular they must be able to generate, display and process of message/rfc822, multipart/mixed and text/plain media types.
       Additionally, the ability to decode application/zlib and application/gzip media types on receipt as defined in <xref target="RFC6713"/>
       and support for format=flowed text/plain media type parameter <xref target="RFC3676"/>.
      </t>

      <!--////Do we need to list which header fields MUST be supported and which MAY be supported?-->
      <t>
       Parsing, processing and having the ability to generate MMHS header fields specified in <xref target="RFC6477"/>.
      </t>

      <t>
       The ability to specify priority on origination, in particular the ability to insert MT-Priority header field <xref target="RFC6758"/> into messsages to be sent.
      </t>

      <t>
       Parsing and processing of multipart/report media type for the Reporting of Mail System Administrative Messages <xref target="RFC6522"/> containing message/delivery-status <xref target="RFC3464"/> and Message Disposition Notification (MDN) <xref target="RFC3798"/>.
      </t>

      <t>
       The ability to request an MDN and the ability to generate an MDN in response to a request <xref target="RFC3798"/>.
      </t>

      <t>
       <!--////Does it need to be displayed on receipt?-->
       The ability to indicate message language using the Content-Language header field, as defined in <xref target="RFC3282"/>.
      </t>

      <t>
       The ability to select message expiration date when composing a message (using the Expires header field <xref target="RFC2156"/>)
       and display whether a message is expired or not upon receipt.
      </t>

      <t>
       Use of SMTP extension for Delivery Status Notifications <xref target="RFC3461"/>, in particular support for NOTIFY, RET and ENVID parameters.
      </t>

      <t>
       Use of the Deliver By SMTP extension <xref target="RFC2852"/> for specifying the Latest Delivery date for a message.
      </t>

      <t>
       If supporting S/MIME for security services: the ability to send and receive signed and encrypted S/MIME messages <xref target="RFC5652"/> <xref target="RFC5751"/>.
      </t>

      <t>
       If supporting S/MIME for security services: the ability to send and receive ESS Security Labels <xref target="RFC2634"/>.
      </t>

      <t>
       If supporting DKIM for security services: support DKIM digital signature verification specified in <xref target="RFC6376"/>
       or support the Authentication-Results header field as specified in <xref target="RFC7601"/> according to the security policy.
      </t>

      <t>
       Support for SIO-Label header field <xref target="RFC7444"/> on receipt.
      </t>

     </list>
    </t>


    <!--      
      <t>
      Additionally a MUA compliant with this specification MAY support
<list style="numbers">
        <t>
  Support for SIO-Label <xref target="RFC7444"/> on origination.
        </t>
        <t>
  Support replacing an earlier message with a new one with Supersedes header field <xref target="RFC2156"/>.
  What about these:
            Original-Encoded-Information-Types
            Incomplete-Copy
          ?
        </t>
        <t>
  New SASL mechanisms:
            For environment using X.509 certificates, use of SASL EXTERNAL <xref target="RFC4422"/> authentication mechanism is RECOMMENDED.
            For environment using Kerberos, use of SASL GSSAPI <xref target="RFC4752"/> authentication mechanism is RECOMMENDED.
            Support for SCRAM <xref target="RFC5802"/> is RECOMMENDED for environment using password based authentication.
        </t>
</list>
        </t>
-->

    <t>
     MUA can also take advantage of SMTP extensions advertised by MSAs (see <xref target="msa-reqs"/>).
    </t>

   </section>

   <section title="Audit Trail and Logging">

    <t>
     Storage of audit data by the MUA is required to support security monitoring, accountability, and
     tractability of messages to the source. This information will be used to provide accountability and support for
     any required tracer actions. All stored audit data shall be maintained for at least ten (10) days. Data will be
     recorded and stored at each MUA to provide an audit capability for messages that are submitted and
     received. The following table indicates which audit information is required at a minimum to be logged by the
     MUA for submitted and received messages. Policy may require longer retention periods and
     additional information be stored. The integrity of audit logs must be protected.
    </t>
    <texttable>
     <!--
		<preamble></preamble>
    -->
     <ttcol align="left" width="50%">Submitted Messages</ttcol>
     <ttcol align="left">Delivered/Received Messages</ttcol>
     <c>
      Authorizing Users Indication, 
      Extended Authorization Info, 
      MM Identification, 
      Message Identification, 
      Delivery/Non-delivery Notification, 
      Receipt/Non-receipt Notification Request Indication, 
      Primary/Copy Precedence, 
      Primary and Copy Recipients Indication, 
      Blind Copy Recipient Indication, 
      Non-Repudiation of Receipt, 
      Security Labels, 
      Message Type
     </c>
     <c>
      Extended Authorization Info, 
      MM Identification, 
      Message Identification, 
      Originator Indication, 
      Primary/Copy Precedence, 
      Security Labels, 
      Delivery Timestamp Indication
     </c>
     <!--
		<postamble></postamble>
    -->
    </texttable>

   </section>
  </section>

  <section title="Requirements on Mail Submission Agents" anchor="msa-reqs">

   <section title="Standards Compliance">
    <t>
     In addition to the list of requirements specified in <xref target="RFC6409"/>,
     an Mail Submission Agent (MSA) compliant with this specification MUST support:

     <list style="numbers">

      <t>
       SMTP Extension for Authentication <xref target="RFC4954"/>.
       For environment using X.509 certificates, SASL EXTERNAL <xref target="RFC4422"/> authentication mechanism must be supported.
       For environment using Kerberos, SASL GSSAPI <xref target="RFC4752"/> authentication mechanism must be supported.
       For environment using password based authentication, SASL SCRAM <xref target="RFC5802"/> must be supported.
      </t>
      <t>
       SMTP Extension for Secure SMTP over TLS <xref target="RFC3207"/>.
      </t>

      <t>
       SMTP Service Extension for Returning Enhanced Error Codes <xref target="RFC2034"/>.
      </t>

      <t>
       Deliver By SMTP Service Extension <xref target="RFC2852"/>.
      </t>

      <t>
       SMTP extension for Message Transfer Priorities. <xref target="RFC6710"/>
       "STANAG4406" Priority Assignment Policy MUST be advertised in the EHLO response.
       The MSA MUST be able to handle the MT-Priority header field as specified in <xref target="RFC6758"/>.
      </t>

      <t>
       SMTP extension for for Delivery Status Notifications <xref target="RFC3461"/>.
      </t>

      <t>
       SMTP Extension for 8-bit MIME transport <xref target="RFC6152"/>.
      </t>
      <t>
       SMTP Extension for Message Size Declaration <xref target="RFC1870"/>.
      </t>
      <t>
       SMTP Extension for Command Pipelining <xref target="RFC2920"/>.
      </t>
      <t>
       SMTP Extensions for Transmission of Large and Binary MIME Messages <xref target="RFC3030"/>.
      </t>

      <t>
       Support Draft &amp; Release procedure using the MMHS-Authorizing-Users header field <xref target="I-D.melnikov-mmhs-authorizing-users"/>.
      </t>

      <!--////
  If supporting S/MIME for security services: the ability to send and receive ESS Security Labels <xref target="RFC2634"/>.
-->

      <t>
       If supporting S/MIME for security services: the ability to sign and/or encrypt S/MIME messages on bahalf of the originating domain as specified in <xref target="I-D.melnikov-smime-msa-to-mda"/>.
      </t>

      <t>
       If supporting DKIM for security services: support DKIM digital signature generation as specified in <xref target="RFC6376"/>.
      </t>

     </list>
    </t>


    <t>
     The following SMTP extensions are OPTIONAL to support in MSAs compliant with this specification:

     <list style="numbers">

      <t>
       SMTP Submission Service Extension for Future Message Release <xref target="RFC4865"/>.
      </t>

      <!--////draft-melnikov-smtp-altrecip-on-error - maybe in the future.
  <t>SMTP extension for Alternate Recipient Delivery Option.</t>
-->

     </list>

    </t>

   </section>

   <section title="Audit Trail and Logging">

    <t>
     Storage of audit data by the MSA is required to support security monitoring, accountability, and traceability of
     messages to the source. This information will be used to provide accountability and support for any required
     tracer actions. All stored audit data shall be maintained for at least ten (10) days. Data will be recorded and
     stored at each MSA to provide an audit capability for messages that are delivered and submitted. The following
     table indicates which audit information is required at a minimum to be logged by the MSA for delivered and
     submitted messages. Policy may require longer retention periods and additional information be
     stored. The integrity of audit logs must be protected.
    </t>

    <texttable>
     <!--
		<preamble></preamble>
    -->
     <ttcol align="left" width="100%">Submitted Messages</ttcol>
     <c>
      MM Identification, 
      Message Identification, 
      Submission Timestamp Indication, 
      Priority
     </c>
     <!--
		<postamble></postamble>
    -->
    </texttable>

   </section>

  </section>



  <section title="Requirements on Mail Transfer Agents" anchor="mta-reqs">

   <section title="Standards Compliance">

    <t>
     A Mail Transfer Agent (MTA) compliant with this specification MUST support

     <list style="numbers">

      <t>
       SMTP Service Extension for Returning Enhanced Error Codes <xref target="RFC2034"/>.
      </t>

      <t>
       Deliver By SMTP Service Extension <xref target="RFC2852"/>.
      </t>

      <t>
       SMTP extension for Message Transfer Priorities <xref target="RFC6710"/>.
       "STANAG4406" Priority Assignment Policy MUST be advertised in the EHLO response.
       The MTA MUST be able to handle the MT-Priority header field as specified in <xref target="RFC6758"/>.
      </t>

      <t>
       SMTP extension for for Delivery Status Notifications <xref target="RFC3461"/>.
      </t>

      <t>
       SMTP Extension for 8-bit MIME transport <xref target="RFC6152"/>.
      </t>
      <t>
       SMTP Extension for Message Size Declaration <xref target="RFC1870"/>.
      </t>
      <t>
       SMTP Extension for Command Pipelining <xref target="RFC2920"/>.
      </t>
      <t>
       SMTP Extensions for Transmission of Large and Binary MIME Messages <xref target="RFC3030"/>.
      </t>

     </list>
    </t>


    <t>
     Additionally border MTAs in originating domains MUST support

     <list style="numbers">

      <t>
       Enforcement of correct Draft &amp; Release procedure using the MMHS-Authorizing-Users header field <xref target="I-D.melnikov-mmhs-authorizing-users"/>.
      </t>

      <t>
       If supporting S/MIME for security services: the ability to sign and/or encrypt S/MIME messages on bahalf of the originating domain as specified in <xref target="I-D.melnikov-smime-msa-to-mda"/>.
      </t>

      <t>
       If supporting DKIM for security services: support DKIM digital signature generation as specified in <xref target="RFC6376"/>.
      </t>


      <t>
       If supporting S/MIME for security services: enforcement of correctness of ESS Security Labels <xref target="RFC2634"/>.
      </t>


      <t>
       Enforcement of correctness of security labels in SIO-Label header field <xref target="RFC7444"/>.
      </t>

      <t>
       SMTP Extension for Secure SMTP over TLS <xref target="RFC3207"/>.
      </t>

      <t>
       SMTP Extension for Authentication <xref target="RFC4954"/>.
      </t>
       
     </list>
    </t>




    <t>
     Additionally border MTAs in receiving domains MUST support

     <list style="numbers">

      <t>
       If supporting S/MIME for security services: the ability to verify and/or decrypt S/MIME messages on behalf of the receiving domain as specified in <xref target="I-D.melnikov-smime-msa-to-mda"/>.
      </t>

      <t>
       If supporting DKIM for security services: support DKIM digital signature verification as specified in <xref target="RFC6376"/>.
      </t>

      <t>
       Support for the Authentication-Results header field generation as specified in <xref target="RFC7601"/> if required by the security policy.
      </t>

      <t>
       If supporting S/MIME for security services: enforcement of correctness of ESS Security Labels <xref target="RFC2634"/>.
      </t>


      <t>
       Enforcement of correctness of security labels in SIO-Label header field <xref target="RFC7444"/>.
      </t>

       <t>
         SMTP Extension for Secure SMTP over TLS <xref target="RFC3207"/>.
       </t>

       <t>
         SMTP Extension for Authentication <xref target="RFC4954"/>.
       </t>
       
     </list>
    </t>

<!--////
    <t>
     The following SMTP extensions SHOULD be supported in MTAs compliant with this specification:

     <list style="numbers">

draft-melnikov-smtp-altrecip-on-error - maybe in the future
  <t>SMTP extension for Alternate Recipient Delivery Option.</t>

     </list>

    </t>
-->

  </section>

   <section title="Audit Trail and Logging">
    <t>
     Storage of audit data by the MTA is required to support security monitoring, accountability, and tracability of
     messages to the source. This information will be used to provide accountability and support for any required
     tracer actions. All stored audit data shall be maintained for at least ten (10) days. Data will be recorded and
     stored at each MTA to provide an audit capability for messages that are sent and received. The following
     table indicates which audit information is required at a minimum to be logged by the MTA for inbound and
     outbound messages. Policy may require longer retention periods and additional information be
     stored. The integrity of audit logs must be protected.
    </t>

    <texttable>
     <!--
		<preamble></preamble>
    -->
     <ttcol align="left" width="50%">Inbound Messages</ttcol>
     <ttcol align="left">Outbound Message</ttcol>
     <c>
      MM Identification, 
      Message Identification, 
      Submission Timestamp Indication, 
      Priority, 
      Time of Transfer In*
     </c>
     <c>
      MM Identification, 
      Message Identification, 
      Submission Timestamp Indication, 
      Priority, 
      Time of Transfer Out*
     </c>
     <!--
		<postamble></postamble>
    -->
    </texttable>
    <t>* MTAs operating in a relay capacity are responsible for logging the marked attributes.</t>
    
   </section>

  </section>


  <section title="IANA Considerations">

   <t>This document doesn't ask for any action from IANA.</t>

  </section>

  <section title="Security Considerations" anchor="seccons">

   <t>
    This document specifies an MMHS Profile for a comparable
    messaging service to STANAG 4406 Edition 2 or <xref target="ACP123"/> provided using Internet Electronic Mail, SMTP and their extensions, S/MIME and DKIM.
   </t>
   <t>
   The MMHS Profile is not defining new protocol, therefore no new security concerns are raised that are not already captured by
   Email <xref target="RFC5322"/>, MIME <xref target="RFC2045"/>, S/MIME <xref target="RFC5751"/>, DKIM <xref target="RFC6376"/>,
   ESS <xref target="RFC2634"/> and SIO-Label <xref target="RFC7444"/> in general.
   </t>
  </section>

 </middle>
 <back>
  <references title="Normative References">

   <?rfc include="reference.RFC.2033"?>
   <!-- LMTP -->
   <?rfc include="reference.RFC.2034"?>
   <!-- SMTP extension for returning Enhanced Status Codes -->
   <?rfc include="reference.RFC.2119"?>
   <!-- Keywords -->
   <?rfc include="reference.RFC.3461"?>
   <!-- SMTP DSN -->
   <?rfc include="reference.RFC.5321"?>
   <!-- SMTP -->
   <?rfc include="reference.RFC.5322"?>
   <!-- Email -->
   <?rfc include="reference.RFC.6409"?>
   <!-- Submission Service -->
   <?rfc include="reference.RFC.1870"?>
   <!-- SMTP SIZE -->
   <?rfc include="reference.RFC.2852"?>
   <!-- SMTP DELIVERBY -->
   <?rfc include="reference.RFC.2920"?>
   <!-- SMTP PIPELINING -->
   <?rfc include="reference.RFC.3030"?>
   <!-- SMTP BDAT -->
   <?rfc include="reference.RFC.4865"?>
   <!-- Future Release SMTP extension -->
   <?rfc include="reference.RFC.6152"?>
   <!-- SMTP 8BITMIME -->

   <?rfc include="reference.RFC.4954"?>
   <!-- SMTP AUTH -->
   <?rfc include="reference.RFC.3207"?>
   <!-- SMTP STARTTLS -->

   <?rfc include="reference.RFC.6477"?>
   <!-- MMHS Header Fields -->
   <?rfc include="reference.RFC.6710"?>
   <!-- SMTP Priority -->
   <?rfc include="reference.RFC.6758"?>
   <!-- SMTP Priority Tunnelling -->

   <!-- MIME: -->
   <?rfc include="reference.RFC.2045"?>
   <!--////+RFC 6657 ("charset" for text/*)?-->
   <?rfc include="reference.RFC.2046"?>
   <?rfc include="reference.RFC.2047"?>
   <?rfc include="reference.RFC.2049"?>
   <?rfc include="reference.RFC.2231"?>
   <?rfc include="reference.RFC.3676"?><!--format=flowed-->
   <?rfc include="reference.RFC.6713"?>
   <!-- application/zlib and application/gzip -->

   <?rfc include="reference.RFC.5280"?>
   <!-- PKIX -->
   <?rfc include="reference.RFC.6818"?>

   <?rfc include="reference.RFC.2634"?>
   <!--Enhanced Security Services for S/MIME-->
   <?rfc include="reference.RFC.5652"?>
   <!--CMS-->
   <?rfc include="reference.RFC.5751"?>
   <!--S/MIME 3.1-->
   <?rfc include="reference.RFC.5754"?>
   <!-- Using SHA2 Algorithms with Cryptographic Message Syntax -->
   <?rfc include="reference.RFC.5750"?>
   <!-- Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
                                                Certificate Handling -->
   <?rfc include="reference.RFC.3274"?>
   <!-- Compressed Data Content Type for CMS -->

   <?rfc include="reference.RFC.3464"?>
   <!-- DSN format -->
   <?rfc include="reference.RFC.6522"?>
   <!-- Multipart/Report -->
   <?rfc include="reference.RFC.3798"?>
   <!-- Message Disposition Notification -->

   <?rfc include="reference.RFC.3282"?>
   <!-- Content-Language -->

   <?rfc include="reference.RFC.5228"?>
   <!-- Sieve -->

   <?rfc include="reference.RFC.7601"?>
   <!-- Authentication-Results -->

   <?rfc include="reference.RFC.2156"?>
   <!-- MIXER -->
   <?rfc include="reference.RFC.6376"?>
   <!-- DKIM -->
   <?rfc include="reference.RFC.7444"?>
   <!-- SIO-Label -->

   <?rfc include="reference.RFC.4422"?>
   <!-- SASL and SASL EXTERNAL -->
   <?rfc include="reference.RFC.4752"?>
   <!-- SASL GSSAPI -->
   <?rfc include="reference.RFC.5802"?>
   <!-- SASL SCRAM -->

   <reference anchor="ACP123">
    <front>
     <title>Common Messaging Strategy and Procedures</title>
     <!--CCEB == COMBINED COMMUNICATIONS-ELECTRONICS BOARD-->
     <author surname="CCEB">
      <!--
			<organization></organization>
-->
     </author>
     <date month="May" year="2009"/>
    </front>
    <seriesInfo name="ACP" value="123"/>
    <format target="http://jcs.dtic.mil/j6/cceb/acps/acp123" type="HTML"/>
   </reference>

   <reference anchor='I-D.melnikov-mmhs-authorizing-users'>
    <front>
     <title>Draft and Release using Internet Email</title>

     <author initials='A' surname='Melnikov' fullname='Alexey Melnikov'>
      <organization />
     </author>

     <date month='June' day='23' year='2015' />

     <abstract>
      <t>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 countersigned, allowing recipients to verify both the original signature (if any) and countersignatures.</t>
     </abstract>

    </front>

    <seriesInfo name='Internet-Draft' value='draft-melnikov-mmhs-authorizing-users-08' />
    <format type='TXT'
            target='http://www.ietf.org/internet-drafts/draft-melnikov-mmhs-authorizing-users-08.txt' />
   </reference>


   <reference anchor='I-D.melnikov-smime-msa-to-mda'>
    <front>
     <title>Domain-based signing and encryption using S/MIME</title>

     <author initials='A' surname='Melnikov' fullname='Alexey Melnikov'>
      <organization />
     </author>

     <date month='March' day='05' year='2014' />

     <abstract>
      <t>This document specifies how S/MIME signing and encryption can be applied between a Message Submission Agent (MSA) and a Message Delivery Agent (MDA) or between 2 Message Transfer Agents (MTA).</t>
     </abstract>

    </front>

    <seriesInfo name='Internet-Draft' value='draft-melnikov-smime-msa-to-mda-04' />
    <format type='TXT'
            target='http://www.ietf.org/internet-drafts/draft-melnikov-smime-msa-to-mda-04.txt' />
   </reference>

   <reference anchor='I-D.melnikov-smime-header-signing'>
    <front>
     <title>Considerations for protecting Email header with S/MIME</title>

     <author initials='A' surname='Melnikov' fullname='Alexey Melnikov'>
      <organization />
     </author>

     <date month='April' day='03' year='2015' />

     <abstract>
      <t>This document describes best practices for handling of Email header protected by S/MIME.  It also adds a new Content-Type parameter to help distinguish an S/MIME protected forwarded message from an S/MIME construct protecting message header.</t>
     </abstract>

    </front>

    <seriesInfo name='Internet-Draft' value='draft-melnikov-smime-header-signing-02' />
    <format type='TXT'
            target='http://www.ietf.org/internet-drafts/draft-melnikov-smime-header-signing-02.txt' />
   </reference>

   <!--
   **
   * Deprecated
   **
   
   <reference anchor="I-D.zeilenga-email-seclabel">
    <front>
     <title>Security Labels in Internet Email</title>
     <author initials="K" surname="Zeilenga" fullname="Kurt Zeilenga">
      <organization/>
     </author>
     <author initials="A" surname="Melnikov" fullname="Alexey Melnikov">
      <organization/>
     </author>
     <date month="December" day="1" year="2013"/>
     <abstract>
      <t>
       This document describes a header field, SIO-Label, for use in Internet Mail to convey the sensitivity of the message. This header field which may carry a textual representation (a display marking) and/or a structural representation (a security label) of the sensitivity of the message. This document also describes a header field, SIO-Label-History, for recording changes in the message's label.
      </t>
     </abstract>
    </front>
    <seriesInfo name="Internet-Draft" value="draft-zeilenga-email-seclabel-07"/>
    <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-zeilenga-email-seclabel-07.txt"/>
   </reference>-->

  </references>

  <references title="Informative References">

   <?rfc include="reference.RFC.5598"?>
   <!-- Internet Mail Architecture -->

   <!--IMAP:
      <?rfc include="reference.RFC.3501"?>
-->

   <reference anchor="STANAG-4406">
    <front>
     <title>STANAG 4406 Edition 2: Military Message Handling System</title>
     <author surname="NATO">
     </author>
     <date month="March" year="2005"/>
    </front>
    <seriesInfo name="STANAG" value="4406"/>
   </reference>

   <reference anchor="STANAG-4631">
    <front>
     <title>STANAG 4631 Edition 1: Profile for the Use of the Cryptographic Message Syntax (CMS) and Enhanced Security Services (ESS) for S/MIME</title>
     <author surname="NATO">
     </author>
     <date month="June" year="2008"/>
    </front>
    <seriesInfo name="STANAG" value="4631"/>
   </reference>

  </references>

  <section title="Acknowledgements">

   <t>
    Many thanks for input provided by Steve Kille and David Wilson.
   </t>

  </section>
 </back>
</rfc>