Military Message Handling (MMHS) is specified in STANAG 4406, which operates over the X.400 Messaging protocols. This whitepaper looks at how MMHS could be provided over SMTP noting where this can be done with existing standards, where there is active work to define standards, and where there are currently no standards. It concludes with a summary of what is needed to make MMHS over SMTP a reality that can meet operational requirements.

Creative Commons License

Military Message Handling

Formal messaging is used by the military to handle commands, and is complementary to informal messaging (email). Formal messaging is primarily communication between roles and organizations rather than individuals. There are two families of standards for formal military messaging: ACP127 and STANAG 4406; These are reviewed in historical order.


Military Messaging was originally specified in the ACP127 which is essentially a text based message format, with very simple telex-like exchange mechanisms. An example ACP127 message is:

DE RCCIC 134 02/0009Z
R 012345Z APR 00

Further information on ACP127 and on Isode’s M-Switch support of ACP127 and related protocols is provided in the whitepaper [M-Switch ACP127 Gateway to STANAG 4406 and MMHS over SMTP].


NATO specified STANAG 4406 as a replacement for ACP127. The most recent version is STANAG 4406, Edition 2. "Military Message Handling System", March 2005. ACP 123(B) "Common Messaging Strategy and Procedures", May 2009 is a related CCEB standard (Australia/Canada/New Zealand/UK/USA) that is broadly similar with the protocols harmonized. Key benefits of STANAG 4406 over the earlier ACP127 include:

  • Security, including Security Labels and Digital Signatures.
  • Attachments.
  • Reliable message transfer protocols (so no operator assistance needed).
  • End to end acknowledgements (read receipts and delivery reports) provide reliability, tracking and fire and forget.
  • Optimized protocols for constrained links.
  • Flexible precedence (priority) handling.
  • Directory integration.

More information on MMHS and Isode's solutions to provide MMHS can be found on the Military Messaging solutions page.

Is there a Need for MMHS over SMTP?

SMTP (Simple Mail Transfer Protocol) and other Internet Email protocols are widely deployed. This white paper looks at how MMHS could be deployed over SMTP as an alternative to STANAG 4406 and ACP127.

This white paper is not trying to present a view as to whether or not MMHS over SMTP is a good thing. Those who see MMHS over SMTP as a desired direction can read this paper as a road map on how to achieve it. Those who see MMHS over SMTP as a change to be avoided can read the list of open requirements as an argument to stay with STANAG 4406. Arguments for and against are now noted.

Reasons for MMHS over SMTP

  • SMTP is widely used and available, whereas STANAG 4406 systems are specialized.
  • SMTP infrastructure can be shared between MMHS and informal email, reducing management overheads and to support communities where only partial MMHS capability may be required, or communities where a small subset of users require MMHS capability, without the requirement of deploying a separate MMHS infrastructure.
  • Because it can now be done (SMTP was not sufficiently mature when STANAG 4406 was specified).

Reasons against MMHS over SMTP

  • STANAG 4406 provides a complete and comprehensive set of standards for MMHS over X.400, including interoperability with ACP127. No such standards exist for SMTP.
  • It is desirable to keep MMHS formal messaging separate from SMTP, as this facilitates giving priority to formal messaging over informal messaging when communication resource is constrained.
  • Significant work would need to be done to make SMTP systems suitable for MMHS; Just to achieve the current capability.
  • It would introduce yet another technology in to the mix of protocols to be gatewayed.

Experience with MMHS over SMTP

There have been a number of projects that have provided MMHS style services over SMTP, including:

Characteristics of these projects are:

  • Not attempting to provide all of the MMHS capabilities of STANAG 4406.
  • Defining extensions within the scope of the project to extend SMTP to provide capabilities beyond that provided by the SMTP core.

Why Open Standards are Vital

Standardization is very important for MMHS. For military messaging, partner interoperability is critical and this requires standards. For this reason, functional elements in this white paper are presented in terms of either standards that can be used or standards that need to be written.

This paper looks at the services provided by STANAG 4406 messaging, and considers how these services could be provided over SMTP. There are three basic groups:

  1. Services that can be provided by existing (SMTP related) standards.
  2. Services that cannot be provided by existing standards, but where Isode is actively working on specifications with other interested parties that we anticipate will become standards.
  3. Services that cannot be provided by existing standards, where no standard is currently anticipated.

STANAG 4406 and X.400

