Network Working Group D. Wilson Internet-Draft A. Melnikov, Ed. Intended status: Informational Isode Ltd Expires: November 11, 2017 May 10, 2017 Mail Transfer Protocol over ACP 142 draft-melnikov-email-over-pmul-00 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). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 11, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Wilson & Melnikov Expires November 11, 2017 [Page 1] Internet-Draft Email over ACP 142 May 2017 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Gatewaying from Internet Mail . . . . . . . . . . . . . . . . 4 3.1. Sending Internet Messages . . . . . . . . . . . . . . . . 4 3.1.1. BSMTP-like Payload construction . . . . . . . . . . . 4 3.1.2. Payload compression . . . . . . . . . . . . . . . . . 6 3.2. Error handling . . . . . . . . . . . . . . . . . . . . . 7 3.3. Use of BDAT . . . . . . . . . . . . . . . . . . . . . . . 8 4. Gatewaying to Internet Mail . . . . . . . . . . . . . . . . . 8 4.1. Error handling . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5.1. Mapping of existing SMTP extensions to MULE . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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. Wilson & Melnikov Expires November 11, 2017 [Page 2] Internet-Draft Email over ACP 142 May 2017 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 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. 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]. Wilson & Melnikov Expires November 11, 2017 [Page 3] Internet-Draft Email over ACP 142 May 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 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". 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]. The receiver MAY accept BINARYMIME [RFC3030] 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. For the initial case, the assumption is made that a whole ACP 142 network either supports the Internet content type or does not. 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 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. Wilson & Melnikov Expires November 11, 2017 [Page 4] Internet-Draft Email over ACP 142 May 2017 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 Section 3.1.2 for more details). Example of a BSMTP-like payload MT-PRIORITY=4 BODY=8BITMIME RET=HDRS ENVID=QQ314159 NOTIFY=SUCCESS,FAILURE ORCPT=rfc822;Bob@enterprise.example.net NOTIFY=SUCCESS,FAILURE From: from@example.com To: To1 , To2 Date: 27 Apr 2017 16:17 +0100 Subject: a test MIME-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit This is worth 100 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 OCTET = reverse-path = forward-path = mail-parameters = rcpt-parameters = Wilson & Melnikov Expires November 11, 2017 [Page 5] Internet-Draft Email over ACP 142 May 2017 3.1.2. Payload compression BSMTP-like payload (Section 3.1.1) is compressed using zlibCompress and placed in the compressedContent field of the CompressedContentInfo element defined in Section 4.2.6 of [STANAG-4406]. 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: id-mmhs-CDT ID ::= { iso(1) identified-organization(3) nato(26) stanags(0) mmhs(4406) object-identifiers(0) id-mcont(4) 2 } Wilson & Melnikov Expires November 11, 2017 [Page 6] Internet-Draft Email over ACP 142 May 2017 The Compressed Data Type are defined by the following ASN.1 type: DEFINITIONS ::= BEGIN CompressedData ::= SEQUENCE { compressionAlgorithm CompressionAlgorithmIdentifier, compressedContentInfo CompressedContentInfo } CompressionAlgorithmIdentifier ::= CHOICE { algorithmID-ShortForm [0] AlgorithmID-ShortForm, algorithmID-OID [1] OBJECT IDENTIFIER } AlgorithmID-ShortForm ::= INTEGER { zlibCompress (0) } CompressedContentInfo ::= SEQUENCE { CHOICE { contentType-ShortForm [0] ContentType-ShortForm, contentType-OID [1] OBJECT IDENTIFIER }, compressedContent [0] EXPLICIT OCTET STRING } ContentType-ShortForm ::= INTEGER { unidentified (0), external (1), -- identified by the object-identifier -- of the EXTERNAL content p1 (2), p3 (3), p7 (4) } END 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. Wilson & Melnikov Expires November 11, 2017 [Page 7] Internet-Draft Email over ACP 142 May 2017 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. BURL [RFC4468] SMTP extension only applies to SMTP Submission, so it is already mapped to BDAT/DATA by the time it reaches MULE. 4. Gatewaying to Internet Mail TBD. 4.1. Error handling TBC. Need to describe how to handle FROM-line or RCPT-line parameters that we don't understand. 5. IANA Considerations TBD. Need a new registry that specifies which SMTP extensions can be gatewayed to MULE. 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". Wilson & Melnikov Expires November 11, 2017 [Page 8] Internet-Draft Email over ACP 142 May 2017 +------------------------+-----------+-------------------------+ | SMTP Extension Keyword | Reference | Status | +------------------------+-----------+-------------------------+ | 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 | +------------------------+-----------+-------------------------+ 6. Security Considerations TBD. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Wilson & Melnikov Expires November 11, 2017 [Page 9] Internet-Draft Email over ACP 142 May 2017 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, DOI 10.17487/RFC1870, November 1995, . [RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, DOI 10.17487/RFC2852, June 2000, . [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, DOI 10.17487/RFC3461, January 2003, . [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, DOI 10.17487/RFC3464, January 2003, . [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages", STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, . [RFC6710] Melnikov, A. and K. Carlberg, "Simple Mail Transfer Protocol Extension for Message Transfer Priorities", RFC 6710, DOI 10.17487/RFC6710, August 2012, . [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed., "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, DOI 10.17487/RFC6152, March 2011, . [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, DOI 10.17487/RFC3030, December 2000, . Wilson & Melnikov Expires November 11, 2017 [Page 10] Internet-Draft Email over ACP 142 May 2017 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [ACP142A] "Common Messaging strategy and procedures", ACP 142(A), August 2008. [STANAG-4406] "STANAG 4406 Edition 2: Military Message Handling System", STANAG 4406 Ed. 2, March 2005. 7.2. Informative References [RFC1845] Crocker, D., Freed, N., and A. Cargille, "SMTP Service Extension for Checkpoint/Restart", RFC 1845, DOI 10.17487/RFC1845, September 1995, . [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, DOI 10.17487/RFC2034, October 1996, . [RFC2442] Freed, N., Newman, D., Belissent, J., and M. Hoy, "The Batch SMTP Media Type", RFC 2442, DOI 10.17487/RFC2442, November 1998, . [RFC2920] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920, September 2000, . [RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension", RFC 3865, DOI 10.17487/RFC3865, September 2004, . [RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for Content Conversion", RFC 4141, DOI 10.17487/RFC4141, November 2005, . [RFC4405] Allman, E. and H. Katz, "SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message", RFC 4405, DOI 10.17487/RFC4405, April 2006, . [RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468, DOI 10.17487/RFC4468, May 2006, . Wilson & Melnikov Expires November 11, 2017 [Page 11] Internet-Draft Email over ACP 142 May 2017 [RFC7293] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid- Since Header Field and SMTP Service Extension", RFC 7293, DOI 10.17487/RFC7293, July 2014, . Wilson & Melnikov Expires November 11, 2017 [Page 12] Internet-Draft Email over ACP 142 May 2017 Appendix A. Acknowledgements Thank 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. Authors' Addresses David Wilson Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP UK EMail: David.Wilson@isode.com Alexey Melnikov (editor) Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP UK EMail: Alexey.Melnikov@isode.com Wilson & Melnikov Expires November 11, 2017 [Page 13]