draft-melnikov-email-over-pmul is proposed for publication as an Informational
Independent Submission RFC.
It describes a proprietary implementation of Multicast Email (MULE) over P_MUL,
a reliable multicast protocol also known as ACP-142. The document is clear that
the work is not the output of the IETF and is presented chiefly for the
purposes of facilitating inteoperable implementations and debugging live
networks.
The document was first brought to the ISE as revision -01 in September 2017.
Since then it has had detailed review on behalf of the ISE by Sean Turner,
Barry Leiba, amd Dave Crocker. Final review by the ISE led to a number of
changes (largely of tone and editorial in nature).
The authors note that there is no relevant IETF WG and so this document was
never submitted for publication on IETF Stream. They did advertise the document
on ietf-smtp@ietf.org, but didn't receive any reviews there.
NOTE WELL. This document asks IANA to create a codepoint registry with
allocation policy 'Specification Required' under the care of a Designateed
Expert. This document and the ISE are clear that the ISE is responsible for
appointing the initial DEs, for finding substitute DEs in the future, and for
acting as backstop if DEs cannot be foun or are unresponsive. This has been
discussed with IANA who have agreed the process.
The initial reviews by the three reviewers are presented below for information.
=============
Review of: Mail Transfer Protocol over ACP 142
I-D: draft-melnikov-email-over-pmul-01
Reviewer: D. Crocker
Review date:
Summary:
The draft specifies an adaptation of SMTP, to operate over a
multicast medium, specifically ACP 142. It leverages the lower-layer,
multicast router, for fan-out to multiple receiving MTAs. It further
adapts to reduced interaction, for environments that restrict the
ability of receiving MTAs to respond in real-time.
The draft is submitted for Independent stream publication, so that
the primary acceptance criteria are: basic relevance to the Internet
technical community, absence of conflict with existing IETF work, and
general specification writing quality. The draft satisfies all three:
The draft is generally well-organized and well-written, although some
substantive improvements are recommended, below, including one technical
design concern I consider major. It seems likely that ACP 142 is of
limited interest to the general Internet technical community, since it
is used in a highly constrained administrative environment (some
military); however a multicast-based application protocol design should
very much be of interest to the community. Further I believe there is
no related IETF work in this space.
The design seems to have one major technical flaw, concerning
reliability. The document does not say this explicitly, but it relies
solely on the reliability of the lower-layer multicast transport for all
reliability services, except to send a failure DSN. That is, it changes
the email application protocol from an ACK model of reliability to a
NACK model -- the absence of a NACK is taken to mean that transmission
was successful. Such a reliance on lower layers for all aspects of
reliability has a long history of being problematic, dating back to the
Arpanet's NCP (TCP-equivalent) relying on the IMP packet switches. These
early problems were the reason that TCP and IP do not rely on the
underlying network for all aspects of reliability. Similarly, Internet
application-level protocols include connection-validation mechanisms in
order to detect a variety of lower-layer problems, such as connection to
the wrong host. The lesson is that the upper-layer needs to have its
own, active method of communicating success, as well as failure. The
easy solution to this, given the details of the current draft, is to
require a DSN for ALL messages, not just messages that fail; this will
increase traffic from receiving MTAs, but the current draft already
requires some equivalent traffic, so the change is in degree, not kind.
It appears that detail is missing, concerning ACP 142-specifics, for use
with MULE (or P_MUL, I'm not sure whether it's one or the other or both.)
Detailed Comments:
> Abstract
>
> 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).
>
> Table of Contents
...
> 3. Gatewaying from Internet Mail . . . . . . . . . . . . . . . . 4
"Gatewaying" involves a translation between two, related-but-different
environments. There should be some care in offering a model that
distinguishes the translation activity from the two, separate, 'native'
transfer activities. Making the distinction explicit usually simplifies
a specification or, at least, makes it easier to understand. A possible
diagram for this is offered below.
The current form of the draft implies that multicast is only a last-hop
tail and always gets translated to/from regular Internet Mail -- that
is, SMTP semantics. Perhaps that is the reality for the current
implementation but what if there were an entire, multi-cast based email
network. Would it still be translating everything to/from regular SMTP
semantics or would it stay in MULE packaging? I'd expect the latter; if
the decision is to cast MULE as only a stub activity to native SMTP,
then this should be stated explicitly.
In terms of documenting a translation process, this requires
specifications for each environment, with the translation mechanism
being distinct. We have specification for regular SMTP. The current
spec talks only about the translation, without having a clear
specification for the non-SMTP environment. The reader gets details
about that other environment, but not in a distinct, coherent fashion.
It appears that the email object is the same in both environments --
this should be stated explicitly -- so that it is only the email
transfer mechanisms that have difference. This should be made explicit.
(BTW, having a common message object means that there is an argument
that, therefore, both environments are Internet Mail. cf, RFC 1775...)
So, I'm suggesting a documentation style that has:
Internet Mail <--> Gateway <--> MULE
and document MULE as distinct from the Gateway processing. (This is
different from the multi-cast diagram the draft shows, farther down. (I
suspect that that existing diagram is of the MULE 'network'. So the
combined diagram would be something like:
+-------+ +-------+
| MTA 1 |<-\ /->| MTA 3 |
+-------+ +-----+ +-------+ \ +-------+ / +-------+
| MTA A |<--->| G/W |<--------------->| Router|<
+-------+ +-----+ +-------+ / +-------+ \ +-------+
| MTA 2 |<-/ \->| MTA 4 |
+-------+ +-------+
|< -------------- MULE ---------------->|
> 1. Introduction
>
> P_MUL [ACP142A] 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.
Other than the summary term "reliable multicast", the draft does not
give any summary of the functional characteristics of the reliability
mechanism. Especially given the signaling constraints imposed by having
EMCON, these reliability characteristics are likely to be quite unusual
and likely to have significance at the email transfer level. The
specification should bring these details out explicitly. Note that
while receiving MTAs have highly restrict response opportunities, they
do have /some/. However the characteristics of such response traffic,
in terms of frequency/latency or amount, are not provided, but should be.
> This illustrates a simple multicast scenario, where the same message
> has to be sent from MTA 1 to MTA 2 and to MTA 3.
>
> +-------+
> /->| MTA 2 |
> +-------+ +-------+ / +-------+
> | MTA 1 |<----->| Router|<
> +-------+ +-------+ \ +-------+
> \->| MTA 3 |
> +-------+
>
> Typical MTA Configuration
>
> Figure 1
>
> 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 paragraph doesn't make much sense to me. The "As" at the beginning
means that the first part should motivate/justify the latter part and I
don't see how "connectionless transport" has any relationship to
"reliable message transfer".
My guess is that the intended meaning is more along the lines of "P_Mul
employs a ....messages, that guarantees reliable message transfer, even
in those cases..."
Note however that the draft needs to deliver on that promise by
explaining how reliability is achieved.
>
> 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 [RFC5322] over ACP 142 P_Mul.
Consider promoting the name MULE into the title, since it is the handle
for what is being specified.
(BTW, since mules can't reproduce, there is some nice irony in having
the term used to refer to a multicast mechanism...)
> 2. Conventions Used in This Document
>
> 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 [RFC2119].
>
> This document is also using terminology from [RFC5321].
I feel obligated to make a plug for citing RFC 5598, since some of its
model and terminology are used here...
In general, the draft should use terminology a bit more carefully. For
example, when it says 'recipient' it seems to actually mean 'receiver'.
That is, it is referring to a receiving MTA rather than the addressed
end-user. (Casual, daily use conflates these commonly, but a
specification should be more careful.)
> Wilson & Melnikov Expires February 11, 2018 [Page 3]
>
> Internet-Draft Email over ACP 142 August 2017
>
>
> 3. Gatewaying from Internet Mail
>
> 3.1. Sending Internet Messages
>
> When the content type for a message is an Internet message content
> type (which may be 7bit, 8bit or binary MIME), this is transported
This sentence is a bit confusing. "Content-type" is a MIME term of art,
not a 'message' term. A 'message' does not have a content-type. A
message 'body' or a MIME 'body-part' does. It looks like the applicable
term that is used in SMTP service extensions, to cover what is meant
here, is "content body".
Language that is pedantic but precise might be:
[ACP142A] can be used for transmitting any Internet Mail message
content body that can be transferred by SMTP using 7bit, or 8bitMIME or
BINARYMIME.
However from the later discussion of Binary, I think the above statement
should NOT reference it, since it's only supported by bilateral agreement.
> using ACP 142 [ACP142A]. Firstly, for each mail message a BSMTP-like
> payload is formed, as described in Section 3.1.1. Secondly, the
> created payload is compressed and encoded as specified in
> Section 3.1.2. 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 [RFC6710], 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".
Personal preference for specification style: When a list is given --
especially a procedural sequence -- present it in list form, numbered if
it is a sequence. This facilities comprehension and later reference.
> The sender of the message can assume that the receiver supports the
> following ESMTP extensions: DSN [RFC3461], SIZE [RFC1870], 8BITMIME
> [RFC6152], MT-PRIORITY [RFC6710], DELIVERBY [RFC2852].
I suspect that 'can assume' is wrong. More likely is that is actually
meant as a normative set of baseline capabilities; so it needs to be
stated that way, with a MUST.
If it is /not/ a required set, then what happens if the sender makes the
assumption of support but the receiver doesn't actually do the support?
Especially in an environment with high latency for responses, I'd expect
this to kill interoperability.
> The receiver MAY accept BINARYMIME [RFC3030] SMTP extension. This is
> a matter for bilateral agreement. As the message content size can
Bilateral agreement is another term for "outside the standard". Private
parties can agree to anything they want. When a spec says something like
bilateral agreement, it is not specifying any technical or operational
detail that is useful.
So, here, the "MAY" is not a protocol option. Rather, it's permission
to have an out-of-band agreement between private parties. Hence, it is
a meaningless distraction from the substance of the specification.
The protocol standard form of the above is more like:
A sender MUST NOT rely on a receiver's support of BINARYMIME
[RFC3030] SMTP extension, in the absence of an explicit, bilateral
agreement.
> 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.
Where is the specification detail for doing this mapping? It needs to
be provided or cited.
Where is the rest of the detail for ACP 142-specific information, such
as the contentType-ShortForm value to use?
>
> 3.1.1. BSMTP-like Payload construction
>
> MULE uses BSMTP-like payload which differs from BSMTP [RFC2442].
> ESMTP is using capability negotiation, which is not practical when
> EMCON is used, as there is no way for a recipient to return
Perhaps: MULE is derived from BSMTP [RFC2442], with small
modifications. As with BSMTP, ESMTP capability negotiation is not used.
since receiver EMCON restrictions prohibit such real-time interaction.
> 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):
Nit: received -> transmitted
...
> ABNF for the BSMTP-like payload is:
>
> bsmtp-like-payload = envelope CRLF payload
> envelope = FROM-line 1*RCPT-line
> FROM-line = reverse-path [SP mail-parameters] CRLF
> RCPT-line = forward-path [SP rcpt-parameters] CRLF
>
> payload = *OCTET
> ; Conforms to message syntax as defined in RFC 5322 and extended in
MIME
MIME seems not to be formally cited in the draft.
Payload has no syntactic delimiter at the end? The basis for
termination should be defined explicitly.
> OCTET = <any 0-255 octet value>
> reverse-path = <as defined in RFC 5321>
> forward-path = <as defined in RFC 5321>
> mail-parameters = <as defined in RFC 5321>
> rcpt-parameters = <as defined in RFC 5321>
The ABNF should come before the example...
> 3.2. Error handling
>
> 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 [RFC6522]
> message which includes message/delivery-status body part [RFC3464]
> 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.
I suggest -- maybe strongly -- that the MULE environment be defined to
have mandatory support for a specific set of SMTP extensions and that
the presence of any additional -- ie, not specified in MULE --
extensions MUST force message rejection, unless there is a private,
bilateral agreement in place for support of the extension's use.
That is, define a simple, rigid environment and define variations as
being outside the spec. This permits interoperability. Any other
approach threatens it.
> 3.3. Use of BDAT
>
> 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 [RFC3030] might need to be
> enabled in the FROM-line.
"used by by the SMTP side" probably is clear, but I can also imagine
that it might not be. To make a bit more clear, perhaps:
If a message is received by a gateway, through SMTP transfers
using the CHUNKING extension, the message is rebuilt by the SMTP
receiving MTA into its complete, single, original form and is then used
as a single MULE payload.
I suggest dropping the reference here to BINARYMIME, since the use of
that extension is deferred to private, bilateral agreement. That is,
it's not part of the spec.
>
> BURL [RFC4468] SMTP extension only applies to SMTP Submission, so it
> is already mapped to BDAT/DATA by the time it reaches MULE.
Huh?
This is not a Submission scenario. Hence it is (or at least, should be)
outside the scope of this draft.
>
> 4. Gatewaying to Internet Mail
>
> Gatewaying from ACP 142 environment to Internet Email is the reverse
> of the process specified in Section 3.1. Firstly, the message is
> reassembled from one or more DATA_PDUs. Secondly, if the
> contentType-ShortForm value is 25, the BSMTP-like payload is
This contentType-ShortForm value is not specified in the ACP 142
creation process.
> extracted from compressedContent field and uncompressed as specified
> in Section 3.1.2. Thirdly, the BSMTP-like payload is converted to
> SMTP transaction (see Section 3.1.1). (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.)
Again, I suggest putting a list of actions like this into a
list/sequence format.
>
> 4.1. Error handling
>
> 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.
>
> 5. IANA Considerations
>
> 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 Section 5.1) and specification reference.
Hmmm. This is interest. First, good that the table is being defined.
Second, I believe it is seeking to specify a subset of SMTP extensions
that are required to be supported by implementations. Language to that
effect needs to be provided, preferably with some indication of that
also in the name of the table; something like "SMTP Extension Support in
Multicast Email". Second, I think it is not necessary -- and might also
invite divergence errors -- to have an entry cite the RFC specification,
since that's already provided in the 'parent' SMTP service extensions table.
That is, the current table should be defined as listing a subset of the
existing SMTP Service Extensions table (RFC 5321), to indicate which
extensions MUST be supported by a MULE implementation.
> Wilson & Melnikov Expires February 11, 2018 [Page 8]
>
> Internet-Draft Email over ACP 142 August 2017
>
>
> 5.1. Mapping of existing SMTP extensions to MULE
>
> 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".
1. I am not sure I understand the difference between Required and
Supported. I suspect it means that the gateway MUST generate the
Required ones and MAY generate the Supported ones? Otherwise, what is
the point of saying the support is 'required' on the SMTP side?
2. Listing extensions that are /not/ to be supported highlights a
problem with how this table is currently specified: the implication is
that it is attempting to be exhaustive and this will require it always
be in sync with the parent, SMTP Extensions, table. It need not do
that. That is, it only needs to specify the extensions that /are/ part
of MULE, not those that aren't. It it is not part of MULE, it is out of
scope and, therefore, should not be mentioned.
3. The focus on the 'SMTP side' again raises a problem with not
distinguishing gateway from native MULE: There is nothing that
specifies what MULE supports, although it's implied. Hence I think that
things get simpler if the table is cast as I've suggested above: "SMTP
Extension Support in Multicast Email". That is, as native MULE detail,
with a column indicating that use is Required or Allowed. Text
specifying MULE implementation then dictates that it MUST generate all
of the Required extensions and must accept all of the Required and
Allowed extensions. This applies to the MULE implementation in a gateway.
> +---------------------+-----------+---------------------------------+
> | SMTP Extension | Reference | Status |
> | Keyword | | |
> +---------------------+-----------+---------------------------------+
> | SIZE | [RFC1870] | Required |
> | | | |
> | 8BITMIME | [RFC6152] | Required |
> | | | |
> | DSN | [RFC3461] | Required |
> | | | |
> | MT-PRIORITY | [RFC6710] | Required |
> | | | |
> | DELIVERBY | [RFC2852] | Required |
> | | | |
> | BINARYMIME | [RFC3030] | Supported |
> | | | |
> | PIPELINING | [RFC2920] | N/A |
> | | | |
> | CHUNKING | [RFC3030] | N/A |
> | | | |
> | BURL | [RFC4468] | N/A |
> | | | |
> | ENHANCEDSTATUSCODES | [RFC2034] | Supported (through DSN) |
> | | | |
> | CHECKPOINT | [RFC1845] | Disallowed |
> | | | |
> | RRVS | [RFC7293] | Supported |
> | | | |
> | NO-SOLICITING | [RFC3865] | N/A |
> | | | |
> | SUBMITTER | [RFC4405] | Supported |
> | | | |
> | CONNEG | [RFC4141] | Disallowed |
> | | | |
> | STARTTLS | [RFC3207] | N/A |
> | | | |
> | AUTH | [RFC4954] | N/A (MAIL FROM parameter is |
> | | | supported) |
> +---------------------+-----------+---------------------------------+
=============
Sean Turner
Alexey asked me to review this draft. I’m no mail expert like Alexey, but I've
got some experience with ACPs.
Comments:
s1, penultimate paragraph: Good to point out that the groups need to be
established for this to work. The only thing I think that’s missing there is
that they need to be established before messages start getting sent. I can see
that it might be implied but it’s not explicit stated.
s3.2: any particular reason you didn’t use the CMS Compressed Data content type
from RFC 3274? AH! s,o the point is that you want to avoid sending the
algorithm OID (and the EncapsulatedContentInfo OID). Maybe that’s fine, but by
omitting the version field, specifying only one compression algorithm, and
having only 5 content types you are saying there’s no intent to ever add other
compression values or content types. I.e., it's one and done? To make any
changes as specified you’re going to have to get a new content type OID. Might
be good to just state that up front if that’s the case. I’m pretty sure nobody
is investing any money in new MHS content types.
Actually that makes me wonder, why isn’t the only content type defined P1?
Isn’t P1 MTA-MTA and P3 and P7 MTA-UA?
s3.2: You should probably point to the zlib long form OID in these registries
for the long form:
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-3
s4.1: There’s a TBC - to be covered?
s6: Is there an expert pool or is it just one person for the registry’s DE?
s7: Is still TBD :)
Reference nits:
Refer to 2015 ASN.1?
I can’t really find ACP142 anywhere. Now I’m not sure that’s really a show
stopped because like anybody building this is just building it for the fun of
it. They’ve been given it. But, maybe I’m just not searching for it
correctly? I also get the impression that somebody does have it because there
are all kinds of wireshark tools.
Because there’s two version of ACP 142. I think that somewhere up front you
should use ACP 142(A) so that those in the know know it’s not the ’01 version.
Editorial nits:
s3.1: r/CR LF)/CR LF).
s3.1: r/CRLF.CRLF/CRLF. CRLF
s3.1: r/Example of a BSMTP-like payload/
An example of BSMTP-like payload follows
===============
>> On 11/10/17 08:19, Barry Leiba wrote:
>>> Hi, Nevil. Sorry I couldn't get to this until today.
>>>
>>> Alexey does some work with military contract that this appears to
>>> relate to, and we decided some time ago that most of the specific
>>> requirements that come from that don't really belong in the IETF
>>> stream. So it seems perfect for the Independent stream, and I see no
>>> problem with the protocol description relative to that.
>>>
>>> The only issue I have is in the IANA Considerations, where he asks
>>> IANA to define a registry with the Specification Required policy.
>>> First, quotation of the policy needs to be accompanied by a normative
>>> reference to RFC 8126, which is missing.
>>>
>>> But second, "Expert Review" and "Specification Required" mean that the
>>> IESG has to appoint and manage a designated expert, and we decided
>>> some time ago that it's not appropriate for the Independent stream to
>>> commit the IESG to that, and that Independent stream documents
>>> shouldn't use those registration policies.
>>>
>>> What we decided was that it would be appropriate to cite the policy
>>> but to explicitly specify a different mechanism for expert review.
>>> So, perhaps "Specification Required, but without designated-expert
>>> review of the specification," or "Specification Required, but
>>> <organization X> appoints and manages the designated expert."
>>>
>>> Barry