STANAG 4406 is based on X.400. It defines a number of extensions to X.400, which are the most visible distinct parts of STANAG 4406. It also defines use of a wide range of X.400 capabilities. X.400 is an ideal base for a service such as MMHS. Key reasons:

  • A rich messaging protocol, providing comprehensive message transfer and end to end capabilities.
  • Reliability and an integrated approach to message delivery reports.
  • Extensibility at message transport and end to end.
  • Support for priority at message transport level.
  • Directory integration.

The Isode whitepaper [Why X.400 Is Good for High Reliability Messaging] gives further detail.

This paper looks at support of the X.400 services used by STANAG 4406 and at the X.400 extensions defined in STANAG 4406.

Capabilities provided by Standard SMTP and Related Standards

SMTP is not defined in one place, but by a family of RFCs specifying core and extended capabilities. When STANAG 4406 was specified, SMTP would have been an entirely inadequate base (e.g., it did not support attachments or delivery reports). The full SMTP suite can now address the majority of the X.400 services used by SMTP. It should be noted that many SMTP products do not support all of the standards noted here.

Messaging Standards

Support of the following standards is needed in order to provide the STANAG 4406 services, in addition to further standards grouped by functionality in the following sections:

  • RFC 2034: SMTP Service Extension for Returning Enhanced Error Codes, N Freed, October 1996.
  • RFCs 2045, 2046, 2047, 2048, 2049: Multipurpose Internet Mail Extensions (MIME) Parts 1-5: Format of Internet Message Bodies, N. Freed, N. Borenstein, November 1996.
  • RFC 2852: Deliver By SMTP Service Extension, D Newman, June 2000. 
  • RFC 3461: Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs), K. Moore, January 2003.
  • RFC 3462: The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages, G. Vaudreuil, January 2003.
  • RFC 3798: Message Disposition Notification, T. Hansen, G. Vaudreuil, May 2004.
  • RFC 4409: Message Submission, R. Gellens , J. Klensin April 2006.
  • RFC 4865: SMTP Submission Service Extension for Future Message Release, G. White, G. Vaudreuil, May 2007.
  • RFC 5322: Internet Message Format, P Resnick (ed), October 2008.
  • RFC 5321: Simple Mail Transfer Protocol, J. Klensin (ed), October 2008

Support for the following standards would seem desirable to support MMHS over SMTP, but are not essential to provide the core STANAG 4406 Service:

  • RFC 1870: SMTP Service Extension for Message size Declaration, J. Klensin, N. Freed, K. Moore, November 1995.
  • RFC 2920: SMTP Service Extension for Command Pipelining, N. Freed, September 2000.
  • RFC 3030: SMTP Service Extensions for Transmission of Large and Binary MIME Messages, G. Vaudreuil, December 2000.
  • RFC 6152: SMTP Service Extension for 8-bit MIME transport, J. Klensin, N. Freed, M. Rose, D. Crocker, March 2011.

Connection Security

SMTP provides connection authentication using SASL , which is integrated with SMTP using:

  • RFC 4954: SMTP Service Extension for Authentication, A. Melnikov, R. Siemborski July 2007.

In addition, it may be desirable to use TLS for connection integrity and confidentiality, which goes beyond the STANAG 4406 service:

  • RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security, P. Hoffman, Feb 2002.

SMTP MTAs will generally provide connection security for message submission. However, connection security is generally not used between MTAs, unlike X.400 were MTA peer authentication is generally used. If connection security is needed between SMTP MTAs, care should be taken to ensure that a product supporting this is chosen.

Capabilities Needed to Replace X.400 Features used by STANAG 4406

This section looks at X.400 capabilities used by STANAG 4406 that are not provided by SMTP.

Priority (MTS Grade of Delivery)

X.400 defines three priority levels that control transfer of messages, and STANAG 4406 extends this to six levels, so that this can include military precedence levels (FLASH etc.). Military messaging is often deployed on slower networks, so sending higher priority traffic first is important, to meet operational objectives and SLA targets for delivery time which vary by precedence. Message priority is also sometimes used to control IP Quality of Service parameters.

Isode has helped to develop a standard for SMTP Priority (RFC 6710: Simple Mail Transfer Protocol Extension for Message Priorities) and an associated specification to support clients that do not have direct access to an MTA supporting RFC 6710 (RFC 6758: SMTP Priority Tunnelling).

Originator Requested Alternate Recipient

In the event of a critical message failing to be delivered, it is often desirable to have the message sent to an “alternate recipient” who can action the message, rather than reporting an error back to the originator. This service enables the originator to specify an alternate recipient that can be used in the event that the originally specified one fails.

