Mail Transfer Protocol over ACP 142
Isode Ltd14 Castle MewsHamptonMiddlesexTW12 2NPUKDavid.Wilson@isode.comIsode Ltd14 Castle MewsHamptonMiddlesexTW12 2NPUKAlexey.Melnikov@isode.comP_Mul
ACP 142 defines P_Mul, which is a protocol for reliable multicast in bandwidth constrained and
delayed acknowledgement (EMCON) environments running over UDP.
This document is a specification of the basic protocol for
electronic mail transfer over P_MUL. It also described how to gateway
this basic protocol to/from Simple Mail Transfer Protocol (RFC 5321).
P_MUL is a protocol for reliable multicast in bandwidth constrained and
delayed acknowledgement environments running over UDP. The objectives of
this protocol 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
conditions. EMCON (Emission Control) 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 EMCON
conditions. EMCON condition means that a receiving node is able to
receive messages, but it cannot - for a relitive long time (hours or
even days) - acknowledge the received messages.
Using a multicast instead of an unicast communication service in the
above MTA configuration only one message transmission from MTA 1 to
the Router is required, instead of two as required with unicast.
This saves the transmision of one message 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.
As P_Mul employs a connectionless transport protocol to transmit
messages, the reliable message transfer is guaranteed 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 to one or more multicast groups of each participating
node.
This document defines application protocol MULE (Multicast Email) for transferring Internet Mail messages
over ACP 142 P_Mul.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in
.This document is also using terminology from .
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 .
Firstly, for each mail message a BSMTP-like payload is formed, as described in .
Secondly, the created payload is compressed and encoded as specified in .
Thirdly, 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 "-1 * x + 6".
The sender of the message can assume that the receiver supports the
following ESMTP extensions:
DSN ,
SIZE ,
8BITMIME ,
MT-PRIORITY ,
DELIVERBY .
The receiver MAY accept BINARYMIME SMTP extension. This is a matter for bilateral
agreement. 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.
The set of ACP 142 destinations for the message is derived from the next
hop MTAs for each of the recipients.
MULE uses BSMTP-like payload which differs from BSMTP .
ESMTP is using capability negotiation, which is not practical when EMCON is used,
as there is no way for a recipient to return capabilities before a message can be sent. For that reason,
there is no point in including EHLO capabilities. "MAIL FROM:" and "RCPT TO:" prefixes can also be 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 CRLF.CRLF as the end of
the message content is indicated by the end of the data
(See for more details).
BSMTP-like payload () is compressed using zlibCompress and
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, ASN.1 of the CompressedData structure is included below.
The contentType-ShortForm value used by MULE is 25.
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 to return immediate Response Codes for FROM-line or any of recipients in RCPT-line,
MTAs that are compliant with this specification that receive a message that can't be 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.TBC: Also need to describe how to handle FROM-line or RCPT-line parameters that we don't understand.
Probably, they can be rejected on receipt or be relayed to the final destination/gateway, which can decide what to do with them.If SMTP CHUNKING extension is used by the SMTP side, data from all BDAT blocks
is concatenated into continuous block and is used as the message payload.
Use of BINARYMIME might need to be enabled in the FROM-line.BURL SMTP extension only applies to SMTP Submission,
so it is already mapped to BDAT/DATA by the time it reaches MULE.Gatewaying from ACP 142 environment to Internet Email is the reverse of the process specified in .
Firstly, the message is reassembled from one or more DATA_PDUs.
Secondly, if the contentType-ShortForm value is 25, the BSMTP-like payload is extracted from compressedContent field
and uncompressed as specified in .
Thirdly, the BSMTP-like payload is converted to 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.)
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.
Failures to extract or uncompres BSMTP-like payload are handled according to ACP 142.IANA is requested to create a new registry "Multicast Email SMTP extensions". SMTP extensions registered in the "SMTP Service Extensions" IANA registry
can be registered in this new registry. Registration procedure for the new registry is "Specification Required".
Registration requests should include SMTP extension name, status (see ) and specification reference.The following table summarizes how different SMTP extensions can be gatewayed to/from MULE.
Each extension has one of the following statuses: "required" (required to be supported on the SMTP side),
"disallowed" (incompatible with this protocol),
"N/A" (not relevant, because they affect commands other than MAIL FROM and RCPT TO. Can be used on the SMTP side) or "supported".SMTP Extension KeywordReferenceStatusSIZERequired8BITMIMERequiredDSNRequiredMT-PRIORITYRequiredDELIVERBYRequiredBINARYMIMESupportedPIPELININGN/ACHUNKINGN/ABURLN/AENHANCEDSTATUSCODESSupported (through DSN)CHECKPOINTDisallowedRRVSSupportedNO-SOLICITINGN/ASUBMITTERSupportedCONNEGDisallowedSTARTTLSN/AAUTHN/A (MAIL FROM parameter is supported)TBD.
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 SystemThank you to Steve Kille for suggestions, comments and corrections on this document.Some text was borrowed from draft-riechmann-multicast-mail-00, thus work of authors of that document is greatefully acknowledged.