Multicast Email (MULE) over Allied Communications Publication (ACP) 142
Isode Ltd14 Castle MewsHamptonMiddlesexTW12 2NPUKDavid.Wilson@isode.comIsode Ltd14 Castle MewsHamptonMiddlesexTW12 2NPUKAlexey.Melnikov@isode.comP_MUL
Allied Communications Publication (ACP) 142 defines P_MUL, which is a protocol
for reliable multicast suitable for bandwidth constrained and
delayed acknowledgement (Emissions Control or "EMCON") environments running over UDP.
This document defines an application protocol called MULE (Multicast Email) for transferring of
Internet Mail messages (as described in RFC 5322) over P_MUL (as defined in ACP 142A).
MULE enables Message Transfer Agent (MTA) to MTA transfer and doesn't provide a service
similar to SMTP Submission (as described in RFC 6409).
This document explains how MULE can be used in conjunction with
Simple Mail Transfer Protocol (SMTP, RFC 5321), including some common SMTP extensions,
to provide an alternate MTA to MTA transfer mechanism.
This is not an IETF specification, but describes an existing implementation.
It is provided in order to facilitate interoperable implementations and third-party diagnostics.
P_MUL is a transport protocol for reliable multicast in bandwidth constrained and
delayed acknowledgement environments running on top of UDP.
This document defines an application protocol called MULE
for transferring Internet Mail messages over ACP 142 P_MUL.
The objectives of MULE are first to take advantage of the bandwidth saving
feature of using the multicast service as supported by modern
computer networks and second to allow message transfer under EMCON (Emission Control)
conditions. EMCON or "Radio Silence" means that although receiving
nodes are able to receive messages, they are not able to acknowledge
the receipt of messages.
The objective of this protocol is to take advantage of multicast
communication for the transfer of messages between MTAs (Message
Transfer Agents) on a single multicast network under normal - which
means dialogue oriented - communication condition and under EMCON
condition. EMCON condition means that a receiving node is able to
receive messages, but it cannot - for a relatively long time (hours or
even days) - acknowledge the received messages.
Due to multicast use (instead of a unicast communication service) in the
above MTA configuration only one message transmission from the gateway to
the Router is required in order to reach MTA 1, MTA 2, MTA 3 and MTA 4,
instead of 4 as required with unicast.
This saves the transmision of 3 message transactions and thus network bandwidth
utilisation. Depending on the network bandwidth (in some radio
networks less than 9.6 Kb/s) this saving can be of vital importance.
The saving in bandwidth utilisation becomes even greater with every
additional receiving MTA.
P_MUL employs a connectionless transport protocol to transmit
messages: this guarantees reliable message transfer (through ACP 142 retransmissions),
even in those cases, when for a certain period of time, one or more of the receiving
MTAs are not able or allowed to acknowledge completely received
messages.
This protocol specification requires fixed multicast groups and a
well known knowledge at each participating node (MTA) about the group
memberships in one or more multicast groups of each participating
node. Membership in multicast groups needs to be established
before MULE messages can be sent.
MULE enables Message Transfer Agents (MTA) to MTA transfer and
doesn't provide service similar to SMTP Submission.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in BCP 14
when, and only when, they
appear in all capitals, as shown here.This document also uses terminology from and .
MULE is an electronic mail transport of Internet messages over
ACP 142 P_MUL network. It provides service similar to MTA-to-MTA SMTP .
This document doesn't define a service similar to Message Submission ().
An important feature of MULE is its capability to transport mail
across multiple networks, referred to as "MULE mail relaying".
A network consists of the mutually-ACP142-accessible nodes.
Using MULE, a process can transfer mail to another process on the same
ACP 142 network or to some other ACP 142 network via a relay or gateway process
accessible to both networks.
MULE reuses ESMTP extension framework defined in .
MULE servers MUST support the following ESMTP extensions:
DSN ,
SIZE ,
8BITMIME ,
MT-PRIORITY ,
DELIVERBY ,
BINARYMIME and CHUNKING .
(As the message content size can always be determined from
the compression wrapper and the size of the envelope,
no special handling is needed for binary messages.)
Relaying a message using MULE is performed as follows:
The message is reassembled from one or more DATA_PDUs .
If the contentType-ShortForm value is 25, the BSMTP-like payload is extracted from compressedContent field
and uncompressed as specified in .
If the contentType-ShortForm value is not 25, it is handled as described in .
This document doesn't discuss further any cases where contentType-ShortForm value is not 25.
The list of recipients is extracted from RCPT-lines (see ).
If the receiving node is not responsible (directly or inderectly) for any of the recipients,
the message is discarded and no further processing is done.
The relay adds trace header fields, for example the Received header field. See Section 4.4. of
and .
The set of ACP 142 destinations for the message is created by extracting right hand sides (hostnames)
of each RCPT-line, eliminating duplicates and then converting each hostname into next ACP 142 destination
using static configuration.
For each unique ACP 142 destination, the following steps are performed:
A new BSMTP-like payload is formed, as described in ,
which only contains RCPT-lines that correspond to recipients that can receive mail
through the ACP 142 destination.
The created payload is compressed and encoded as specified in .
The compressed payload is sent by P_MUL as a series of Address_PDU and one or more DATA_PDUs.
When the message has an associated MT-PRIORITY value ,
the MappedPriority(value) is included as the Priority field of corresponding ACP 142 PDUs,
including Address_PDU, DATA_PDUs, DISCARD_MESSAGE_PDU. Here MappedPriority(x) is defined as "6 - x".
MULE uses BSMTP-like payload which differs from Batch SMTP (BSMTP, )
in that it eliminates unnecessary information.
As with BSMTP, ESMTP capability negotiation is not used,
since receiver EMCON restrictions prohibit such real-time
interaction. For that reason, there is no point in including EHLO
capabilities. "MAIL FROM:" and "RCPT TO:" prefixes are also
eluded in order to save a few bytes.
For each received message, the corresponding BSMTP-like payload is constructed as follows
(Lines are terminated using CR LF).:
The first line is what would be used for the data following "MAIL FROM:"
in the SMTP dialogue. I.e. it contains the return-path address, within
<>'s followed by any ESMTP extension parameters to the MAIL FROM command.
After that, there is a separate line for each recipient of the message.
The value is what would follow "RCPT TO:" in the SMTP dialogue,
i.e. the recipient address within <>'s
followed by any ESMTP extension parameters to the corresponding RCPT TO command.
The list of recipients is terminated by an empty line (i.e. just CR LF)
The message content follows the empty line. There is no need for
transparency ("dot stuffing") or terminating with a sequence "CR LF . CR LF", as the end of
the message content is indicated by the end of the data
(See for more details).
A BSMTP-like payload () is first compressed using zlibCompress and
the compressed payload is placed in the compressedContent field of
the CompressedContentInfo element defined in Section 4.2.6 of .
This is then encoded as BER encoding of the CompressedData ASN.1 structure.
For convenience, the original definition of ASN.1 of the CompressedData structure is included below.
The contentType-ShortForm value used by MULE MUST be 25. (The contentType-OID alternative is never used by MULE.)
The above procedure is similar to how X.400 messages are sent using Annex E of STANAG 4406 Ed 2.
This makes it easier to implement MTAs that support both Internet messages and X.400 messages in the same code base.
The Compressed Data Type (CDT) consists of content of any type that is
compressed using a specified algorithm. The following object identifier identifies the
Compressed Data Type:
As MULE doesn't allow next hop MTA/MDA to return immediate Response Codes for FROM-line or any of the recipients in RCPT-line,
MTAs/MDAs that are compliant with this specification that receive a message that can't be relayed further or delivered
MUST generate a non delivery DSN report message which includes message/delivery-status
body part and submit it using MULE to the FROM-line return-path address.
MULE relays (unlike MULE MDAs) don't need to verify that they understand all FROM-line and/or RCPT-line parameters.
This keeps relay-only implementations simpler and avoids the need to upgrade them when MULE MDAs are updated to support
extra SMTP extensions.A gateway from Internet Mail to MULE acts as an SMTP server on the receiving side and
as a MULE client on the sending side.
When the content type for a message is an Internet message content type
(which may be 7bit, 8bit or binary MIME), this is transported using
ACP 142 as follows:
For each mail message a BSMTP-like payload is formed, as described in .
The created payload is compressed and encoded as specified in .
The compressed payload is sent by P_MUL as a series of Address_PDU and one or more DATA_PDUs.
When the message has an associated MT-PRIORITY value ,
the MappedPriority(value) is included as the Priority field of corresponding ACP 142 PDUs,
including Address_PDU, DATA_PDUs, DISCARD_MESSAGE_PDU. Here MappedPriority(x) is defined as "6 - x".
The set of ACP 142 destinations for the message is derived from the next
hop MTAs for each of the recipients.
If a message is received by a gateway, through SMTP transfers using
the CHUNKING extension, the message is rebuilt by the receiving MTA
into its complete form and is then used as a single
MULE message payload.
Use of BINARYMIME extension is conveyed by inclusion of BODY=BINARY parameter in the FROM-line.
A gateway from MULE to Internet Mail acts as a MULE server on the receiving side and
as an SMTP client on the sending side.
Gatewaying from ACP 142 environment to Internet Email is the reverse of the process specified in .
The ACP 142 message is reassembled from one or more DATA_PDUs.
If the contentType-ShortForm value is 25, the BSMTP-like payload is extracted from compressedContent field
and uncompressed as specified in .
If the contentType-ShortForm value is not 25, it is handled as described in .
The BSMTP-like payload is converted to an SMTP transaction (see ).
(The first line of the BSMTP-like payload is prepended with "MAIL FROM:" and
each following line (until the empty line is encountered) is prepended with "RCPT TO:".
After skipping the empty delimiting line, the rest of the payload is the message body.
This can be either sent using DATA or a series of BDAT commands, depending on capabilities
of the receiving SMTP system.
For example, the presence of BODY=BINARY parameter in FROM-line would necessitate use of BDAT or
downconversion of the message to 7-bit compatible representation.)
ESMTP extension parameters to MAIL FROM and RCPT TO SMTP commands obtained from BSMTP-like payload
are processed according to specifications of the corresponding ESMTP extensions,
including dealing with absence of support for ESMTP extensions that correspond to MAIL FROM/RCPT TO parameters
found in the BSMTP-like payload.
Failures to extract or uncompress BSMTP-like payload should result in the receiver discarding such payloads.IANA is requested to create a new registry "Multicast Email SMTP extensions".
Registration procedure for the new registry is "Specification Required" ,
but the Designated Expert(s) will be appointed and managed by the editors of this document
together with the Independent Submissions Editor. Selected Designated Expert(s) should (collectively)
have good knowledge of SMTP protocol (and its extensions/extensibility mechanisms), and ACP 142
and its limitations.
Subsections of this section provide more details. In particular,
specifies instructions for the Designated Expert(s) and
defines the initial content of the registry.
The Designated Expert for the new "Multicast Email SMTP extensions" registry verifies that
the requested SMTP extension is already registered in the "SMTP Service Extensions" registry
in the "Mail Parameters" section of the IANA Website
or is well documented on a stable, publicly accessible web page.
the requested SMTP extension has the correct status as specified in .
When deciding on status, the Designated Expert(s) is provided with the following guidelines:
If the SMTP extension only affects commands other than
MAIL FROM/RCPT TO, then the status should be "N/A".
If the SMTP extension only applies to SMTP submission (and not to SMTP relay or final SMTP delivery),
then the status should be "N/A".
If the SMTP extension changes which commands are allowed during an SMTP transaction
(e.g. if it adds commands alternative to DATA or declares commands other than
MAIL FROM/RCPT TO/DATA/BDAT to be a part of SMTP transaction),
then the status should be "Disallowed" or "Special".
If the SMTP extension adds extra round trips during SMTP transaction,
then the status should be "Disallowed" or "Special".
Registration requests should include SMTP extension name, status (see ),
specification reference and may include an optional note.The following table summarizes how different SMTP extensions can be used with MULE.
Each extension has one of the following statuses: "Required" (required to be supported by MULE relays,
SMTP-to-MULE gateway or MULE-to-SMTP gateway),
"Disallowed" (incompatible with MULE),
"N/A" (not relevant, because they affect commands other than MAIL FROM and/or RCPT TO,
or only defined for SMTP Submission. Such extensions can still be used on the receiving SMTP side of SMTP-to-MULE gateway)
"Supported" (can be used with MULE, but requires bilateral agreement between sender and receiver),
or "Special". "Special" needs to be accompanied by an explanation.SMTP Extension Support in MULE:SMTP Extension KeywordReferenceStatusSIZERequired8BITMIMERequiredDSNRequiredMT-PRIORITYRequiredDELIVERBYRequiredBINARYMIMERequiredCHUNKINGSpecial (*)ENHANCEDSTATUSCODESSpecial (**)RRVSSupportedSUBMITTERSupportedPIPELININGN/ASTARTTLSN/AAUTHSpecial (***)BURLN/ANO-SOLICITINGN/ACHECKPOINTDisallowedCONNEGDisallowed(*) - SMTP CHUNKING MUST be supported on the receiving SMTP side of a SMTP-to-MULE gateway
and MAY be used on the sending side of MULE-to-SMTP gateway.
A MULE relay doesn't need to do anything special for this extension.
(**) - ENHANCEDSTATUSCODES extension is supported by including relevant status codes in DSN reports.(***) - The AUTH parameter to MAIL FROM command is "supported", but the rest of AUTH extension is not applicable to MULE.
Note that the above table is not exhaustive. Future RFCs can define how SMTP Extensions not listed above
can be used in MULE.
As MULE provides a service similar to SMTP, many of Security Considerations from
apply to MULE as well, in particular Sections 7.1, 7.2, 7.4, 7.6, 7.7, 7.9 of
still apply to MULE.
As MULE doesn't support capability negotiation or SMTP HELP command, Section 7.5 of
("Information Disclosure in Announcements") doesn't apply to MULE.As MULE doesn't support VRFY or EXPN SMTP commands, Section 7.3 of
("VRFY, EXPN, and Security") that talks about email harvesting doesn't apply to MULE.Arguably, it is more difficult to cause an application layer Denial-of-Service attack on
a MULE server than on an SMTP server. This is partially due to fact that ACP 142 is used
in radio/wireless networks with relatively low bandwidth and very long round trip time
(especially if EMCON is in force).
However, as MULE is using multicast, multiple MULE nodes can receive the same message
and spend CPU processing it, even if the message is addressed to recipients that are not going
to be handled by such nodes. As MULE lacks transport layer source authentication,
this can be abused by malicious senders.
For Security Considerations related to use of zlib compression see .Due to the multicast nature of MULE, it cannot use TLS or DTLS.
Accordingly, it does not support STARTTLS .
Users should not depend on hop-by-hop confidentiality or integrity protection
of mail transfered among MULE MTAs (in the same way they can't generally rely on use of
STARTTLS on SMTP MTA-to-MTA links), and should consider the use of end-to-end protection,
such as S/MIME .
Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
International Telecommunications UnionCommon Messaging strategy and proceduresSTANAG 4406 Edition 2: Military Message Handling System
Thank you to Steve Kille for suggestions, comments and corrections on this document.
Additional thank you goes to Barry Leiba, Sean Turner, Dave Crocker and Nick Hudson
for reviews and comments on this document.
Some text was borrowed from draft-riechmann-multicast-mail-00, thus work of authors of
that document is greatefully acknowledged.