Isode is working to develop a standard for SMTP Originator Requested Alternate Recipient: Simple Mail Transfer Protocol extension for Alternate Recipient Delivery Option.

Recipient Domain Assigned Alternate Recipient

This is an alternate option for alternate recipient, where the recipient domain defines a "catch all" alternate recipient. This capability could be supported in an SMTP MTA without any standardization, as this is a function of the MTA performing delivery reflected in local configuration.

Directory Integration & Capability Checking

X.400 users are addressed with an OR Name, which contains a "directory name" that can be looked up in an X.500 or LDAP directory. This gives two clear benefits:

  1. A message recipient can look up information (e.g., phone number) of the originator or other message recipients, by use of the directory name.
  2. A message originator can use the directory to look up recipient capabilities (including information defined in X.402 such as max message size, and X.501 Security Clearance) and check these against the message before submission.

There are three possible approaches to supporting directory addresses within SMTP.

  1. To encode directory addresses within the SMTP address. This could cause SMTP addresses to become rather long and awkward to use.
  2. To extend the SMTP specifications to carry directory names alongside SMTP addresses. This would give useful functionality, but would be awkward to specify and agree,
  3. To use the SMTP address as key into the directory. This would be straightforward for a small system with all users managed in a single directory server, but would need careful consideration for a larger system.

Message Distribution

STANAG 4406 makes use of X.400 Distribution Lists (DLs). DLs are defined as a part of X.400, and include sophisticated access control and behavior options such as priority handling. These capabilities may be important for some MMHS deployments.

STANAG 4406 also defines a mechanism where the originator can specify users to be exempted from message distribution.

Military Address Lists often use additional capabilities, such as profiling (distribution based on content or SIC code), which are not clearly standardized anywhere.

Internet Distribution Lists do not provide all of the necessary functionality.

Message Tracking using Acknowledgement (Fire and Forget)

STANAG 4406 systems will often use tracking of delivery reports (DRs) and read receipts (IPNs) to record if messages have been delivered and read, and to take automated or operator controlled action in the event this does not happen. This can work correctly in conjunction with Redirects and DLs.

Tracking can work correctly for simple SMTP systems using delivery reports (DSNs) and read receipts (MDNs). However, there is a problem if an SMTP MTA uses certain capabilities. In particular:

  1. If a single-alias is used (see RFC 3461) which is the equivalent of redirect, tracking will not work. This could be made to work, if specification of the use of ORCPT was made explicit.
  2. If a multi-alias is used (see RFC 3461), which is a bit like a DL but does not have a direct X.400 equivalent, tracking will not work.
  3. Use of mailing lists with MDNs will lead to multiple responses, which will cause difficulties with tracking.

The could be addressed by clear specification and constraints on how SMTP MTAs provide these functions, and use of the RFC 3461 ORCPT command to support tracking.

End to End Security

End to end security is a critical element of MMHS. STANAG 4631 defines the MMHS profile for security. Additional security requirements arise for messaging between partners, that are considered in ACP145.

The Security Standards for STANAG 4406 edition 2 and S/MIME for Internet messaging were developed together and share a common core. For this reason, it is straightforward to provide the equivalent services over SMTP.

Digital Signature and Encryption

STANAG 4406 uses CMS to sign and encrypt messages, noting that most MMHS deployments use digital signature but not encryption:

  • RFC 5652: Cryptographic Message Syntax (CMS), R. Housley, September 2009

SMTP can use exactly the same technology, following the S/MIME standard:

  • RFC 5751: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification, B. Ramsdell, January 2010

So the basic services are straightforward and equivalent.

In STANAG 4406, CMS signs and encrypts the entire message content. The normal S/MIME deployment does not sign or encrypt message headers, which is likely to be a problem for MMHS use. S/MIME does define a mechanism for signing headers, but this inter-operates badly with deployed S/MIME. The TrustedBird project uses a mechanism for including signed headers, which inter-operates with common S/MIME implementations. Unfortunately this dual content approach is likely to be problematic for gateways. A solution for this problem seems highly desirable.

Security Labels

STANAG 4406 edition 2 uses ESS labels:

  • RFC 2634: Enhanced Security Services for S/MIME, P. Hoffman, June 1999

These can also be used with S/MIME, and so equivalent support with SMTP is straightforward.

There are MMHS operational requirements to provide security labels without digital signature, typically for environments without PKI. This can be done in STANAG 4406 using X.411 security labels. It would be useful to define a new RFC 5322 header to enable this.

Constrained Networks

STANAG 4406 defines use of constrained networks in Annex E. For further information ses the Isode whitepaper [Military Messaging over HF Radio and Satellite using STANAG 4406 Annex E].

