Skip to main content

Mail Transfer Protocol over ACP 142
draft-melnikov-email-over-pmul-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8494.
Authors David Wilson , Alexey Melnikov
Last updated 2017-09-26 (Latest revision 2017-08-10)
RFC stream Independent Submission
Formats
IETF conflict review conflict-review-melnikov-email-over-pmul, conflict-review-melnikov-email-over-pmul, conflict-review-melnikov-email-over-pmul, conflict-review-melnikov-email-over-pmul, conflict-review-melnikov-email-over-pmul, conflict-review-melnikov-email-over-pmul
Stream ISE state Finding Reviewers
Consensus boilerplate Unknown
Document shepherd (None)
IESG IESG state Became RFC 8494 (Informational)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-melnikov-email-over-pmul-01
Network Working Group                                          D. Wilson
Internet-Draft                                          A. Melnikov, Ed.
Intended status: Informational                                 Isode Ltd
Expires: February 11, 2018                               August 10, 2017

                  Mail Transfer Protocol over ACP 142
                   draft-melnikov-email-over-pmul-01

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 February 11, 2018.

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 February 11, 2018               [Page 1]
Internet-Draft             Email over ACP 142                August 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 . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     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 February 11, 2018               [Page 2]
Internet-Draft             Email over ACP 142                August 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 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
   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.

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.

      After that, there is a separate line for each recipient of the
      message.  The value is what would follow "RCPT TO:" in the SMTP

Wilson & Melnikov       Expires February 11, 2018               [Page 4]
Internet-Draft             Email over ACP 142                August 2017

      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

<from@example.com> MT-PRIORITY=4 BODY=8BITMIME RET=HDRS ENVID=QQ314159
<to1@example.net> NOTIFY=SUCCESS,FAILURE ORCPT=rfc822;Bob@enterprise.example.net
<to2@example.net> NOTIFY=SUCCESS,FAILURE

From: from@example.com
To: To1 <to1@example.net>, To2 <to2@example.net>
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 <poundsign>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 = <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>

Wilson & Melnikov       Expires February 11, 2018               [Page 5]
Internet-Draft             Email over ACP 142                August 2017

3.1.2.  Payload compression

   BSMTP-like payload (Section 3.1.1) is compressed using zlibCompress
   [RFC1951] 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 [ITU.X690.2002]
   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 February 11, 2018               [Page 6]
Internet-Draft             Email over ACP 142                August 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 February 11, 2018               [Page 7]
Internet-Draft             Email over ACP 142                August 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

   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
   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.)

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.

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".

   +---------------------+-----------+---------------------------------+
   | 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)                      |
   +---------------------+-----------+---------------------------------+

Wilson & Melnikov       Expires February 11, 2018               [Page 9]
Internet-Draft             Email over ACP 142                August 2017

6.  Security Considerations

   TBD.

7.  References

7.1.  Normative References

   [ACP142A]  "Common Messaging strategy and procedures", ACP 142(A),
              August 2008.

   [ITU.X690.2002]
              International Telecommunications Union, "Information
              Technology - ASN.1 encoding rules: Specification of Basic
              Encoding Rules (BER), Canonical Encoding Rules (CER) and
              Distinguished Encoding Rules (DER)", ITU-T Recommendation
              X.690, July 2002.

   [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,
              <http://www.rfc-editor.org/info/rfc1870>.

   [RFC1951]  Deutsch, P., "DEFLATE Compressed Data Format Specification
              version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
              <http://www.rfc-editor.org/info/rfc1951>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2852]  Newman, D., "Deliver By SMTP Service Extension", RFC 2852,
              DOI 10.17487/RFC2852, June 2000,
              <http://www.rfc-editor.org/info/rfc2852>.

   [RFC3030]  Vaudreuil, G., "SMTP Service Extensions for Transmission
              of Large and Binary MIME Messages", RFC 3030,
              DOI 10.17487/RFC3030, December 2000,
              <http://www.rfc-editor.org/info/rfc3030>.

   [RFC3461]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)",
              RFC 3461, DOI 10.17487/RFC3461, January 2003,
              <http://www.rfc-editor.org/info/rfc3461>.

Wilson & Melnikov       Expires February 11, 2018              [Page 10]
Internet-Draft             Email over ACP 142                August 2017

   [RFC3464]  Moore, K. and G. Vaudreuil, "An Extensible Message Format
              for Delivery Status Notifications", RFC 3464,
              DOI 10.17487/RFC3464, January 2003,
              <http://www.rfc-editor.org/info/rfc3464>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <http://www.rfc-editor.org/info/rfc5234>.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <http://www.rfc-editor.org/info/rfc5321>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <http://www.rfc-editor.org/info/rfc5322>.

   [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,
              <http://www.rfc-editor.org/info/rfc6152>.

   [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,
              <http://www.rfc-editor.org/info/rfc6522>.

   [RFC6710]  Melnikov, A. and K. Carlberg, "Simple Mail Transfer
              Protocol Extension for Message Transfer Priorities",
              RFC 6710, DOI 10.17487/RFC6710, August 2012,
              <http://www.rfc-editor.org/info/rfc6710>.

   [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,
              <http://www.rfc-editor.org/info/rfc1845>.

   [RFC2034]  Freed, N., "SMTP Service Extension for Returning Enhanced
              Error Codes", RFC 2034, DOI 10.17487/RFC2034, October
              1996, <http://www.rfc-editor.org/info/rfc2034>.

Wilson & Melnikov       Expires February 11, 2018              [Page 11]
Internet-Draft             Email over ACP 142                August 2017

   [RFC2442]  Freed, N., Newman, D., Belissent, J., and M. Hoy, "The
              Batch SMTP Media Type", RFC 2442, DOI 10.17487/RFC2442,
              November 1998, <http://www.rfc-editor.org/info/rfc2442>.

   [RFC2920]  Freed, N., "SMTP Service Extension for Command
              Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920,
              September 2000, <http://www.rfc-editor.org/info/rfc2920>.

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
              February 2002, <http://www.rfc-editor.org/info/rfc3207>.

   [RFC3865]  Malamud, C., "A No Soliciting Simple Mail Transfer
              Protocol (SMTP) Service Extension", RFC 3865,
              DOI 10.17487/RFC3865, September 2004,
              <http://www.rfc-editor.org/info/rfc3865>.

   [RFC4141]  Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for
              Content Conversion", RFC 4141, DOI 10.17487/RFC4141,
              November 2005, <http://www.rfc-editor.org/info/rfc4141>.

   [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,
              <http://www.rfc-editor.org/info/rfc4405>.

   [RFC4468]  Newman, C., "Message Submission BURL Extension", RFC 4468,
              DOI 10.17487/RFC4468, May 2006,
              <http://www.rfc-editor.org/info/rfc4468>.

   [RFC4954]  Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
              Extension for Authentication", RFC 4954,
              DOI 10.17487/RFC4954, July 2007,
              <http://www.rfc-editor.org/info/rfc4954>.

   [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,
              <http://www.rfc-editor.org/info/rfc7293>.

Wilson & Melnikov       Expires February 11, 2018              [Page 12]
Internet-Draft             Email over ACP 142                August 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 February 11, 2018              [Page 13]