idnits 2.17.1 draft-melnikov-mmhs-profile-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 3, 2015) is 3125 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2033' is defined on line 2398, but no explicit reference was found in the text == Unused Reference: 'RFC5598' is defined on line 2627, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) ** Obsolete normative reference: RFC 5750 (Obsoleted by RFC 8550) ** Obsolete normative reference: RFC 3798 (Obsoleted by RFC 8098) ** Obsolete normative reference: RFC 7601 (Obsoleted by RFC 8601) == Outdated reference: A later version (-14) exists of draft-melnikov-mmhs-authorizing-users-08 == Outdated reference: A later version (-05) exists of draft-melnikov-smime-header-signing-02 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode Ltd 4 Intended status: Informational G. Lunt 5 Expires: April 5, 2016 A. Ross 6 SMHS Ltd 7 October 3, 2015 9 Military Message Handling System (MMHS) over SMTP Profile 10 draft-melnikov-mmhs-profile-09 12 Abstract 14 A Military Message Handling System (MMHS) processes formal messages 15 ensuring release, distribution, security, and timely delivery across 16 national and international strategic and tactical networks. The MMHS 17 Elements of Service have been defined as a set of extensions to the 18 ITU-T X.400 (1992) international standards and are specified in 19 STANAG 4406 Edition 2 or ACP 123. 21 This document specifies how a messaging service that meets these 22 service definitions can be provided using the SMTP family of 23 protocols. It defines a profile that can be used by those wishing to 24 ensure that these services are provided. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 5, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2. MMHS Profile Summary . . . . . . . . . . . . . . . . . . 5 63 2. Conventions Used in This Document . . . . . . . . . . . . . . 6 64 3. Elements of Service . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2. Profile Support . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. Basic Elements of Service . . . . . . . . . . . . . . . . 16 68 3.3.1. Access Management . . . . . . . . . . . . . . . . . . 16 69 3.3.2. Content Type Indication . . . . . . . . . . . . . . . 16 70 3.3.3. Converted Indication . . . . . . . . . . . . . . . . 16 71 3.3.4. Delivery Time Stamp Indication . . . . . . . . . . . 17 72 3.3.5. MM Identification . . . . . . . . . . . . . . . . . . 17 73 3.3.6. Message Identification . . . . . . . . . . . . . . . 17 74 3.3.7. Non-delivery Notification . . . . . . . . . . . . . . 17 75 3.3.8. Original Encoded Information Types . . . . . . . . . 18 76 3.3.9. Submission Time Stamp Indication . . . . . . . . . . 18 77 3.3.10. Typed Body . . . . . . . . . . . . . . . . . . . . . 18 78 3.3.11. User/UA Capabilities Registration . . . . . . . . . . 19 79 3.4. Optional Elements of Service . . . . . . . . . . . . . . 19 80 3.4.1. Alternate Recipient Allowed . . . . . . . . . . . . . 19 81 3.4.2. Alternate Recipient Assignment . . . . . . . . . . . 19 82 3.4.3. Authorizing Users Indication . . . . . . . . . . . . 20 83 3.4.4. Auto-forwarded Indication . . . . . . . . . . . . . . 20 84 3.4.5. Blind Copy Recipient Indication . . . . . . . . . . . 20 85 3.4.6. Body Part Encryption Indication . . . . . . . . . . . 21 86 3.4.7. Conversion Prohibited . . . . . . . . . . . . . . . . 21 87 3.4.8. Conversion Prohibition in Case of Loss of Information 21 88 3.4.9. Cross Referencing Indication . . . . . . . . . . . . 21 89 3.4.10. Deferred Delivery . . . . . . . . . . . . . . . . . . 22 90 3.4.11. Deferred Delivery Cancellation . . . . . . . . . . . 22 91 3.4.12. Delivery Notification . . . . . . . . . . . . . . . . 22 92 3.4.13. Designation of Recipient by Directory Name . . . . . 22 93 3.4.14. Disclosure of Other Recipients . . . . . . . . . . . 23 94 3.4.15. DL Expansion History Indication . . . . . . . . . . . 23 95 3.4.16. DL Expansion Prohibited . . . . . . . . . . . . . . . 23 96 3.4.17. Expiry Date Indication . . . . . . . . . . . . . . . 23 97 3.4.18. Explicit Conversion . . . . . . . . . . . . . . . . . 24 98 3.4.19. Forwarded MM Indication . . . . . . . . . . . . . . . 24 99 3.4.20. Grade of Delivery Selection . . . . . . . . . . . . . 24 100 3.4.21. Hold for Delivery . . . . . . . . . . . . . . . . . . 25 101 3.4.22. Incomplete Copy Indication . . . . . . . . . . . . . 25 102 3.4.23. Language Indication . . . . . . . . . . . . . . . . . 26 103 3.4.24. Latest Delivery Designation . . . . . . . . . . . . . 26 104 3.4.25. Multi-destination Delivery . . . . . . . . . . . . . 26 105 3.4.26. Multi-part Body . . . . . . . . . . . . . . . . . . . 26 106 3.4.27. Non-receipt Notification Request Indication . . . . . 27 107 3.4.28. Obsoleting Indication . . . . . . . . . . . . . . . . 27 108 3.4.29. Originator Indication . . . . . . . . . . . . . . . . 27 109 3.4.30. Originator Requested Alternate Recipient . . . . . . 28 110 3.4.31. Prevention of Non-delivery Notification . . . . . . . 28 111 3.4.32. Primary and Copy Recipients Indication . . . . . . . 28 112 3.4.33. Receipt Notification Request Indication . . . . . . . 29 113 3.4.34. Redirection Disallowed by Originator . . . . . . . . 29 114 3.4.35. Redirection of Incoming Messages . . . . . . . . . . 29 115 3.4.36. Reply Request Indication . . . . . . . . . . . . . . 30 116 3.4.37. Replying MM Indication . . . . . . . . . . . . . . . 30 117 3.4.38. Requested Preferred Delivery Method . . . . . . . . . 30 118 3.4.39. Subject Indication . . . . . . . . . . . . . . . . . 31 119 3.4.40. Use of Distribution List . . . . . . . . . . . . . . 31 120 3.5. Military Elements of Service . . . . . . . . . . . . . . 31 121 3.5.1. Primary Precedence . . . . . . . . . . . . . . . . . 31 122 3.5.2. Copy Precedence . . . . . . . . . . . . . . . . . . . 31 123 3.5.3. Message Type . . . . . . . . . . . . . . . . . . . . 31 124 3.5.4. Exempted Addresses . . . . . . . . . . . . . . . . . 32 125 3.5.5. Extended Authorization Info . . . . . . . . . . . . . 32 126 3.5.6. Distribution Code . . . . . . . . . . . . . . . . . . 32 127 3.5.7. Message Instructions . . . . . . . . . . . . . . . . 32 128 3.5.8. Clear Service . . . . . . . . . . . . . . . . . . . . 32 129 3.5.9. Other Recipient Indicator . . . . . . . . . . . . . . 32 130 3.5.10. Originator Reference . . . . . . . . . . . . . . . . 32 131 3.5.11. Use of Address List . . . . . . . . . . . . . . . . . 33 132 3.6. Transition Elements of Service . . . . . . . . . . . . . 33 133 3.6.1. Handling Instructions . . . . . . . . . . . . . . . . 33 134 3.6.2. Pilot Forwarded . . . . . . . . . . . . . . . . . . . 33 135 3.6.3. Corrections . . . . . . . . . . . . . . . . . . . . . 33 136 3.6.4. ACP 127 Message Identifier . . . . . . . . . . . . . 33 137 3.6.5. Originator PLAD . . . . . . . . . . . . . . . . . . . 33 138 3.6.6. Codress Message Indicator . . . . . . . . . . . . . . 33 139 3.6.7. ACP 127 Notification Request . . . . . . . . . . . . 33 140 3.6.8. ACP 127 Notification Response . . . . . . . . . . . . 34 141 4. Security Services . . . . . . . . . . . . . . . . . . . . . . 34 142 4.1. General Security Elements of Service . . . . . . . . . . 34 143 4.1.1. Access Control . . . . . . . . . . . . . . . . . . . 34 144 4.1.2. Authentication of Origin . . . . . . . . . . . . . . 34 145 4.1.3. Non-repudiation of Origin . . . . . . . . . . . . . . 35 146 4.1.4. Message Integrity . . . . . . . . . . . . . . . . . . 36 147 4.1.5. Message Data Separation . . . . . . . . . . . . . . . 36 148 4.1.6. Security Labels . . . . . . . . . . . . . . . . . . . 36 149 4.1.7. Non-repudiation of Receipt . . . . . . . . . . . . . 37 150 4.1.8. Secure Mailing Lists . . . . . . . . . . . . . . . . 37 151 4.1.9. Message Counter Signature . . . . . . . . . . . . . . 37 152 4.1.10. Certificate Binding . . . . . . . . . . . . . . . . . 37 153 4.1.11. Compressed Data . . . . . . . . . . . . . . . . . . . 38 154 4.2. Security Profile . . . . . . . . . . . . . . . . . . . . 38 155 4.2.1. S/MIME Cryptographic Message Syntax Content Types . . 38 156 4.2.2. S/MIME Triple Wrapping . . . . . . . . . . . . . . . 42 157 4.2.3. Organisation to Organisation Security . . . . . . . . 42 158 4.2.4. DKIM Digital Signatures . . . . . . . . . . . . . . . 42 159 4.2.5. Security Labels . . . . . . . . . . . . . . . . . . . 44 160 4.2.6. Message Header Fields . . . . . . . . . . . . . . . . 44 161 5. Requirements on Mail User Agents . . . . . . . . . . . . . . 45 162 5.1. Standards Compliance . . . . . . . . . . . . . . . . . . 45 163 5.2. Audit Trail and Logging . . . . . . . . . . . . . . . . . 46 164 6. Requirements on Mail Submission Agents . . . . . . . . . . . 47 165 6.1. Standards Compliance . . . . . . . . . . . . . . . . . . 47 166 6.2. Audit Trail and Logging . . . . . . . . . . . . . . . . . 48 167 7. Requirements on Mail Transfer Agents . . . . . . . . . . . . 49 168 7.1. Standards Compliance . . . . . . . . . . . . . . . . . . 49 169 7.2. Audit Trail and Logging . . . . . . . . . . . . . . . . . 50 170 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 171 9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 172 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 173 10.1. Normative References . . . . . . . . . . . . . . . . . . 51 174 10.2. Informative References . . . . . . . . . . . . . . . . . 56 175 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 57 176 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 178 1. Introduction 180 1.1. Overview 182 A Military Message Handling System (MMHS) processes formal messages 183 ensuring release, distribution, security, and timely delivery across 184 national and international strategic and tactical networks. The MMHS 185 Elements of Service are defined as a set of extensions to the ITU-T 186 X.400 (1992) international standards and are specified in STANAG 4406 187 Edition 2 or [ACP123]. This document specifies an MMHS Profile for 188 how a comparable messaging service can be provided using Email 189 Message Format [RFC5322], SMTP [RFC5321] and their extensions. 191 1.2. MMHS Profile Summary 193 This non-normative section provides a summary of the sections in this 194 document that specifies the MMHS Profile; refer to the sections that 195 follow for a normative specification of the MMHS Profile. 197 The fundamental purpose of STANAG 4406 Edition 2 or [ACP123] is to 198 define a common message service to be provided between all 199 participating organisations (or domains). STANAG 4406 Edition 2 and 200 [ACP123] achieve this by defining the Military Messaging Elements of 201 Service (EoS) that are required to be supported. [ACP123] defines 202 EoS as 'abstractions that describe features of a system for which the 203 user of that system has direct access'. Note for the purposes of 204 this MMHS Profile a 'user' can be described as: an end user; an 205 organisation (or domain); a Mail User Agent (MUA); a Mail Submission 206 Agent (MSA); a Mail Transfer Agent (MTA); or, Mail Delivery Agent 207 (MDA). 209 The MMHS Profile adopts the EoS defined in [ACP123]. 211 Section 3 provides a developer-friendly summary (Section 3.2) and a 212 detailed definition (Section 3.3, Section 3.4 and Section 3.5) that 213 specifies: 215 o the mandatory and optional EoS to be supported in order to claim 216 conformance to this MMHS Profile; and, 218 o the relevant IETF RFC Standard that provides the comparable EoS. 220 Section 4 describes generic security services independent of the 221 mechanisms used to provide the security (Section 4.1) and profiles 222 the use of Secure Multipurpose Internet Mail Extensions (S/MIME) 223 protocols ([RFC5751], [RFC5652] and [RFC2634]) and DomainKeys 224 Identified Mail (DKIM) Signatures ([RFC6376]) for implementing these 225 security services (Section 4.2). 227 In order to implement an MMHS a number of components are typically 228 deployed to support [ACP123]. The MMHS profile (defined in this 229 document) identifies the requirements on the following SMTP MMHS 230 components in order to claim conformance with the EoS specified in 231 Section 3 and the security services specified in Section 4 (Note: 232 additional SMTP extensions that provide additional SMTP functionality 233 but do not have equivalent [ACP123] EoS are also included in these 234 sections): 236 o Mail User Agent (Section 5); 238 o Mail Submission Agent (Section 6); and, 239 o Mail Transfer Agent (Section 7); 241 2. Conventions Used in This Document 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in [RFC2119]. 247 3. Elements of Service 249 3.1. Introduction 251 The military messaging elements of service are adopted from [ACP123]. 253 Many of these elements of service are derived from the X.400 254 standards upon which [ACP123] is based. 256 Note that some of the X.400 elements of service do not have an 257 equivalent in a SMTP messaging system. It is not the intention of 258 this profile to define additional SMTP functionality and consequently 259 a number of the military messaging elements of service are not 260 supported by this profile. 262 Specifically, the physical delivery, conversion (implicit or 263 explicit) and alternate recipient elements of service are not 264 supported by this profile. 266 This profile adopts, where appropriate, header fields that are 267 defined in [RFC2156] to support X.400 elements of service that 268 support military messaging elements of service. [RFC2156] has 269 already addressed the issue of conveying many of the X.400 elements 270 of service within an SMTP messaging system. 272 3.2. Profile Support 274 +----------------+-------+------+---------------------+-------------+ 275 | Element of | ACP12 | Supp | SMTP Standard | Header | 276 | Service | 3 Ref | ort | | Field or | 277 | | erenc | | | SMTP | 278 | | e | | | Parameter | 279 +----------------+-------+------+---------------------+-------------+ 280 | Access | 205a | MUST | [RFC4954], | N/A | 281 | Management | | | [RFC3207] | | 282 | (Section | | | | | 283 | 3.3.1) | | | | | 284 | | | | | | 285 | Content Type | 205b | MUST | [RFC6477], 3.2 | MMHS- | 286 | Indication | | | | Extended-Au | 287 | (Section | | | | thorization | 288 | 3.3.2) | | | | -Info | 289 | | | | | | 290 | Converted | 205c | N/A | N/A | N/A | 291 | Indication | | | | | 292 | (Section | | | | | 293 | 3.3.3) | | | | | 294 | | | | | | 295 | Delivery Time | 205d | MUST | [RFC5322], 3.6.7 | Received | 296 | Stamp | | | | | 297 | Indication | | | | | 298 | (Section | | | | | 299 | 3.3.4) | | | | | 300 | | | | | | 301 | MM | 205e | MUST | [RFC5322], 3.6.4 | Message-ID | 302 | Identification | | | | | 303 | (Section | | | | | 304 | 3.3.5) | | | | | 305 | | | | | | 306 | Message | 205f | MUST | [RFC3461], 4.4 | ENVID | 307 | Identification | | | | | 308 | (Section | | | | | 309 | 3.3.6) | | | | | 310 | | | | | | 311 | Non-delivery | 205g | MUST | [RFC3461], 4.1 | NOTIFY=FAIL | 312 | Notification | | | | URE | 313 | (Section | | | | | 314 | 3.3.7) | | | | | 315 | | | | | | 316 | Original | 205h | MAY | [RFC2156], 2.3.1.1 | Original- | 317 | Encoded | | | | Encoded-Inf | 318 | Information | | | | ormation- | 319 | Types (Section | | | | Types | 320 | 3.3.8) | | | | | 321 | | | | | | 322 | Submission | 205i | MUST | [RFC5322], 3.6.7 | Received | 323 | Time Stamp | | | | | 324 | Indication | | | | | 325 | (Section | | | | | 326 | 3.3.9) | | | | | 327 | | | | | | 328 | Typed Body | 205j | MUST | [RFC2045], 5 | Content- | 329 | (Section | | | | Type | 330 | 3.3.10) | | | | | 331 | | | | | | 332 | User/UA | 205k | N/A | N/A | N/A | 333 | Capabilities | | | | | 334 | Registration | | | | | 335 | (Section | | | | | 336 | 3.3.11) | | | | | 337 | | | | | | 338 | Alternate | 206a | N/A | N/A | N/A | 339 | Recipient | | | | | 340 | Allowed | | | | | 341 | (Section | | | | | 342 | 3.4.1) | | | | | 343 | | | | | | 344 | Alternate | 206b | N/A | N/A | N/A | 345 | Recipient | | | | | 346 | Assignment | | | | | 347 | (Section | | | | | 348 | 3.4.2) | | | | | 349 | | | | | | 350 | Authorizing | 206c | MUST | [I-D.melnikov-mmhs- | MMHS-Author | 351 | Users | | | authorizing-users] | izing-Users | 352 | Indication | | | | | 353 | (Section | | | | | 354 | 3.4.3) | | | | | 355 | | | | | | 356 | Auto-forwarded | 206d | MAY | [RFC2156], 2.3.1.2 | Autoforward | 357 | Indication | | | | ed | 358 | (Section | | | | | 359 | 3.4.4) | | | | | 360 | | | | | | 361 | Blind Copy | 206e | MUST | [RFC5322], 3.6.3 | Bcc | 362 | Recipient | | | | | 363 | Indication | | | | | 364 | (Section | | | | | 365 | 3.4.5) | | | | | 366 | | | | | | 367 | Body Part | 206f | N/A | N/A | N/A | 368 | Encryption | | | | | 369 | Indication | | | | | 370 | (Section | | | | | 371 | 3.4.6) | | | | | 372 | | | | | | 373 | Conversion | 206g | MAY | [RFC2156], 5.3.6 | Conversion | 374 | Prohibited | | | | | 375 | (Section | | | | | 376 | 3.4.7) | | | | | 377 | | | | | | 378 | Conversion | 206h | MAY | [RFC2156], 5.3.6 | Conversion- | 379 | Prohibition in | | | | With-Loss | 380 | Case of Loss | | | | | 381 | of Information | | | | | 382 | (Section | | | | | 383 | 3.4.8) | | | | | 384 | | | | | | 385 | Cross | 206i | MAY | [RFC5322], 3.6.4 | References | 386 | Referencing | | | | | 387 | Indication | | | | | 388 | (Section | | | | | 389 | 3.4.9) | | | | | 390 | | | | | | 391 | Deferred | 206j | MAY | [RFC4865], 3.6.4 | HOLDUNTIL | 392 | Delivery | | | | | 393 | (Section | | | | | 394 | 3.4.10) | | | | | 395 | | | | | | 396 | Deferred | 206k | N/A | N/A | N/A | 397 | Delivery | | | | | 398 | Cancellation | | | | | 399 | (Section | | | | | 400 | 3.4.11) | | | | | 401 | | | | | | 402 | Delivery | 206l | MUST | [RFC3461], 4.1 | NOTIFY=SUCC | 403 | Notification | | | | ESS | 404 | (Section | | | | | 405 | 3.4.12) | | | | | 406 | | | | | | 407 | Designation of | 206m | N/A | N/A | N/A | 408 | Recipient by | | | | | 409 | Directory Name | | | | | 410 | (Section | | | | | 411 | 3.4.13) | | | | | 412 | | | | | | 413 | Disclosure of | 206n | N/A | N/A | N/A | 414 | Other | | | | | 415 | Recipients | | | | | 416 | (Section | | | | | 417 | 3.4.14) | | | | | 418 | | | | | | 419 | DL Expansion | 206o | N/A | N/A | N/A | 420 | History | | | | | 421 | Indication | | | | | 422 | (Section | | | | | 423 | 3.4.15) | | | | | 424 | | | | | | 425 | DL Expansion | 206p | N/A | N/A | N/A | 426 | Prohibited | | | | | 427 | (Section | | | | | 428 | 3.4.16) | | | | | 429 | | | | | | 430 | Expiry Date | 206q | MUST | [RFC2156], 2.3.1.2 | Expires | 431 | Indication | | | | | 432 | (Section | | | | | 433 | 3.4.17) | | | | | 434 | | | | | | 435 | Explicit | 206r | N/A | N/A | N/A | 436 | Conversion | | | | | 437 | (Section | | | | | 438 | 3.4.18) | | | | | 439 | | | | | | 440 | Forwarded MM | 206s | MUST | [RFC2046], 5.2 | Content- | 441 | Indication | | | | Type: messa | 442 | (Section | | | | ge/rfc822 | 443 | 3.4.19) | | | | | 444 | | | | | | 445 | Grade of | 206t | MUST | [RFC6758] | MT-Priority | 446 | Delivery | | | | | 447 | Selection | | | | | 448 | (Section | | | | | 449 | 3.4.20) | | | | | 450 | | | | | | 451 | Hold for | 206u | N/A | N/A | N/A | 452 | Delivery | | | | | 453 | (Section | | | | | 454 | 3.4.21) | | | | | 455 | | | | | | 456 | Incomplete | 206v | MAY | [RFC2156], 2.3.1.2 | Incomplete- | 457 | Copy | | | | Copy | 458 | Indication | | | | | 459 | (Section | | | | | 460 | 3.4.22) | | | | | 461 | | | | | | 462 | Language | 206w | MAY | [RFC3282], 2 | Content- | 463 | Indication | | | | Language | 464 | (Section | | | | | 465 | 3.4.23) | | | | | 466 | | | | | | 467 | Latest | 206x | MUST | [RFC2852], 4 | BY | 468 | Delivery | | | | | 469 | Designation | | | | | 470 | (Section | | | | | 471 | 3.4.24) | | | | | 472 | | | | | | 473 | Multi- | 206y | MUST | [RFC5321], 2.1 | RCPT TO | 474 | destination | | | | | 475 | Delivery | | | | | 476 | (Section | | | | | 477 | 3.4.25) | | | | | 478 | | | | | | 479 | Multi-part | 206z | MUST | [RFC2046], 25.1.3 | Content- | 480 | Body (Section | | | | Type: multi | 481 | 3.4.26) | | | | part/mixed | 482 | | | | | | 483 | Non-receipt | 206aa | MUST | [RFC3798], 2.1 | Disposition | 484 | Notification | | | | -Notificati | 485 | Request | | | | on-To | 486 | Indication | | | | | 487 | (Section | | | | | 488 | 3.4.27) | | | | | 489 | | | | | | 490 | Obsoleting | 206ab | MAY | [RFC2156], 2.3.1.2 | Supersedes | 491 | Indication | | | | | 492 | (Section | | | | | 493 | 3.4.28) | | | | | 494 | | | | | | 495 | Originator | 206ac | MUST | [RFC5322], 3.6.2 | Sender | 496 | Indication | | | | | 497 | (Section | | | | | 498 | 3.4.29) | | | | | 499 | | | | | | 500 | Originator | 206ad | N/A | N/A | N/A | 501 | Requested | | | | | 502 | Alternate | | | | | 503 | Recipient | | | | | 504 | (Section | | | | | 505 | 3.4.30) | | | | | 506 | | | | | | 507 | Prevent of | 206ae | MAY | [RFC3461], 4.1 | NOTIFY=NEVE | 508 | Non-delivery | | | | R | 509 | Notification | | | | | 510 | (Section | | | | | 511 | 3.4.31) | | | | | 512 | | | | | | 513 | Primary and | 206af | MAY | [RFC5322], 3.6.3 | To, Cc | 514 | Copy | | | | | 515 | Recipients | | | | | 516 | Indication | | | | | 517 | (Section | | | | | 518 | 3.4.32) | | | | | 519 | | | | | | 520 | Receipt | 206ag | MUST | [RFC3798], 2.1 | Disposition | 521 | Notification | | | | -Notificati | 522 | Request | | | | on-To | 523 | Indication | | | | | 524 | (Section | | | | | 525 | 3.4.33) | | | | | 526 | | | | | | 527 | Redirection | 206ah | N/A | N/A | N/A | 528 | Disallowed By | | | | | 529 | Originator | | | | | 530 | (Section | | | | | 531 | 3.4.34) | | | | | 532 | | | | | | 533 | Redirection of | 206ai | N/A | [RFC5228], 4.2? | N/A | 534 | Incoming | | | Maybe? | | 535 | Messages | | | | | 536 | (Section | | | | | 537 | 3.4.35) | | | | | 538 | | | | | | 539 | Reply Request | 206ab | N/A | [RFC5322] - no | N/A | 540 | Indication | | | requesting | | 541 | (Section | | | mechanism | | 542 | 3.4.36) | | | | | 543 | | | | | | 544 | Replying MM | 206ak | MUST | [RFC2156], 3.6.4 | In-Reply-To | 545 | Indication | | | | | 546 | (Section | | | | | 547 | 3.4.37) | | | | | 548 | | | | | | 549 | Requested | 206al | N/A | N/A | N/A | 550 | Preferred | | | | | 551 | Delivery | | | | | 552 | Method | | | | | 553 | (Section | | | | | 554 | 3.4.38) | | | | | 555 | | | | | | 556 | Subject | 206am | MAY | [RFC2156], 3.6.5 | Subject | 557 | Indication | | | | | 558 | (Section | | | | | 559 | 3.4.39) | | | | | 560 | | | | | | 561 | Use of | 206an | N/A | N/A | N/A | 562 | Distribution | | | | | 563 | List (Section | | | | | 564 | 3.4.40) | | | | | 565 | | | | | | 566 | Primary | 212a | MUST | [RFC6477], 3.8 | MMHS- | 567 | Precedence | | | | Primary- | 568 | (Section | | | | Precedence | 569 | 3.5.1) | | | | | 570 | | | | | | 571 | Copy | 212b | MUST | [RFC6477], 3.9 | MMHS-Copy- | 572 | Precedence | | | | Precedence | 573 | (Section | | | | | 574 | 3.5.2) | | | | | 575 | | | | | | 576 | Message Type | 212c | MUST | [RFC6477], 3.10 | MMHS- | 577 | (Section | | | | Message- | 578 | 3.5.3) | | | | Type | 579 | | | | | | 580 | Exempted | 212d | MAY | [RFC6477], 3.1 | MMHS- | 581 | Addresses | | | | Exempted- | 582 | (Section | | | | Address | 583 | 3.5.4) | | | | | 584 | | | | | | 585 | Extended | 212e | MAY | [RFC6477], 3.2 | MMHS- | 586 | Authorization | | | | Extended-Au | 587 | Info (Section | | | | thorisation | 588 | 3.5.5) | | | | -Info | 589 | | | | | | 590 | Distribution | 212f | MAY | [RFC6477], 3.3 | MMHS- | 591 | Code (Section | | | | Subject- | 592 | 3.5.6) | | | | Indicator- | 593 | | | | | Codes | 594 | | | | | | 595 | Message | 212g | MAY | [RFC6477], 3.5 | MMHS- | 596 | Instructions | | | | Message-Ins | 597 | (Section | | | | tructions | 598 | 3.5.7) | | | | | 599 | | | | | | 600 | Clear Service | 212h | MAY | [RFC2634], 3 and | eSSSecurity | 601 | (Section | | | [RFC7444] | Label, SIO- | 602 | 3.5.8) | | | | Label | 603 | | | | | | 604 | Other | 212i | MAY | [RFC6477], 3.11 | MMHS-Other- | 605 | Recipient | | | 3.12 | Recipient- | 606 | Indicator | | | | Indicator- | 607 | (Section | | | | To, MMHS- | 608 | 3.5.9) | | | | Other- | 609 | | | | | Recipients- | 610 | | | | | Indicator- | 611 | | | | | CC | 612 | | | | | | 613 | Originator | 212j | MAY | [RFC6477], 3.7 | MMHS- | 614 | Reference | | | | Originator- | 615 | (Section | | | | Reference | 616 | 3.5.10) | | | | | 617 | | | | | | 618 | Use of Address | 212k | N/A | N/A | N/A | 619 | List (Section | | | | | 620 | 3.5.11) | | | | | 621 | | | | | | 622 | Handling | 213a | MAY | [RFC6477], 3.4 | MMHS- | 623 | Instructions | | | | Handling-In | 624 | (Section | | | | structions | 625 | 3.6.1) | | | | | 626 | | | | | | 627 | Pilot | 213b | N/A | N/A | N/A | 628 | Forwarded | | | | | 629 | (Section | | | | | 630 | 3.6.2) | | | | | 631 | | | | | | 632 | Corrections | 213c | N/A | N/A | N/A | 633 | (Section | | | | | 634 | 3.6.3) | | | | | 635 | | | | | | 636 | ACP 127 | 213d | MAY | [RFC6477], 3.13 | MMHS-Acp127 | 637 | Message | | | | -Message- | 638 | Identifier | | | | Identifier | 639 | (Section | | | | | 640 | 3.6.4) | | | | | 641 | | | | | | 642 | Originator | 213e | MAY | [RFC6477], 3.14 | MMHS- | 643 | PLAD (Section | | | | Originator- | 644 | 3.6.5) | | | | PLAD | 645 | | | | | | 646 | Codress | 213f | MAY | [RFC6477], 3.6 | MMHS- | 647 | Message | | | | Codress- | 648 | Indicator | | | | Message- | 649 | (Section | | | | Indicator | 650 | 3.6.6) | | | | | 651 | | | | | | 652 | ACP 127 | 213g | N/A | N/A | N/A | 653 | Notification | | | | | 654 | Request | | | | | 655 | (Section | | | | | 656 | 3.6.7) | | | | | 657 | | | | | | 658 | ACP 127 | 213h | N/A | N/A | N/A | 659 | Notification | | | | | 660 | Response | | | | | 661 | (Section | | | | | 662 | 3.6.8) | | | | | 663 | | | | | | 664 | Access Control | Annex | MAY | TBD | TBD | 665 | (Section | B, | | | | 666 | 4.1.1) | 7.1 | | | | 667 | | | | | | 668 | Authentication | Annex | MAY | [RFC5652], 5 | SignedData | 669 | of Origin | B, | | | | 670 | (Section | 7.2 | | | | 671 | 4.1.2) | | | | | 672 | | | | | | 673 | Non- | Annex | MAY | [RFC5652], 5 | SignedData | 674 | repudiation of | B, | | | | 675 | Origin | 7.3 | | | | 676 | (Section | | | | | 677 | 4.1.3) | | | | | 678 | | | | | | 679 | Message | Annex | MUST | [RFC5652], 5 | SignedData | 680 | Integrity | B, | | | | 681 | (Section | 7.4 | | | | 682 | 4.1.4) | | | | | 683 | | | | | | 684 | Message Data | Annex | MAY | [RFC5652], 6 | EnvelopedDa | 685 | Separation | B, | | | ta | 686 | (Section | 7.5 | | | | 687 | 4.1.5) | | | | | 688 | | | | | | 689 | Security | Annex | MUST | [RFC2634], 3 and | ESSSecurity | 690 | Labels | B, | | [RFC7444] | Label, SIO- | 691 | (Section | 7.6 | | | Label | 692 | 4.1.6) | | | | | 693 | | | | | | 694 | Non- | Annex | MAY | [RFC2634], 2 | ReceiptRequ | 695 | repudiation of | B, | | | est | 696 | Receipt | 7.7 | | | | 697 | (Section | | | | | 698 | 4.1.7) | | | | | 699 | | | | | | 700 | Secure Mailing | Annex | MAY | [RFC2634], 4 | MLExpansion | 701 | Lists (Section | B, | | | History | 702 | 4.1.8) | 7.8 | | | | 703 | | | | | | 704 | Message | Annex | MAY | [RFC5652], 11.4 | counterSign | 705 | Counter | B, | | | ature | 706 | Signature | 7.9 | | | | 707 | (Section | | | | | 708 | 4.1.9) | | | | | 709 | | | | | | 710 | Certificate | Annex | MAY | [RFC2634], | SigningCert | 711 | Binding | B, | | | ificate | 712 | (Section | 7.10 | | | | 713 | 4.1.10) | | | | | 714 | | | | | | 715 | Compressed | Annex | MAY | [RFC3274] | CompressedD | 716 | Data (Section | B, | | | ata | 717 | 4.1.11) | 7.11 | | | | 718 +----------------+-------+------+---------------------+-------------+ 720 3.3. Basic Elements of Service 722 3.3.1. Access Management 724 This element of service enables an Mail User Agent and an Mail 725 Transfer Agent to establish access and manage information associated 726 with access establishment. This includes the ability to identify and 727 validate the identity of the other. 729 Strong authentication in the bind operation is mandatory. Strong 730 authentication MUST be supported using SMTP Extension for 731 Authentication [RFC4954] and SMTP Extension for Secure SMTP over TLS 732 [RFC3207]. 734 While the list of recommended authentication mechanisms used with 735 SMTP Extension for Authentication would depend on operating 736 environment and would change over time, some recommendations are 737 provided here. For environment using X.509 certificates, use of SASL 738 EXTERNAL [RFC4422] authentication mechanism is RECOMMENDED. For 739 environment using Kerberos, use of SASL GSSAPI [RFC4752] 740 authentication mechanism is RECOMMENDED. Support for SCRAM [RFC5802] 741 is RECOMMENDED for environment using password based authentication. 743 3.3.2. Content Type Indication 745 This element of service enables an originating Mail User Agent to 746 indicate the type of each submitted message. In most cases, the 747 content type can be determined from the header fields that are 748 present. 750 A Military Message MUST be indicated using the MMHS-Extended- 751 Authorization-Info header field defined in [RFC6477]. 753 Note that the Content Type Indication element of service is not 754 supported by the MIME Content-Type header field defined in [RFC2045], 755 even though they have a similar name. The MIME Content-Type header 756 field is to describe only the data contained in the body of the 757 message, and not the whole message itself. 759 3.3.3. Converted Indication 761 This element of service indicates to each recipient UA (i.e., on per- 762 recipient basis) that the performed conversion on the Encoded 763 Information Types (EITs) within a delivered message. 765 Security requirements and mechanisms may not allow conversion to take 766 place within the MMHS. 768 However, messages entering the MMHS from a gateway (e.g., a civilian 769 X.400 domain, an ACP 127 tactical gateway) may carry the converted 770 indication. 772 The Converted Indication, if present, MUST use the X400-Received 773 header field as defined in [RFC2156]. 775 3.3.4. Delivery Time Stamp Indication 777 This element of service indicates to each recipient Mail User Agent 778 (i.e., on a per-recipient basis), the date and time at which the Mail 779 Transfer Agent delivered a message. 781 The delivery time stamp MUST be determined from the first Received 782 header field, defined in [RFC5322], present in the message. 784 3.3.5. MM Identification 786 This element of service enables cooperating Mail User Agents to 787 convey a globally unique identifier for each Military Message sent or 788 received. This identifier is used in subsequent messages to identify 789 the original Military Message. 791 A Military Message MUST be uniquely identified using the Message-ID 792 header field defined in [RFC5322]. 794 3.3.6. Message Identification 796 This element of service is used by Mail User Agents and the Mail 797 Transfer Agents to refer to a previously submitted message in 798 connection with other elements of service such as delivery and non- 799 delivery notification. 801 Message Identification MUST be specified by the Mail User Agent using 802 the ENVID parameter, as defined in [RFC3461]. The Mail Transfer 803 Agent MUST return the message identification in the Original- 804 Envelope-Id field of a message/delivery status as defined in 805 [RFC3461]. 807 3.3.7. Non-delivery Notification 809 This element of service allows a Mail User Agent to ask for the MTS 810 to notify the originator if a submitted message was not delivered to 811 the specified recipient Mail User Agent. The MMHS must, with a high 812 degree of certainty, deliver a message to the intended recipient(s). 813 If the system cannot deliver a message within a determined period of 814 time , a non-delivery report will be returned to the originating Mail 815 User Agent by the MMHS. The non-delivery report contains information 816 to enable it to be mapped to the appropriate message (i.e., the 817 message identification), recipient information, as well as 818 information about why the message could not be delivered. 820 Non-Delivery notifications MUST be generated in accordance with 821 [RFC3461]. 823 3.3.8. Original Encoded Information Types 825 This element of service enables the originating Mail User Agent to 826 indicate the various formats of the bodyparts of a message. 828 The Original Encoded Information Types, if present, MUST use the 829 Original-Encoded-Information-Types header field as defined in 830 [RFC2156]. 832 3.3.9. Submission Time Stamp Indication 834 This element of service enables the Message Transfer Agent to 835 indicate to the originating Mail User Agent and each recipient Mail 836 User Agent the date and time at which is which was submitted to the 837 Message Transfer Agent. 839 The Submission Time Stamp Indication MUST be determined from the last 840 Received header field, as defined in [RFC5322], present in the 841 message. Note that this is distinct from the Date header field, 842 defined in [RFC5322], which is more likely to be displayed by a 843 receiving Mail User Agent but which indicates the date and time at 844 which the originator of the message indicated that the message was 845 complete and ready to submitted. 847 3.3.10. Typed Body 849 This element of service allows the nature and attributes of the body 850 of the message to be conveyed along with the body. 852 The MMHS MUST support this element of service whereby: 854 o A Mail User Agent MUST support Multipurpose Internet Mail 855 Extensions (MIME) [RFC2045], [RFC2046], [RFC2047], [RFC2049], 856 [RFC2231] and [RFC3676]; and, 858 o A Mail Submission Agent MUST support SMTP Extension for 8-bit MIME 859 transport [RFC6152]. 861 3.3.11. User/UA Capabilities Registration 863 This element of service enables a MUA to indicate to the MMHS 864 unrestricted use of any or all of the following capabilities with 865 respect to received messages: 867 o the content type(s) of messages it is willing to accept; 869 o the maximum content length of a message it is willing to accept; 870 and 872 o the Encoded Information Type(s) of messages it is willing to 873 accept. 875 There is no current SMTP service that supports this element of 876 service. Therefore this profile does not support this element of 877 service. 879 However, this element of service MAY be supported by MUAs and other 880 MMHS components that provide proprietary mechanisms (i.e Directory 881 Services). 883 3.4. Optional Elements of Service 885 3.4.1. Alternate Recipient Allowed 887 This element of service enables an originating Mail User Agent to 888 specify that the message being submiited can be redirected to an 889 alternate recipient. Unless an originator specifically request that 890 an alternate recipient be disallowed, all Military Messages will 891 indicate that an alternate recipient is allowed. 893 There is no current SMTP service that supports allows the originator 894 to disallow the redirection of a message to an alternate recipient. 895 Therefore this profile does not support the Alternate Recipient 896 Allowed element of service. 898 3.4.2. Alternate Recipient Assignment 900 This element of service enables a receiving Mail User Agent to be 901 given the capability to have certain messages delivered to it for 902 which there is not an exact match between the recipient address 903 specified in the message and the valid addresses within the recipient 904 domain. This service allows a message that would otherwise be 905 undeliverable to be delivered to a "default mailbox" within the 906 recipient domain. 908 There is no current SMTP service that supports allows the Alternate 909 Recipient Assignment element of service. Therefore this profile does 910 not support the Alternate Recipient Assignment element of service. 911 Note that some Mail Transfer Agent products may provide propriertary 912 mechanisms that support the element of service. 914 3.4.3. Authorizing Users Indication 916 This element of service allows the originator to indicate to the 917 recipient the names or one or more persons who authorized the sending 918 of the messages. 920 The Authorizing Users Indication element of service MUST be 921 conformant with the Draft and Release using Internet Email 922 specification [I-D.melnikov-mmhs-authorizing-users]. In addition, 923 the Sender header field as defined in [RFC5322] (carrying the 924 Originator Indication) MUST also be present in accordance with 925 [RFC2156]. 927 3.4.4. Auto-forwarded Indication 929 This element of service allows a recipient to determine that the body 930 of an incoming Military Message contains a Military Message that has 931 been auto-forwarded by an autonomous Mail Submission Agent. This is 932 used to distinguish the incoming Military Message that contains a 933 Military Message that was manually forwarded by the original 934 recipient. If automatic forwarding of Military Messages is supported 935 by a Mail Submission Agent, then the Auto-forwarded Indication MUST 936 be supported on origination. 938 The Auto-forwared Indication MUST use the Autoforwarded header field, 939 as defined in [RFC2156]. 941 3.4.5. Blind Copy Recipient Indication 943 This element of service enable the originator to provide the address 944 of one or more additional intended recipients of the message being 945 sent. These names are not disclosed to the primary, copy or other 946 blind copy recipients. This service can be used to keep some 947 recipient names and addressed hidden from other recipients. This 948 service can be used to send a courtesy copy to drafters or reviewers 949 of a message, when internal information, such as who drafted or 950 reviewed the message, is not to be disclosed to the recipient(s). 951 Separate copies of the mesage MUST be submitted to the Mail Transfer 952 Agent for the open recipients (primary and copy recipients) and for 953 each blind copy recipient. The messages sent to each of blind copy 954 recipients MUST contain same MM Identification as the message sent to 955 the open recipients. 957 The Blind Copy Recipient Indication MUST use the Bcc header field, as 958 defined in [RFC5322]. 960 3.4.6. Body Part Encryption Indication 962 This element of service allows the originator to indicate to the 963 recipient that a particular body of the message has been sent 964 encrypted. 966 There is no current SMTP service that supports allows the Body Part 967 Encryption Indication element of service. Therefore this profile 968 does not support the Body Part Encryption Indication element of 969 service. 971 3.4.7. Conversion Prohibited 973 This element of service enables an originating Mail User Agent to 974 instruct the Mail Transfer Agent that the implicit conversion of the 975 military message should not be performed. 977 This element of service is not supported by an SMTP Mail Transfer 978 Agent. A Mail User Agent MAY use the Conversion header field, as 979 defined in [RFC2156] to control the conversion to an X.400 message at 980 a MIXER gateway and further within the X.400 domain at X.400 Mail 981 Transfer Agents. 983 3.4.8. Conversion Prohibition in Case of Loss of Information 985 This element of service enables and originating Mail User Agent to 986 instruct the Mail Transfer Agent that the implicit conversion of the 987 military message should not be performed, if such conversion would 988 result in the loss of information. 990 This element of service is not supported by an SMTP Mail Transfer 991 Agent. A Mail User Agent MAY use the Conversion-With-Loss header 992 field, as defined in [RFC2156] to control the conversion to an X.400 993 message at a MIXER gateway and further within the X.400 domain at 994 X.400 Mail Transfer Agents. 996 3.4.9. Cross Referencing Indication 998 This element of service allows the originator to associate the 999 globally unique identifiers of one or more other messages with the 1000 message being sent. This enables the recipient's Mail User Agent, 1001 for example, to retrieve a copy of the referenced messages. 1003 The Cross Referencing Indication MUST use the References header 1004 field, as defined in [RFC5322]. 1006 3.4.10. Deferred Delivery 1008 This element of service enables an originating Mail User Agent to 1009 instruct the Mail Transfer Agent that a military message being 1010 submitted shall be delivered no sooner than a specified date and 1011 time. When this service is requested, it MUST be logged for audit 1012 and tracing purposes. 1014 Deferred Delivery MUST be specified in accordance with [RFC4865]. 1016 3.4.11. Deferred Delivery Cancellation 1018 This element of service enables an orginating MUA to instruct the MTA 1019 to cancel a previously submitted military message that contained a 1020 Deferred Delivery date and time. 1022 Deferred Delivery Cancellation is not supported by this profile. 1024 3.4.12. Delivery Notification 1026 This element of service enables the originating MUA to request that 1027 the originating MUA be explicitly notified when a submitted military 1028 message has been successfully delivered to a recipient MUA. This 1029 notification is conveyed by a delivery report. The delivery report 1030 is related to the submitted message by means of a message identifier 1031 and includes the date and time of delivery. Receipt of a delivery 1032 report at the originating MUA results in the the generation of a 1033 delivery notification to the originator. In the case of multi- 1034 destination military messages, this service shall be selectable on a 1035 per recipient basis. 1037 This element of service MUST be supported using the NOTIFY parameter 1038 of the ESMTP RCPT command with as value of SUCCESS, as defined in 1039 [RFC3461]. 1041 Note that while this element of service is selectable on a per 1042 recipient basis, an MUA MAY only allow it to be selected on a per 1043 message basis. 1045 3.4.13. Designation of Recipient by Directory Name 1047 This element of service enables an originating UA to use, on a per- 1048 recipient basis, a directory name in place of an individual 1049 recipient's address. This implies the support of a directory 1050 service. The directory name must be translated to an email address 1051 for delivery to take place. However, the directory lookup may take 1052 place at the MTA rather than at the MUA. 1054 Designation of Recipient by Directory Name is not suppoted by this 1055 profile. 1057 However the designation of a recipient by a directory name MAY be 1058 supported by a MUA that can retrieve an address from a directory 1059 service. 1061 3.4.14. Disclosure of Other Recipients 1063 This element of service enables the originating MTA to instruct the 1064 MTS to disclose the address of all other recipient of a multi- 1065 recipient military message to each recipient MUA, upon delivery of 1066 the message. The addresses disclosed are as supplied by the 1067 originating MUA or the results of address list expansion. 1069 Disclosure of Other Recipients is not supported by this profile. 1071 3.4.15. DL Expansion History Indication 1073 This element of service provides information to a recipient about the 1074 DL(s) that resulted in the message being delivered to this recipient. 1075 This element of service also provides a mechanism to protect against 1076 potential nested DL looping. 1078 DL Expansion History Indication is not supported by this profile. 1080 The DL-Expansion-History header defined in [RFC2156] SHALL NOT be 1081 used. DL-Expansion-History header MAY be present in messages 1082 gatewayed from X.400. 1084 3.4.16. DL Expansion Prohibited 1086 This element of service allows an originating user to specify that if 1087 any of the recipient names can directly, or by reassignment, refer to 1088 a distribution, then no expansion of the distribution shall occur. 1089 Instead, a non-delivery notification shall be returned to the 1090 originating Mail User Agent. 1092 DL Expansion Prohibited is not supported by this profile. 1094 3.4.17. Expiry Date Indication 1096 This element of service allows the originator to indicate to the 1097 recipient the date and time after which the message is considered 1098 invalid. The intent of this element of service is to state the 1099 originator's assessment of the current applicability of a message. 1100 If the Expiry Date Indication is present, it shall be displayed to 1101 the recipients(s) to indicate the time after which this message 1102 should be longer be acted upon. It is left to the discretion of the 1103 recipient as to whether or not the message is discarded. 1105 The Expiry Date Indication element of service SHALL use the Expires 1106 header field, as defined in [RFC2156]. 1108 3.4.18. Explicit Conversion 1110 This element of service enables an originating MUA to request, on a 1111 per-recipient basis, that the MTA perform a specified Encoded 1112 Information Type conversion. 1114 Explicit Conversion is not supported by this profile. 1116 3.4.19. Forwarded MM Indication 1118 This element of service allows a message, plus its delivery 1119 information to be sent as a body part inside another message. In a 1120 multi-part body the forwarded message may be one of serveral body 1121 parts of various types. 1123 The Forwarded MM Indication element of service, if supported by the 1124 MMHS, SHALL use the Content-Type header field, as defined in 1125 [RFC2045] with the value "message/rfc822" and use the Content Type 1126 Indication , as defined in Section 3.3.2, within the headers of the 1127 embedded message. 1129 Note that the Content-Type header field may be embedded within an 1130 outer "multipart/mixed" MIME body where, for example, the fowarding 1131 Military Message also includes delivery information, covering text or 1132 additional attachments. 1134 3.4.20. Grade of Delivery Selection 1136 This element of service enables an originating MUA to request that 1137 transfer through the MMHS take place at a selected priority. The 1138 time periods defined for each grade of delivery must be specified in 1139 an organisation (or domain) policy and bilaterally agreed between 1140 participating organisations (or domains). 1142 The Grade of Delivery Selection element of service MUST be supported 1143 by the MMHS, using the MT-Priority header field, as defined in 1144 [RFC6758]. 1146 The Grade of Delivery Selection MT-Priority header field value MUST 1147 be derived from the Primary Precedence (Section 3.5.1) MMHS-Primary- 1148 Precedence [RFC6477] header field value. 1150 The MMHS message may have no primary recipients (therefore no Primary 1151 Precedence); the Grade of Delivery Selection MT-Priority header field 1152 value MUST be derived from the Copy Precedence (Section 3.5.2) MMHS- 1153 Copy-Precedence [RFC6477] header field value. 1155 The mapping between the Grade of Delivery Selection MT-Priority 1156 header field values and the Primary Precedence MMHS-Primary- 1157 Precedence header field values (and subsequently the Copy Precedence 1158 MMHS-Copy-Precedence header field values) MUST support the 1159 "STANAG4406" Priority Assignment Policy specified in [RFC6758] 1160 Appendix A. 1162 The Grade of Delivery Selection MT-Priority doesn't have to be 1163 displayed to the recipient by the MUA, as an indication of the Grade 1164 of Delivery selection element of service is provided to the recipient 1165 MUA by the Primary and Copy Precedence. 1167 3.4.21. Hold for Delivery 1169 This element of service enables a recipient MUA to request that the 1170 MTA hold its MMHS messages and returning notifications for delivery 1171 until a later time. The MUA can indicate to the MTA when it is 1172 unavailable to take delivery of messages and notifications, and also, 1173 when it is again ready to accept delivery of messages and 1174 notifications from the MTA. The MTA can indicate to the MUA that 1175 messages are waiting due to the criteria the MUA established for 1176 holding messages. The MMHS message will be held until the maximum 1177 delivery time for that MMHS message expires, unless the recipient 1178 releases the hold prior to its expiry. 1180 There is no current SMTP service that supports the Hold for Delivery 1181 element of service. Therefore this profile does not support this 1182 element of service. 1184 However, this element of service MAY be partially supported by MTA 1185 products that provide proprietary mechanisms to schedule delivery 1186 times based on MMHS message size and MMHS message priority. 1188 3.4.22. Incomplete Copy Indication 1190 This element of service allows an originator to indicate that this 1191 MMHS message is an incomplete copy of a MMHS message with the same 1192 Message-ID header field in that one or more body parts or header 1193 fields of the original MMHS message are absent. 1195 The Incomplete Copy Indication element of service MAY be supported by 1196 the MMHS, using the Incomplete-Copy header field, as defined in 1197 [RFC2156]. 1199 3.4.23. Language Indication 1201 This element of service enables an originating MUA to indicate the 1202 language type(s) of a submitted message. 1204 The Language Indication element of service MAY be supported by the 1205 MMHS, using the Content-Language header field, as defined in 1206 [RFC3282]. 1208 3.4.24. Latest Delivery Designation 1210 This element of service enables an originating MUA to specify the 1211 latest time by which the MMHS message is to be delivered. If the MTA 1212 cannot deliver by the time specified, the MMHS message is canceled 1213 and a non-delivery report returned to the originating MUA. 1215 The Latest Delivery Designation element of service MUST be supported 1216 by the MMHS as defined in the Deliver By SMTP extension [RFC2852]. 1218 3.4.25. Multi-destination Delivery 1220 This element of service allows an originating MUA to specify that a 1221 message being submitted is to be delivered to more than one recipient 1222 MUA. This does not imply simultaneous delivery to all specified 1223 recipient MUAs. 1225 The Multi-destination Delivery element of service is supported by the 1226 SMTP RCPT command as defined in [RFC5321]. 1228 3.4.26. Multi-part Body 1230 This element of service allows an originator to send a message that 1231 is partitioned into several parts. The nature and attributes, or 1232 type, of each body part are conveyed along with the body part. This 1233 enables the multiple parts to be of different encoded information 1234 types. 1236 The MMHS MUST support this element of service whereby: 1238 o A Mail User Agent MUST support Multipurpose Internet Mail 1239 Extensions (MIME) [RFC2045], [RFC2046], [RFC2047], [RFC2049] and 1240 [RFC2231]; and, 1242 o A Mail Submission Agent MUST support SMTP Extension for 8-bit MIME 1243 transport [RFC6152]. 1245 3.4.27. Non-receipt Notification Request Indication 1247 This element of service allows the originator to ask, on a per- 1248 recipient basis, for notification if the MMHS message is deemed 1249 unreceivable by any of the recipients. 1251 The Non-Receipt Notification Request Indication MUST be supported by 1252 the MMHS, using the Disposition-Notification-To header field as 1253 defined in [RFC3798]. 1255 In the case where the Non-Receipt Notification Request Indication 1256 element of service is required for a subset of the recipients the MSA 1257 MUST: submit a MMHS message to those recipients that a non-receipt 1258 notification is requested with a Disposition-Notification-To header 1259 field; and, submit a MMHS message(s) to those recipients that a non- 1260 receipt notification is not requested without a Disposition- 1261 Notification-To header field. 1263 Note that while this element of service is selectable on a per 1264 recipient basis, an MUA MAY only allow it to be selected on a per 1265 message basis. 1267 Note that this element of service will be supported in conjunction 1268 with the Receipt Notification Request Indication as profiled in 1269 Section 3.4.33. 1271 3.4.28. Obsoleting Indication 1273 This element of service allows the originator to indicate to the 1274 recipient that one or more previously sent MMHS messages are 1275 obsolete. The intention of this element of service is for the MUA to 1276 display to the user reading the original MMHS message that the 1277 original MMHS message is obsolete. It is the responsibility of the 1278 user for discarding the original MMHS message. 1280 The Obsoleting Indication element of service MAY be supported by the 1281 MMHS, using the Supersedes header field, as defined in [RFC2156]. 1283 3.4.29. Originator Indication 1285 The Originator Indication MUST use the MMHS-Authorizing-Users header 1286 field, as defined in [I-D.melnikov-mmhs-authorizing-users], when the 1287 Authorizing Users Indication is present in the message and the Sender 1288 header field, as defined in [RFC5322], when the Authorizing Users 1289 Indication is not present in the message. 1291 This conditional use of different header fields is required to 1292 support interoperability with [ACP123] and [STANAG-4406] X.400 1293 systems that utilise a MIXER compliant gateway, [RFC2156]. 1295 3.4.30. Originator Requested Alternate Recipient 1297 This element of service enables the originating MUA to specify, for 1298 each intended recipient, one alternate recipient to whom the MTA can 1299 deliver the message, if delivery to the intended recipient is not 1300 possible. This service allows a MMHS message that would otherwise be 1301 delayed or non-delivered to be delivered to an alternative message 1302 recipient. 1304 There is no current SMTP service that supports the Originator 1305 Requested Alternate Recipient element of service. Therefore this 1306 profile does not support this element of service. Note that some 1307 MTAs may provide propriertary mechanisms that support this element of 1308 service. 1310 3.4.31. Prevention of Non-delivery Notification 1312 This element of service enables an originating MUA to instruct a MTA 1313 not to return a non-delivery report to the originating MUA in the 1314 event that the message being submitted is judged undeliverable. 1316 This element of service MUST be supported by the MMHS, using the 1317 NOTIFY parameter of the ESMTP RCPT command with as value of NEVER, as 1318 defined in [RFC3461]. 1320 Note that while this element of service is selectable on a per 1321 recipient basis, an MUA MAY only allow it to be selected on a per 1322 message basis. 1324 3.4.32. Primary and Copy Recipients Indication 1326 Primary and Copy recipients, within the MMHS, are known as action and 1327 information addressees, respectively. A primary recipient has a 1328 responsibility to act upon a delivered MMHS message, whereas a Copy 1329 recipient has been sent the MMHS message for information purposes 1330 only. 1332 The Primary and Copy Recipients Indication element of service MUST be 1333 supported by the MMHS, using the To and Cc header fields, 1334 respectively, as defined in [RFC5322]. 1336 3.4.33. Receipt Notification Request Indication 1338 This element of service allows the originator of a MMHS message to 1339 request, on a per-recipient basis, for notification when a particular 1340 MMHS message is received. The recipient MUA MUST prominently display 1341 the request for this element of service and permit the recipient to 1342 honour the request or reject the request. 1344 The Receipt Notification Request Indication MUST be supported by the 1345 MMHS, using the Disposition-Notification-To header field as defined 1346 in [RFC3798]. 1348 In the case where the Receipt Notification Request Indication element 1349 of service is required for a subset of the recipients the MUA MUST: 1350 submit a MMHS message to those recipients that a receipt notification 1351 is requested with a Disposition-Notification-To header field; and, 1352 submit a MMHS message(s) to those recipients that a receipt 1353 notification is not requested without a Disposition-Notification-To 1354 header field. 1356 Note that while this element of service is selectable on a per 1357 recipient basis, an MUA MAY only allow it to be selected on a per 1358 message basis. 1360 Note that this element of service will be supported in conjunction 1361 with the Receipt Notification Request Indication as profiled in 1362 Section 3.4.27. 1364 In the case where the MMHS supports S/MIME security services profiled 1365 in Section 4 the originating MUA MAY use the Non-repudiation of 1366 Receipt element of service as specified in Section 4.1.7. 1368 3.4.34. Redirection Disallowed by Originator 1370 This element of service enables an originating MUA to instruct the 1371 MTA that redirection should not be applied to a particular submitted 1372 MMHS message. 1374 There is currently no SMTP service that supports this element of 1375 service. Therefore, the Redirection Disallowed by Originator element 1376 of service is not supported by this profile. 1378 3.4.35. Redirection of Incoming Messages 1380 This element of service enables a MUA to instruct the MTA to redirect 1381 incoming MMHS messages addressed to it, to another MUA or to an 1382 Address List (AL), for a specified period of time, or until revoked. 1384 There is currently no SMTP service that supports this element of 1385 service. Therefore the Redirection of Incoming Messages element of 1386 service is not supported by this profile. However, note that some 1387 MTA and/or MDA products are able to enforce a local security policy 1388 supporting this element of service with proprietary mechanisms. 1390 3.4.36. Reply Request Indication 1392 This element of service allows the originator to request, on a per- 1393 recipient basis, that a recipient send a message in reply to the MMHS 1394 message that carries the request. The originator can also optionally 1395 specify the date by which any reply should be sent and the names of 1396 one or more users and ALs who the originator requests be included 1397 among the preferred recipients of any reply. 1399 The Reply Request Indication element of service is not supported by 1400 this profile. 1402 This element of service MAY be procedurally defined by a MMHS. Hence 1403 the Reply Request Indication MAY be supported by including the 1404 request within the body of the MMHS message. 1406 Blind Copy recipients of the MMHS message, that includes support for 1407 this element of service within the message body, SHOULD be careful to 1408 consider the recipients of the reply MMHS message honoring the Blind 1409 Copy Recipient Indication element of service profiled in 1410 Section 3.4.5. 1412 3.4.37. Replying MM Indication 1414 This element of service allows the originator of a MMHS message to 1415 indicate to the recipients that the message is being sent in reply to 1416 another MMHS message. 1418 The Replying MM Indication element of service MAY be supported by the 1419 MMHS, using the In-Reply-To header field as defined in [RFC5322]. 1421 3.4.38. Requested Preferred Delivery Method 1423 This element of service allows an originator to request, on a per- 1424 recipient basis, the preference of method or methods of delivery. 1426 Requested Preferred Delivery Method is not supported by this profile. 1428 3.4.39. Subject Indication 1430 This element of service allows the originator to indicate to the 1431 recipient(s) a user specified short description of the message. 1433 The Subject Indication element of service MAY be supported by the 1434 MMHS, using the Subject header field as defined in [RFC5322]. 1436 3.4.40. Use of Distribution List 1438 This element of service enables an origintaing MUA to specify, on a 1439 per-recipient basis, a Distribution List in place of all the 1440 individual recipients (users or nested DLs). The MTA will add the 1441 member of the list to the recipients and send it to those members. 1442 Support for this service shall be optional. Determination of where 1443 in the MMHS the DL expansion takes place may be the subject of 1444 national policy based upon security requirements. National policy 1445 may also dictate the preferential support of the Use of Address List 1446 (Section 3.5.11) and Exempted Addsresses (Section 3.5.4)Elements of 1447 Service instead of the Use of Distribution List Element of Service. 1449 Use of Distribution List is not supported by this profile. 1451 3.5. Military Elements of Service 1453 This section profiles the MMHS Header Fields for use in the MMHS as 1454 specified in [RFC6477]. 1456 3.5.1. Primary Precedence 1458 The MMHS-Primary-Precedence header field defined in [RFC6477] MUST be 1459 supported and included by the MMHS if the military message contains 1460 "To:" ("action") addresses. 1462 3.5.2. Copy Precedence 1464 The MMHS-Copy-Precedence header field defined in [RFC6477] MUST be 1465 supported and included by the MMHS if the military message contains 1466 "Cc:" or "Bcc:" ("information") addresses. 1468 3.5.3. Message Type 1470 The MMHS-Message-Type header field defined in [RFC6477] MUST be 1471 supported by the MMHS. 1473 3.5.4. Exempted Addresses 1475 The MMHS-Exempted-Address header field defined in [RFC6477] MAY be 1476 supported by the MMHS. 1478 3.5.5. Extended Authorization Info 1480 The MMHS-Extended-Authorisation-Info header field defined in 1481 [RFC6477] MUST be supported and included by the MMHS in a military 1482 message. 1484 3.5.6. Distribution Code 1486 The MMHS-Subject-Indicator-Codes header field defined in [RFC6477] 1487 MUST be supported by the MMHS. 1489 3.5.7. Message Instructions 1491 The MMHS-Message-Instructions header field defined in [RFC6477] MAY 1492 be supported by the MMHS. 1494 3.5.8. Clear Service 1496 This element of service indicates to the recipient that the military 1497 message containing classified information has been transmitted over 1498 non-secure communications links. This element of service, if 1499 permitted by the security policy, MAY be supported by using the 1500 printable string "CLEAR" in the privacy mark component of the 1501 security label (see Section 4.1.6) along with an appropriate security 1502 policy identifier. If this element of service is supported by the 1503 MMHS, the MUA MUST prominently display to the user that the military 1504 message has been transmitted over non-secure communication links. 1506 3.5.9. Other Recipient Indicator 1508 The MMHS-Other-Recipients-Indicator-To and MMHS-Other-Recipients- 1509 Indicator-CC header fields defined in [RFC6477] MAY be supported by 1510 the MMHS. 1512 3.5.10. Originator Reference 1514 The MMHS-Originator-Reference header field defined in [RFC6477] MAY 1515 be supported by the MMHS. 1517 3.5.11. Use of Address List 1519 The Address List Indication element of service is not supported by 1520 this profile. 1522 3.6. Transition Elements of Service 1524 3.6.1. Handling Instructions 1526 The MMHS-Handling-Instructions header field defined in [RFC6477] MAY 1527 be supported by the MMHS only to support interoperability with ACP 1528 127 systems. 1530 3.6.2. Pilot Forwarded 1532 The Pilot Forwarded element of service is not supported by this 1533 profile. 1535 3.6.3. Corrections 1537 The Corrections element of service is not supported by this profile. 1539 3.6.4. ACP 127 Message Identifier 1541 The MMHS-Acp127-Message-Identifier header field defined in [RFC6477] 1542 MAY be supported by the MMHS only to support interoperability with 1543 ACP 127 systems. 1545 3.6.5. Originator PLAD 1547 The MMHS-Originator-PLAD header field defined in [RFC6477] MAY be 1548 supported by the MMHS only to support interoperability with ACP 127 1549 systems. 1551 3.6.6. Codress Message Indicator 1553 The MMHS-Codress-Message-Indicator header field defined in [RFC6477] 1554 MAY be supported by the MMHS only to support interoperability with 1555 ACP 127 systems. 1557 3.6.7. ACP 127 Notification Request 1559 The ACP 127 Notification Request element of service is not supported 1560 by this profile. 1562 3.6.8. ACP 127 Notification Response 1564 The ACP 127 Notification Response element of service is not supported 1565 by this profile. 1567 4. Security Services 1569 An MMHS MAY support security services. The security services 1570 specified in this profile are based on the Secure Multipurpose 1571 Internet Mail Extensions (S/MIME) protocols and DomainKeys Identified 1572 Mail (DKIM) Signatures specified in [RFC6376]. The S/MIME protocols 1573 Message Specification [RFC5751], Cryptographic Message Syntax 1574 [RFC5652] and Enhanced Security Services for S/MIME [RFC2634] specify 1575 a consistent way to securely send and receive MIME messages providing 1576 end to end integrity, authentication, non-repudiation and 1577 confidentiality. DKIM's primary purpose is to define an 1578 organization-level digital signature authentication framework for 1579 Internet email, using public key cryptography and using the domain 1580 name service as its key server technology. However, it is possible 1581 to administer DKIM to support user-level signature granularity. This 1582 section describes the generic security services and profiles the use 1583 of [RFC5751], [RFC5652], [RFC2634] and [RFC6376]. 1585 4.1. General Security Elements of Service 1587 The general security services and implementation requirements for 1588 providing these security services for an MMHS are detailed below. 1590 4.1.1. Access Control 1592 The Access Control security service provides a means of enforcing the 1593 authorization of users to originate and receive messages. Access 1594 controls are performed in each MMHS domain in accordance with the 1595 security policy in force. MMHS systems MAY enforce their own native 1596 security policies, plus any other security policies that have been 1597 bilaterally agreed. 1599 An MMHS providing the access control service MUST perform access 1600 control decisions based on comparing the sensitivity information 1601 conveyed in a security label (Section 4.1.6) with a user's 1602 authorizations. 1604 4.1.2. Authentication of Origin 1606 The Authentication of Origin security service provides assurance that 1607 the message was originated by the user indicated as the sender by 1608 digitally signing the message. However, it must be noted that the 1609 implementation of the MMHS security services is dependent upon the 1610 security and assurance requirements that are to be met by those MMHS 1611 security services. As such, the identity of the signer of the MMHS 1612 message may be the user, the role the user is performing or the 1613 organization (or domain) the user belongs to. 1615 If the MMHS provides security services it MUST support the 1616 Authentication of Origin service. 1618 The MMHS SHOULD implement this service on origination supporting the 1619 SignedData content type (profiled in Section 4.2.1.2) to apply a 1620 digital signature to a MMHS message or, in a degenerate case where 1621 there is no signature information, to convey certificates. 1623 Alternatively the MMHS MAY implement this service on origination 1624 supporting DKIM (profiled in Section 4.2.4) to apply a digital 1625 signature to a MMHS message. 1627 On reception the MMHS MUST support verification of S/MIME and DKIM 1628 digital signatures. 1630 4.1.3. Non-repudiation of Origin 1632 The Non-repudiation of Origin security service provides the recipient 1633 with evidence that demonstrates, to a third-party, who originated the 1634 message, and will protect against any attempt by the message 1635 originator to falsely deny having sent the message. However, it must 1636 be noted that the implementation of the MMHS security services is 1637 dependent upon the security and assurance requirements that are to be 1638 met by those MMHS security services. As such, the identity of the 1639 signer of the MMHS message may be the user, the role the user is 1640 performing or the organization (or domain) the user belongs to. 1642 If the MMHS provides security services it MUST support the Non- 1643 repudiation of Origin service. 1645 The MMHS SHOULD implement this service on origination as profiled in 1646 Section 4.2.1.2. 1648 Alternatively the MMHS MAY implement this service on origination 1649 supporting DKIM (profiled in Section 4.2.4) to apply a digital 1650 signature to a MMHS message. 1652 On reception the MMHS MUST support verification of S/MIME and DKIM 1653 digital signatures. 1655 4.1.4. Message Integrity 1657 The Message Integrity security service provides a method of ensuring 1658 the content that was received by the recipient(s) is the same as that 1659 which was sent by the originator. However, it must be noted that the 1660 implementation of the MMHS security services is dependent upon the 1661 security and assurance requirements that are to be met by those MMHS 1662 security services. As such, the identity of the signer of the MMHS 1663 message may be the user, the role the user is performing or the 1664 organization (or domain) the user belongs to. 1666 If the MMHS provides security services it MUST support the Message 1667 Integrity service. 1669 The MMHS SHOULD implement this service on origination as profiled in 1670 Section 4.2.1.2. 1672 Alternatively the MMHS MAY implement this service on origination 1673 supporting DKIM (profiled in Section 4.2.4) to apply a digital 1674 signature to a MMHS message. 1676 On reception the MMHS MUST support verification of S/MIME and DKIM 1677 digital signatures. 1679 4.1.5. Message Data Separation 1681 The Message Data Separation security service protects against 1682 unauthorized disclosure of the message, and separates data contained 1683 in one message from that contained in another message. This service 1684 can help to enforce need to know restrictions, or enables multiple 1685 different user communities to share the same secure network. The 1686 service is independent of the network and systems transporting the 1687 message. 1689 The MMHS MAY implement this service supporting the EnvelopedData 1690 content type (profiled in Section 4.2.1.3) to apply privacy 1691 protection to a message. A sender needs to have access to a public 1692 key for each intended message recipient to use this service. This 1693 content type does not provide authentication. 1695 4.1.6. Security Labels 1697 The Security Label security service provides a method for associating 1698 security labels with objects in the MMHS. This then allows a 1699 security policy to define what entities can handle messages 1700 containing associated security labels. The security label associated 1701 with a message MUST indicate the security policy to be followed along 1702 with the sensitivity, compartments, and other handling caveats 1703 associated with the message. This service can be used for purposes 1704 such as access control or a source of routing information. 1706 If the MMHS supports security services then the MMHS MUST implement 1707 this service as profiled in Section 4.2.5. 1709 4.1.7. Non-repudiation of Receipt 1711 The Non-repudiation of Receipt security service provides the 1712 originator with evidence that demonstrates, to a third-party, who 1713 received the message, and will protect against any attempt by the 1714 message recipient to falsely deny having received the message. This 1715 evidence is the signed receipt, which includes a digital signature 1716 and the certificates necessary to verify it. 1718 The MMHS MAY implement this service supporting the ReceiptRequest 1719 attribute as specified in [RFC2634] Section 2. 1721 4.1.8. Secure Mailing Lists 1723 The Secure Mailing Lists security service allows a Mail List Agent 1724 (MLA) to take a single message, perform recipient-specific security 1725 processing, and then redistributes the message to each member of the 1726 Address List (AL) or Mail List (ML). 1728 The MMHS MAY implement this service supporting the mlExpansionHistory 1729 attribute as specified in [RFC2634] Section 4. 1731 4.1.9. Message Counter Signature 1733 The Message Counter Signature security service allows multiple 1734 signatures to be applied to the original signature value in a 1735 sequential manner. Thus, the Message Counter-signature service 1736 allows supervising users or release authorities to countersign for an 1737 originator without invalidating the original signature. 1739 The MMHS MAY implement this service supporting the countersignature 1740 attribute as specified in [RFC5652] Section 11.4. 1742 4.1.10. Certificate Binding 1744 The Certificate Binding security service allows for a certificate, 1745 which is sent with the message to be cryptographically bound to the 1746 message. 1748 The MMHS MAY implement this service supporting the SigningCertificate 1749 attribute as specified in [RFC2634] Section 5. The 1750 SigningCertificate attribute SHOULD only contain the leaf end-user 1751 certificate except where some prior agreement (possibly bilateral) 1752 exists to ensure that path validation is not adversely affected. 1753 Differing treatment in [RFC2634] Section 5.3, paragraph 3 avoids 1754 impact to path validation if only the leaf certificate is included. 1756 4.1.11. Compressed Data 1758 The Compressed Data security service reduces message size, which 1759 helps to protect MMHS availability and may provide an element of 1760 robustness in the event of denial of service attacks. 1762 If the MMHS provides security services it MAY support the Compressed 1763 Data service. 1765 The MMHS SHOULD include support for the Compressed Data content type 1766 on origination profiled in Section 4.2.1.4. 1768 Alternatively the MMHS MAY support the application/zlib and 1769 application/gzip MIME media types on origination as defined in 1770 [RFC6713]. 1772 On reception the MMHS MUST support the Compressed Data content type, 1773 application/zlib media type and application/gzip media type. 1775 4.2. Security Profile 1777 This section profiles the use of the S/MIME protocols [RFC5751], 1778 [RFC5652] and [RFC2634] and DKIM protocol [RFC6376] for adding 1779 cryptographic services to the MMHS. The relevant sections of 1780 [RFC5751], [RFC5652], [RFC2634] and [RFC6376] are listed with further 1781 clarifications and amendments specific to the implementation of an 1782 MMHS conformant with this profile. 1784 This security profile is aligned with the "Profile for the Use of the 1785 Cryptographic Message Syntax (CMS) and Enhanced Security Services 1786 (ESS) for S/MIME", [STANAG-4631]. 1788 In order for participating organisations (or domains) to obtain 1789 secure interoperability additional bilateral agreements on the 1790 labeling, cryptographic algorithms and Public Key Infrastructure 1791 (PKI) need to be achieved. 1793 4.2.1. S/MIME Cryptographic Message Syntax Content Types 1795 If the MMHS supports the S/MIME protocols for implementing the 1796 security services then the MMHS MUST support the Data, SignedData, 1797 EnvelopedData, and CompressedData content types as specified in 1798 [RFC5751]. 1800 In accordance with [RFC5652] ContentInfo MUST be supported to 1801 encapsulate the outer most SignedData or EnvelopedData content type. 1802 Conventions for inner wrappers MUST comply with [RFC5751]. 1804 The clarifications and refinements are as follows: 1806 o The ContentInfo contentType field MUST be supported. 1808 o The ContentInfo content field MUST be supported. 1810 4.2.1.1. Data Content Type 1812 The MMHS MUST use the id-data content type identifier to identify the 1813 "inner" MIME message content as specified in [RFC5751]. 1815 4.2.1.2. Signed-data Content Type 1817 The signedData content type is specified in [RFC5652] Section 5, 1818 consisting of MIME content (identified by the id-data content type) 1819 and zero or more signature values. 1821 4.2.1.2.1. SignedData Type 1823 The MMHS MUST support the SignedData type as specified in [RFC5652] 1824 Section 5.1. The clarifications and refinements are as follows: 1826 o The MMHS MUST support the EncapsulatedContentInfo type 1827 eContentType attribute. The value of the eContentType MUST be id- 1828 data unless the content is compressed according to 1829 Section 4.2.1.4. 1831 o The MMHS MUST support the EncapsulatedContentInfo type eContent 1832 attribute. The value of the eContent MUST contain the content to 1833 be signed. If the content is compressed using the compressed-data 1834 content type as defined in Section 4.2.1.4, the 1835 CompressedData.encapContentInfo.eContentType MUST be set to the 1836 id-data content type identifier of the compressed MIME content and 1837 the CompressedData.encapContentInfo.eContent MUST contain the MIME 1838 content to be compressed and protected by S/MIME. 1840 o The MMHS MUST support X.509 version 3 certificates. An MMHS with 1841 high throughput MUST include certificates within the message. An 1842 MMHS with impoverished communications SHOULD NOT send certificates 1843 with the message. 1845 o The MMHS MUST support the certificate profile and CRL profile 1846 specified in [RFC5280] [RFC6818]. 1848 o The MMHS MUST support X.509 version 3 certificate processing 1849 specified in [RFC5750]. 1851 4.2.1.2.2. SignerInfo Type 1853 The SignerInfo type is specified in [RFC5652] Section 5.3 allowing 1854 the inclusion of unsigned and signed attributes along with a 1855 signature. The clarifications and refinements are as follows: 1857 o The MMHS MUST support signed attributes. As a minimum the MMHS 1858 MUST support processing and handling of the following signed 1859 attributes: contentType ([RFC5751] Section 2.5.1); 1860 eSSSecurityLabel ([RFC2634] Section 3.2; messageDigest ([RFC5652] 1861 Section 11.2); signingTime ([RFC5751] Section 2.5.1); 1862 sMIMECapabilities ([RFC5751] Section 2.5.2); and, 1863 sMIMEEncryptionKeyPreference ([RFC5751] Section 2.5.3). 1865 o The MMHS MUST support the conventions for using the Secure Hash 1866 Algorithm (SHA) message digest algorithms and signature algorithms 1867 as specified in [RFC5754] and [RFC5751]. 1869 o The MMHS MUST support both the SignerIdentifier type attributes 1870 issuerAndSerialNumber and subjectKeyIdentifier. 1872 4.2.1.3. Enveloped-data Content Type 1874 The envelopedData content type is specified in [RFC5652] Section 6, 1875 consisting of an encrypted MIME content (identified by the id-data 1876 content type) and encrypted content-encryption keys for one or more 1877 recipients. 1879 4.2.1.3.1. EnvelopedData Type 1881 The MMHS MUST support the EnvelopedData type as specified in 1882 [RFC5652] Section 6.1. The clarifications and refinements are as 1883 follows: 1885 o The MMHS MUST support the EncryptedContentInfo type eContentType 1886 attribute. The value of the eContentType MUST be id-data unless 1887 the content is compressed according to Section 4.2.1.4. 1889 o The MMHS MUST support the EncryptedContentInfo type eContent 1890 attribute. The value of the eContent MUST contain the content to 1891 be encrypted. If the content is compressed using the compressed- 1892 data content type as defined in Section 4.2.1.4, the 1893 CompressedData.encapContentInfo.eContentType MUST be set to the 1894 id-data content type identifier of the compressed MIME content and 1895 the CompressedData.encapContentInfo.eContent MUST contain the MIME 1896 content to be compressed and protected by S/MIME. 1898 o The MMHS MUST support the originatorInfo attribute if required by 1899 the key-management algorithm (refer to Section 4.2.1.3.1.1). 1901 o The MMHS MUST support X.509 version 3 certificates. An MMHS with 1902 high throughput MUST include certificates within the message. An 1903 MMHS with impoverished communications SHOULD NOT send certificates 1904 with the message. 1906 o The MMHS MUST support the certificate profile and CRL profile 1907 specified in [RFC5280] [RFC6818]. 1909 o The MMHS MUST support X.509 version 3 certificate processing 1910 specified in [RFC5750]. 1912 4.2.1.3.1.1. RecipientInfo Type 1914 The RecipientInfo type is specified in [RFC5652] Section 6.2. The 1915 clarifications and refinements are as follows: 1917 o The MMHS MAY support KeyTransRecipientInfo. 1919 o The MMHS MUST support KeyAgreeRecipientInfo. The originatorKey 1920 attribute MUST be supported as the choice for the originator to 1921 specify the sender's key agreement public key. 1923 o The MMHS MAY support KEKRecipientInfo. 1925 o The MMHS MAY support PasswordRecipientinfo. 1927 o The MMHS MAY support OtherRecipientInfo. 1929 4.2.1.4. Compressed-Data Content Type 1931 The MMHS MUST support the compressedData content type as specified in 1932 [RFC3274]. 1934 4.2.1.4.1. CompressedData Type 1936 In the cases where the MMHS uses compressedData, it MUST only be used 1937 once for every message and MUST only be used around the content of 1938 the innermost security wrapper. 1940 4.2.2. S/MIME Triple Wrapping 1942 If the MMHS supports S/MIME protocols for providing the security 1943 services (defined in this profile) the MMHS MUST support military 1944 messages that are triple wrapped or signed only. A triple wrapped 1945 message is one that has been signed, then encrypted, then signed 1946 again. The signers of the inner and outer signatures may be 1947 different entities or the same entity. If a military message is 1948 triple wrapped, the SignedData and EnvelopedData wrappers MUST follow 1949 the specifications described in Section 4.2.1.2 and Section 4.2.1.3 1950 of this profile, respectively. 1952 4.2.3. Organisation to Organisation Security 1954 The implementation of the MMHS security services is dependent upon 1955 the security and assurance requirements that are to be met by those 1956 MMHS security services. As such, the identity of the signer of the 1957 MMHS message may be the user, the role the user is performing or the 1958 organization the user belongs to. If the MMHS supports S/MIME 1959 protocols for providing the security services (defined in this 1960 profile) and the MMHS is providing organisation to organisation 1961 security services then the MMHS MUST support Domain-based signing 1962 using S/MIME as specified in [I-D.melnikov-smime-msa-to-mda]. 1964 4.2.4. DKIM Digital Signatures 1966 DKIM [RFC6376] defines an organization-level digital signature 1967 authentication framework for Internet email, using public key 1968 cryptography and using the domain name service as its key server 1969 technology. However, it is possible to administer DKIM to support 1970 user-level signature granularity. This profile specifies the use of 1971 DKIM defined in [RFC6376] for providing an alternative security 1972 mechanism to S/MIME to deliver the Authentication of Origin 1973 (Section 4.1.2), Non-repudiation of Origin (Section 4.1.3) and 1974 Message Integrity (Section 4.1.4) security services to the MMHS. 1975 However, the implementation of DKIM is dependent upon the security 1976 and assurance requirements that are to be met by the MMHS security 1977 services. An MMHS MAY implement DKIM (to apply digital signatures 1978 for the MMHS message header fields and message body) to meet those 1979 security and assurance requirements based on one of the following use 1980 cases: 1982 1. Share the organization signing identity (identified by the 1983 Signing Domain Identifier (SDID)) private key for signing the 1984 MMHS message. The MMHS message is digitally signed by the 1985 organization MSA component. This profile does not provide end to 1986 end security services. This profile supports organization to 1987 organization Authentication of Origin, Non-repudiation of Origin 1988 and Message Integrity security services. 1990 2. Share the organization signing identity private key for signing 1991 the MMHS message. The email address of the MMHS message 1992 originator can be specified as the Agent or User Identifier 1993 (AUID). The semantics for performing per-user identity 1994 differentiation with this approach MUST be agreed out-of-band and 1995 is outside the scope of this MMHS profile. The MMHS message is 1996 digitally signed by the organization MSA component. This profile 1997 does not provide end to end security services. This profile 1998 supports organization to organization Authentication of Origin, 1999 Non-repudiation of Origin and Message Integrity security 2000 services. 2002 3. Generate per-user public/private key pairs where the public key 2003 is published to distinct subdomains (of the organization domain). 2004 The MMHS message is signed with the user's private key and the 2005 signing identity is identifiable by the user's subdomain value in 2006 the SDID. The MMHS message is digitally signed by the MUA. This 2007 profile supports end to end Authentication of Origin, Non- 2008 repudiation of Origin and Message Integrity security services. 2010 4. Generate per-user public/private key pairs where the public key 2011 is published to a unique resource record under the organization 2012 domain. The MMHS message is signed with the user's private key 2013 and the signing identity is identifiable by the domain value in 2014 the SDID and the unique resource record identified by the 2015 selector value. The MMHS message is digitally signed by the MUA. 2016 This profile supports end to end Authentication of Origin, Non- 2017 repudiation of Origin and Message Integrity security services. 2019 To provide organization to organization security services: the 2020 recipient MUA SHOULD support DKIM digital signature verification or 2021 the MUA MUST support the Authentication-Results header field as 2022 specified in [RFC7601] according to the security policy; and the 2023 organization border MTA (or MDA) MUST support DKIM digital signature 2024 verification and output the verification results (according to the 2025 security policy) to the Authentication-Results header field compliant 2026 with [RFC7601]. 2028 To provide end to end security services the recipient MUA MUST 2029 support DKIM digital signature verification specified in [RFC6376]. 2031 DKIM does not provide confidentiality security services. 2033 4.2.5. Security Labels 2035 If the MMHS supports S/MIME protocols for implementing security 2036 services then the MMHS MUST support on origination the 2037 ESSSecurityLabel specified in Section 3 of [RFC2634]. The MMHS MUST 2038 support the security-policy-identifier, security-classification, 2039 privacy-mark and security-categories attributes of the 2040 ESSSecurityLabel. The MMHS MAY support the Equivalent Security 2041 Labels EquivalentLabels as specified in [RFC2634] Section 3.4. 2043 An MMHS MAY on origination support the SIO-Label header field as 2044 specified in [RFC7444]. 2046 On reception the MMHS MUST support the ESSSecurityLabel and SIO- 2047 Label. In the case where a military message contains a SIO-Label and 2048 an ESSSecurityLabel the MMHS MUST assert that the policy conveyed in 2049 both are the same and that the sensitivity, compartments, and other 2050 handling caveats that can be conveyed in both are the same. 2052 4.2.6. Message Header Fields 2054 By default, [RFC5751] secures MIME message body parts, excluding the 2055 message header fields. If the MMHS implements S/MIME security 2056 services then the MMHS SHOULD provide a mechanism for securing the 2057 message header fields. [RFC5751] includes a mechanism for protecting 2058 the header fields where the whole message is wrapped in a message/ 2059 rfc822 MIME media type. However, this approach can be problematic 2060 for non-S/MIME aware MUAs and does not provide a mechanism for 2061 signing a subset of message header fields. 2063 If the MMHS provides security services this profile requires that the 2064 MMHS MUST support the protection for the integrity and authenticity 2065 of MMHS message header fields. 2067 The MMHS MUST support the mechanism for protecting the header fields 2068 as defined in [RFC5751] based on the considerations specified in 2069 [I-D.melnikov-smime-header-signing] and/or the MMHS MUST support 2070 DomainKeys Identified Mail (DKIM) Signatures profiled in 2071 Section 4.2.4 for digitally signing the MMHS message header fields. 2073 In the case of DKIM for digitally signing the MMHS message header 2074 fields a subset or all of the MMHS message header fields MAY be 2075 digitally signed. The MMHS message headers that are required to be 2076 digitally signed are to be specified in the security policy being 2077 enforced, however a recommended set of MMHS message headers that are 2078 to be digitally signed (if present) are listed below (note that if a 2079 header field is absent, DKIM will provide protection from insertion 2080 of the header field): 2082 o From 2084 o Reply-To 2086 o Subject 2088 o Date 2090 o To, Cc, Bcc 2092 o Sender 2094 o Expires 2096 o Supersedes 2098 o Message-ID 2100 o In-Reply-To, References 2102 o SIO-Label 2104 o MMHS-Primary-Precedence, MMHS-Copy-Precedence, MMHS-Message-Type, 2105 MMHS-Extended-Authorisation-Info, MMHS-Authorizing-Users 2107 o MT-Priority 2109 DKIM does not provide confidentiality security services. 2111 5. Requirements on Mail User Agents 2113 5.1. Standards Compliance 2115 A Mail User Agent (MUA) compliant with this specification MUST 2116 support 2118 1. Internet Message Format [RFC5322]. 2120 2. Multipurpose Internet Mail Extensions (MIME) [RFC2045] [RFC2046] 2121 [RFC2047] [RFC2049] [RFC2231]. In particular they must be able 2122 to generate, display and process of message/rfc822, multipart/ 2123 mixed and text/plain media types. Additionally, the ability to 2124 decode application/zlib and application/gzip media types on 2125 receipt as defined in [RFC6713] and support for format=flowed 2126 text/plain media type parameter [RFC3676]. 2128 3. Parsing, processing and having the ability to generate MMHS 2129 header fields specified in [RFC6477]. 2131 4. The ability to specify priority on origination, in particular 2132 the ability to insert MT-Priority header field [RFC6758] into 2133 messsages to be sent. 2135 5. Parsing and processing of multipart/report media type for the 2136 Reporting of Mail System Administrative Messages [RFC6522] 2137 containing message/delivery-status [RFC3464] and Message 2138 Disposition Notification (MDN) [RFC3798]. 2140 6. The ability to request an MDN and the ability to generate an MDN 2141 in response to a request [RFC3798]. 2143 7. The ability to indicate message language using the Content- 2144 Language header field, as defined in [RFC3282]. 2146 8. The ability to select message expiration date when composing a 2147 message (using the Expires header field [RFC2156]) and display 2148 whether a message is expired or not upon receipt. 2150 9. Use of SMTP extension for Delivery Status Notifications 2151 [RFC3461], in particular support for NOTIFY, RET and ENVID 2152 parameters. 2154 10. Use of the Deliver By SMTP extension [RFC2852] for specifying 2155 the Latest Delivery date for a message. 2157 11. If supporting S/MIME for security services: the ability to send 2158 and receive signed and encrypted S/MIME messages [RFC5652] 2159 [RFC5751]. 2161 12. If supporting S/MIME for security services: the ability to send 2162 and receive ESS Security Labels [RFC2634]. 2164 13. If supporting DKIM for security services: support DKIM digital 2165 signature verification specified in [RFC6376] or support the 2166 Authentication-Results header field as specified in [RFC7601] 2167 according to the security policy. 2169 14. Support for SIO-Label header field [RFC7444] on receipt. 2171 MUA can also take advantage of SMTP extensions advertised by MSAs 2172 (see Section 6). 2174 5.2. Audit Trail and Logging 2176 Storage of audit data by the MUA is required to support security 2177 monitoring, accountability, and tractability of messages to the 2178 source. This information will be used to provide accountability and 2179 support for any required tracer actions. All stored audit data shall 2180 be maintained for at least ten (10) days. Data will be recorded and 2181 stored at each MUA to provide an audit capability for messages that 2182 are submitted and received. The following table indicates which 2183 audit information is required at a minimum to be logged by the MUA 2184 for submitted and received messages. Policy may require longer 2185 retention periods and additional information be stored. The 2186 integrity of audit logs must be protected. 2188 +-------------------------------------------+-----------------------+ 2189 | Submitted Messages | Delivered/Received | 2190 | | Messages | 2191 +-------------------------------------------+-----------------------+ 2192 | Authorizing Users Indication, Extended | Extended | 2193 | Authorization Info, MM Identification, | Authorization Info, | 2194 | Message Identification, Delivery/Non- | MM Identification, | 2195 | delivery Notification, Receipt/Non- | Message | 2196 | receipt Notification Request Indication, | Identification, | 2197 | Primary/Copy Precedence, Primary and Copy | Originator | 2198 | Recipients Indication, Blind Copy | Indication, | 2199 | Recipient Indication, Non-Repudiation of | Primary/Copy | 2200 | Receipt, Security Labels, Message Type | Precedence, Security | 2201 | | Labels, Delivery | 2202 | | Timestamp Indication | 2203 +-------------------------------------------+-----------------------+ 2205 6. Requirements on Mail Submission Agents 2207 6.1. Standards Compliance 2209 In addition to the list of requirements specified in [RFC6409], an 2210 Mail Submission Agent (MSA) compliant with this specification MUST 2211 support: 2213 1. SMTP Extension for Authentication [RFC4954]. For environment 2214 using X.509 certificates, SASL EXTERNAL [RFC4422] authentication 2215 mechanism must be supported. For environment using Kerberos, 2216 SASL GSSAPI [RFC4752] authentication mechanism must be 2217 supported. For environment using password based authentication, 2218 SASL SCRAM [RFC5802] must be supported. 2220 2. SMTP Extension for Secure SMTP over TLS [RFC3207]. 2222 3. SMTP Service Extension for Returning Enhanced Error Codes 2223 [RFC2034]. 2225 4. Deliver By SMTP Service Extension [RFC2852]. 2227 5. SMTP extension for Message Transfer Priorities. [RFC6710] 2228 "STANAG4406" Priority Assignment Policy MUST be advertised in 2229 the EHLO response. The MSA MUST be able to handle the MT- 2230 Priority header field as specified in [RFC6758]. 2232 6. SMTP extension for for Delivery Status Notifications [RFC3461]. 2234 7. SMTP Extension for 8-bit MIME transport [RFC6152]. 2236 8. SMTP Extension for Message Size Declaration [RFC1870]. 2238 9. SMTP Extension for Command Pipelining [RFC2920]. 2240 10. SMTP Extensions for Transmission of Large and Binary MIME 2241 Messages [RFC3030]. 2243 11. Support Draft & Release procedure using the MMHS-Authorizing- 2244 Users header field [I-D.melnikov-mmhs-authorizing-users]. 2246 12. If supporting S/MIME for security services: the ability to sign 2247 and/or encrypt S/MIME messages on bahalf of the originating 2248 domain as specified in [I-D.melnikov-smime-msa-to-mda]. 2250 13. If supporting DKIM for security services: support DKIM digital 2251 signature generation as specified in [RFC6376]. 2253 The following SMTP extensions are OPTIONAL to support in MSAs 2254 compliant with this specification: 2256 1. SMTP Submission Service Extension for Future Message Release 2257 [RFC4865]. 2259 6.2. Audit Trail and Logging 2261 Storage of audit data by the MSA is required to support security 2262 monitoring, accountability, and traceability of messages to the 2263 source. This information will be used to provide accountability and 2264 support for any required tracer actions. All stored audit data shall 2265 be maintained for at least ten (10) days. Data will be recorded and 2266 stored at each MSA to provide an audit capability for messages that 2267 are delivered and submitted. The following table indicates which 2268 audit information is required at a minimum to be logged by the MSA 2269 for delivered and submitted messages. Policy may require longer 2270 retention periods and additional information be stored. The 2271 integrity of audit logs must be protected. 2273 +-------------------------------------------------------------------+ 2274 | Submitted Messages | 2275 +-------------------------------------------------------------------+ 2276 | MM Identification, Message Identification, Submission Timestamp | 2277 | Indication, Priority | 2278 +-------------------------------------------------------------------+ 2280 7. Requirements on Mail Transfer Agents 2282 7.1. Standards Compliance 2284 A Mail Transfer Agent (MTA) compliant with this specification MUST 2285 support 2287 1. SMTP Service Extension for Returning Enhanced Error Codes 2288 [RFC2034]. 2290 2. Deliver By SMTP Service Extension [RFC2852]. 2292 3. SMTP extension for Message Transfer Priorities [RFC6710]. 2293 "STANAG4406" Priority Assignment Policy MUST be advertised in the 2294 EHLO response. The MTA MUST be able to handle the MT-Priority 2295 header field as specified in [RFC6758]. 2297 4. SMTP extension for for Delivery Status Notifications [RFC3461]. 2299 5. SMTP Extension for 8-bit MIME transport [RFC6152]. 2301 6. SMTP Extension for Message Size Declaration [RFC1870]. 2303 7. SMTP Extension for Command Pipelining [RFC2920]. 2305 8. SMTP Extensions for Transmission of Large and Binary MIME 2306 Messages [RFC3030]. 2308 Additionally border MTAs in originating domains MUST support 2310 1. Enforcement of correct Draft & Release procedure using the MMHS- 2311 Authorizing-Users header field 2312 [I-D.melnikov-mmhs-authorizing-users]. 2314 2. If supporting S/MIME for security services: the ability to sign 2315 and/or encrypt S/MIME messages on bahalf of the originating 2316 domain as specified in [I-D.melnikov-smime-msa-to-mda]. 2318 3. If supporting DKIM for security services: support DKIM digital 2319 signature generation as specified in [RFC6376]. 2321 4. If supporting S/MIME for security services: enforcement of 2322 correctness of ESS Security Labels [RFC2634]. 2324 5. Enforcement of correctness of security labels in SIO-Label header 2325 field [RFC7444]. 2327 6. SMTP Extension for Secure SMTP over TLS [RFC3207]. 2329 7. SMTP Extension for Authentication [RFC4954]. 2331 Additionally border MTAs in receiving domains MUST support 2333 1. If supporting S/MIME for security services: the ability to verify 2334 and/or decrypt S/MIME messages on behalf of the receiving domain 2335 as specified in [I-D.melnikov-smime-msa-to-mda]. 2337 2. If supporting DKIM for security services: support DKIM digital 2338 signature verification as specified in [RFC6376]. 2340 3. Support for the Authentication-Results header field generation as 2341 specified in [RFC7601] if required by the security policy. 2343 4. If supporting S/MIME for security services: enforcement of 2344 correctness of ESS Security Labels [RFC2634]. 2346 5. Enforcement of correctness of security labels in SIO-Label header 2347 field [RFC7444]. 2349 6. SMTP Extension for Secure SMTP over TLS [RFC3207]. 2351 7. SMTP Extension for Authentication [RFC4954]. 2353 7.2. Audit Trail and Logging 2355 Storage of audit data by the MTA is required to support security 2356 monitoring, accountability, and tracability of messages to the 2357 source. This information will be used to provide accountability and 2358 support for any required tracer actions. All stored audit data shall 2359 be maintained for at least ten (10) days. Data will be recorded and 2360 stored at each MTA to provide an audit capability for messages that 2361 are sent and received. The following table indicates which audit 2362 information is required at a minimum to be logged by the MTA for 2363 inbound and outbound messages. Policy may require longer retention 2364 periods and additional information be stored. The integrity of audit 2365 logs must be protected. 2367 +---------------------------------+---------------------------------+ 2368 | Inbound Messages | Outbound Message | 2369 +---------------------------------+---------------------------------+ 2370 | MM Identification, Message | MM Identification, Message | 2371 | Identification, Submission | Identification, Submission | 2372 | Timestamp Indication, Priority, | Timestamp Indication, Priority, | 2373 | Time of Transfer In* | Time of Transfer Out* | 2374 +---------------------------------+---------------------------------+ 2376 * MTAs operating in a relay capacity are responsible for logging the 2377 marked attributes. 2379 8. IANA Considerations 2381 This document doesn't ask for any action from IANA. 2383 9. Security Considerations 2385 This document specifies an MMHS Profile for a comparable messaging 2386 service to STANAG 4406 Edition 2 or [ACP123] provided using Internet 2387 Electronic Mail, SMTP and their extensions, S/MIME and DKIM. 2389 The MMHS Profile is not defining new protocol, therefore no new 2390 security concerns are raised that are not already captured by Email 2391 [RFC5322], MIME [RFC2045], S/MIME [RFC5751], DKIM [RFC6376], ESS 2392 [RFC2634] and SIO-Label [RFC7444] in general. 2394 10. References 2396 10.1. Normative References 2398 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 2399 DOI 10.17487/RFC2033, October 1996, 2400 . 2402 [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced 2403 Error Codes", RFC 2034, DOI 10.17487/RFC2034, October 2404 1996, . 2406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2407 Requirement Levels", BCP 14, RFC 2119, 2408 DOI 10.17487/RFC2119, March 1997, 2409 . 2411 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 2412 Extension for Delivery Status Notifications (DSNs)", 2413 RFC 3461, DOI 10.17487/RFC3461, January 2003, 2414 . 2416 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2417 DOI 10.17487/RFC5321, October 2008, 2418 . 2420 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2421 DOI 10.17487/RFC5322, October 2008, 2422 . 2424 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 2425 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 2426 . 2428 [RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service 2429 Extension for Message Size Declaration", STD 10, RFC 1870, 2430 DOI 10.17487/RFC1870, November 1995, 2431 . 2433 [RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, 2434 DOI 10.17487/RFC2852, June 2000, 2435 . 2437 [RFC2920] Freed, N., "SMTP Service Extension for Command 2438 Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920, 2439 September 2000, . 2441 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 2442 of Large and Binary MIME Messages", RFC 3030, 2443 DOI 10.17487/RFC3030, December 2000, 2444 . 2446 [RFC4865] White, G. and G. Vaudreuil, "SMTP Submission Service 2447 Extension for Future Message Release", RFC 4865, 2448 DOI 10.17487/RFC4865, May 2007, 2449 . 2451 [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed., 2452 "SMTP Service Extension for 8-bit MIME Transport", STD 71, 2453 RFC 6152, DOI 10.17487/RFC6152, March 2011, 2454 . 2456 [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service 2457 Extension for Authentication", RFC 4954, 2458 DOI 10.17487/RFC4954, July 2007, 2459 . 2461 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 2462 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 2463 February 2002, . 2465 [RFC6477] Melnikov, A. and G. Lunt, "Registration of Military 2466 Message Handling System (MMHS) Header Fields for Use in 2467 Internet Mail", RFC 6477, DOI 10.17487/RFC6477, January 2468 2012, . 2470 [RFC6710] Melnikov, A. and K. Carlberg, "Simple Mail Transfer 2471 Protocol Extension for Message Transfer Priorities", 2472 RFC 6710, DOI 10.17487/RFC6710, August 2012, 2473 . 2475 [RFC6758] Melnikov, A. and K. Carlberg, "Tunneling of SMTP Message 2476 Transfer Priorities", RFC 6758, DOI 10.17487/RFC6758, 2477 October 2012, . 2479 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2480 Extensions (MIME) Part One: Format of Internet Message 2481 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 2482 . 2484 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2485 Extensions (MIME) Part Two: Media Types", RFC 2046, 2486 DOI 10.17487/RFC2046, November 1996, 2487 . 2489 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 2490 Part Three: Message Header Extensions for Non-ASCII Text", 2491 RFC 2047, DOI 10.17487/RFC2047, November 1996, 2492 . 2494 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2495 Extensions (MIME) Part Five: Conformance Criteria and 2496 Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996, 2497 . 2499 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 2500 Word Extensions: Character Sets, Languages, and 2501 Continuations", RFC 2231, DOI 10.17487/RFC2231, November 2502 1997, . 2504 [RFC3676] Gellens, R., "The Text/Plain Format and DelSp Parameters", 2505 RFC 3676, DOI 10.17487/RFC3676, February 2004, 2506 . 2508 [RFC6713] Levine, J., "The 'application/zlib' and 'application/gzip' 2509 Media Types", RFC 6713, DOI 10.17487/RFC6713, August 2012, 2510 . 2512 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2513 Housley, R., and W. Polk, "Internet X.509 Public Key 2514 Infrastructure Certificate and Certificate Revocation List 2515 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2516 . 2518 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 2519 Infrastructure Certificate and Certificate Revocation List 2520 (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January 2521 2013, . 2523 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 2524 RFC 2634, DOI 10.17487/RFC2634, June 1999, 2525 . 2527 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2528 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2529 . 2531 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 2532 Mail Extensions (S/MIME) Version 3.2 Message 2533 Specification", RFC 5751, DOI 10.17487/RFC5751, January 2534 2010, . 2536 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 2537 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2538 2010, . 2540 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 2541 Mail Extensions (S/MIME) Version 3.2 Certificate 2542 Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, 2543 . 2545 [RFC3274] Gutmann, P., "Compressed Data Content Type for 2546 Cryptographic Message Syntax (CMS)", RFC 3274, 2547 DOI 10.17487/RFC3274, June 2002, 2548 . 2550 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 2551 for Delivery Status Notifications", RFC 3464, 2552 DOI 10.17487/RFC3464, January 2003, 2553 . 2555 [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for 2556 the Reporting of Mail System Administrative Messages", 2557 STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, 2558 . 2560 [RFC3798] Hansen, T., Ed. and G. Vaudreuil, Ed., "Message 2561 Disposition Notification", RFC 3798, DOI 10.17487/RFC3798, 2562 May 2004, . 2564 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, 2565 DOI 10.17487/RFC3282, May 2002, 2566 . 2568 [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 2569 Filtering Language", RFC 5228, DOI 10.17487/RFC5228, 2570 January 2008, . 2572 [RFC7601] Kucherawy, M., "Message Header Field for Indicating 2573 Message Authentication Status", RFC 7601, 2574 DOI 10.17487/RFC7601, August 2015, 2575 . 2577 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 2578 Mapping between X.400 and RFC 822/MIME", RFC 2156, 2579 DOI 10.17487/RFC2156, January 1998, 2580 . 2582 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 2583 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 2584 RFC 6376, DOI 10.17487/RFC6376, September 2011, 2585 . 2587 [RFC7444] Zeilenga, K. and A. Melnikov, "Security Labels in Internet 2588 Email", RFC 7444, DOI 10.17487/RFC7444, February 2015, 2589 . 2591 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 2592 Authentication and Security Layer (SASL)", RFC 4422, 2593 DOI 10.17487/RFC4422, June 2006, 2594 . 2596 [RFC4752] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") Simple 2597 Authentication and Security Layer (SASL) Mechanism", 2598 RFC 4752, DOI 10.17487/RFC4752, November 2006, 2599 . 2601 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 2602 "Salted Challenge Response Authentication Mechanism 2603 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 2604 DOI 10.17487/RFC5802, July 2010, 2605 . 2607 [ACP123] CCEB, , "Common Messaging Strategy and Procedures", 2608 ACP 123, May 2009. 2610 [I-D.melnikov-mmhs-authorizing-users] 2611 Melnikov, A., "Draft and Release using Internet Email", 2612 draft-melnikov-mmhs-authorizing-users-08 (work in 2613 progress), June 2015. 2615 [I-D.melnikov-smime-msa-to-mda] 2616 Melnikov, A., "Domain-based signing and encryption using 2617 S/MIME", draft-melnikov-smime-msa-to-mda-04 (work in 2618 progress), March 2014. 2620 [I-D.melnikov-smime-header-signing] 2621 Melnikov, A., "Considerations for protecting Email header 2622 with S/MIME", draft-melnikov-smime-header-signing-02 (work 2623 in progress), April 2015. 2625 10.2. Informative References 2627 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 2628 DOI 10.17487/RFC5598, July 2009, 2629 . 2631 [STANAG-4406] 2632 NATO, , "STANAG 4406 Edition 2: Military Message Handling 2633 System", STANAG 4406, March 2005. 2635 [STANAG-4631] 2636 NATO, , "STANAG 4631 Edition 1: Profile for the Use of the 2637 Cryptographic Message Syntax (CMS) and Enhanced Security 2638 Services (ESS) for S/MIME", STANAG 4631, June 2008. 2640 Appendix A. Acknowledgements 2642 Many thanks for input provided by Steve Kille and David Wilson. 2644 Authors' Addresses 2646 Alexey Melnikov 2647 Isode Ltd 2648 5 Castle Business Village 2649 36 Station Road 2650 Hampton, Middlesex TW12 2BX 2651 UK 2653 EMail: Alexey.Melnikov@isode.com 2655 Graeme Lunt 2656 SMHS Ltd 2657 Bescar Moss Farm 2658 Bescar Lane 2659 Ormskirk L40 9QN 2660 UK 2662 EMail: graeme.lunt@smhs.co.uk 2664 Alan Ross 2665 SMHS Ltd 2666 Bescar Moss Farm 2667 Bescar Lane 2668 Ormskirk L40 9QN 2669 UK 2671 EMail: alan.ross@smhs.co.uk