Isode has defined an implemented similar functionality for SMTP messaging using the same ACP 142 approach as Annex E. This is described in [Messaging Protocols for HF Radio].

Isode would be happy to provide its protocols for open standardization if there was interest.

Capabilities Needed to Replace STANAG 4406 Features

This section looks at X.400 extensions defined in STANAG 4406.

Message Headers

STANAG 4406 defines 16 message headers:

  1. Exempted Address.
  2. Extended authorization info.
  3. Distribution codes.
  4. Handling Instructions.
  5. Message instructions.
  6. Codress message.
  7. Originator reference.
  8. Primary Precedence.
  9. Copy Precedence.
  10. Message type.
  11. Address List indictor.
  12. Other recipients indicator.
  13. Pilot forwarding info.
  14. ACP127 message identifier.
  15. Originator PLAD.
  16. Security info.

Some of these would be important for providing MMHS over SMTP. Others are probably not useful or sensible (e.g., Security Info, which is deprecated in STANAG 4406 edition 2).

Isode has led development of the RFC 6477 standard for supporting these MMHS capabilities over SMTP: Registration of Military Message Handling System (MMHS) header fields for use in Internet Mail.


STANAG 4406 defines extension to IPNs and IPN requests. These are defined for interaction between a STANAG 4406 user and an ACP127 Gateway. It is unclear if equivalent functionality would be useful for MMHS over SMTP.

Forwarded Messages

STANAG 4406 defines the MM-Message as a mechanism for forwarding messages. This can be handled by MIME capabilities in MMHS over SMTP.

Body Parts

STANAG 4406 makes use of standard X.400 body parts. FTBP (File Transfer Body Part), IA5 Text, and General Text are the most widely used, and these have direct SMTP equivalent.

STANAG 4406 defines five body part types for carrying military message data, with ADatP-3 being the most widely used. It would be straightforward and desirable to define standardized MIME body parts for any formats useful for MMHS over SMTP, in preference to ad hoc encodings that have been used in some systems. Isode M-Switch supports flexible encoding of ADatP-3 in MIME, including a default mapping that is used to enable MIXER mapping of ADatP-3 with STANAG 4406.

STANAG 4406 Interoperability and MIXER

X.400 interoperability with SMTP is defined in the MIXER specifications.

It would be highly desirable that STANAG 4406 / MMHS over SMTP interoperability could be achieved by use of an enhanced MIXER gateway. Specifications to extend SMTP to support MMHS over SMTP should be defined in a manner that can be used with an enhanced MIXER Gateway.

M-Switch and Isode Product Support of MMHS over SMTP

Isode provides two products that can be used for MMHS over SMTP.

M-Switch SMTP is a high functionality SMTP MTA, with a range of security and management capabilities that make it suitable for military messaging. Many of these characteristics arise from M-Switch X.400, which is the same core product and widely used for STANAG 4406. All of the RFCs referenced are supported, apart from those listed below as possible extensions. Features of specific note:

  • Operation of SMTP over ACP 142, to provide a constrained bandwidth service equivalent to STANAG 4406 Annex E. See the whitepaper [Messaging Protocols for HF Radio].
  • Provision of six level military queue priority handling. A subset of this can be accessed by clients using the RFC 2156 Priority: field. Isode plans to implement the SMTP priority specification noted above.

Isode will be pro-active to add new standardized capability to M-Switch. We plan to add support for RFC 2852 and RFC 4865, which control delivery time and RFCs 6710 and 6758 to support priority.

M-Switch MIXER provides flexible gateway capabilities between STANAG 4406 and SMTP. This includes:

  • Support for the RFC 6477 MMHS Header specification: : 'Registration of Military Message Handling System (MMHS) header fields for use in Internet Mail'.
  • Flexible mapping of security labels between various formats on each side.
  • Mapping ADatP-3 body parts between STANAG 4406 and MIME.

Making MMHS over SMTP a Reality

Currently, some MMHS capabilities can be deployed over SMTP. In order to meet the needs of operational deployment, and in particular high grade messaging, this does not suffice. It is important to close some of the gaps identified in this paper. We believe that introducing an 'MMHS Over SMTP Profile' that specifies which RFCs and additional functionality is needed, would be a useful step, as this would enable clear understanding and procurement of systems providing MMHS over SMTP and associated gateways.


This paper has shown which MMHS capabilities can and cannot be currently provided over SMTP. For some of those that cannot, the paper has indicated how they could be addressed, and where Isode is undertaking standardization work.