idnits 2.17.1 draft-melnikov-email-over-pmul-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 14 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 22, 2017) is 2346 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 318 -- Looks like a reference, but probably isn't: '1' on line 316 == Unused Reference: 'RFC5234' is defined on line 500, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Wilson 3 Internet-Draft A. Melnikov, Ed. 4 Intended status: Informational Isode Ltd 5 Expires: May 26, 2018 November 22, 2017 7 Multicast Email (MULE) over ACP 142 8 draft-melnikov-email-over-pmul-03 10 Abstract 12 ACP 142 defines P_MUL, which is a protocol for reliable multicast in 13 bandwidth constrained and delayed acknowledgement (EMCON) 14 environments running over UDP. This document is a specification of 15 the basic protocol for electronic mail transfer over P_MUL. It also 16 described how to gateway this basic protocol to/from Simple Mail 17 Transfer Protocol (RFC 5321). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 26, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 55 3. MULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Gatewaying from Internet Mail to MULE . . . . . . . . . . . . 5 57 4.1. Sending Internet Messages . . . . . . . . . . . . . . . . 5 58 4.1.1. BSMTP-like Payload construction . . . . . . . . . . . 5 59 4.1.2. Payload compression . . . . . . . . . . . . . . . . . 7 60 4.2. Error handling . . . . . . . . . . . . . . . . . . . . . 8 61 4.3. Use of BDAT . . . . . . . . . . . . . . . . . . . . . . . 9 62 5. Gatewaying from MULE to Internet Mail . . . . . . . . . . . . 9 63 5.1. Error handling . . . . . . . . . . . . . . . . . . . . . 9 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 6.1. Mapping of existing SMTP extensions to MULE . . . . . . . 10 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 8.2. Informative References . . . . . . . . . . . . . . . . . 13 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 P_MUL [ACP142A] is a protocol for reliable multicast in bandwidth 76 constrained and delayed acknowledgement environments running over 77 UDP. The objectives of this protocol are first to take advantage of 78 the bandwidth saving feature of using the multicast service as 79 supported by modern computer networks and second to allow message 80 transfer under EMCON conditions. EMCON (Emission Control) or "Radio 81 Silence" means that, although receiving nodes are able to receive 82 messages, they are not able to acknowledge the receipt of messages. 84 The objective of this protocol is to take advantage of multicast 85 communication for the transfer of messages between MTAs (Message 86 Transfer Agents) on a single multicast network under EMCON 87 conditions. EMCON condition means that a receiving node is able to 88 receive messages, but it cannot - for a relitive long time (hours or 89 even days) - acknowledge the received messages. 91 This illustrates a simple multicast scenario, where the same message 92 has to be sent from MTA 1 to MTA 2 and to MTA 3. 94 +-------+ 95 /->| MTA 2 | 96 +-------+ +-------+ / +-------+ 97 | MTA 1 |<----->| Router|< 98 +-------+ +-------+ \ +-------+ 99 \->| MTA 3 | 100 +-------+ 102 Typical MTA Configuration 104 Figure 1 106 Using a multicast instead of an unicast communication service in the 107 above MTA configuration only one message transmission from MTA 1 to 108 the Router is required, instead of two as required with unicast. 109 This saves the transmision of one message and thus network bandwidth 110 utilisation. Depending on the network bandwidth (in some radio 111 networks less than 9.6 Kb/s) this saving can be of vital importance. 112 The saving in bandwidth utilisation becomes even greater with every 113 additional receiving MTA. 115 P_MUL employs a connectionless transport protocol to transmit 116 messages, that guarantees reliable message transfer, even in those 117 cases, when for a certain period of time one or more of the receiving 118 MTAs are not able or allowed to acknowledge completely received 119 messages. 121 This protocol specification requires fixed multicast groups and a 122 well known knowledge at each participating node(MTA) about the group 123 memberships to one or more multicast groups of each participating 124 node. 126 This document defines application protocol MULE (Multicast Email) for 127 transferring Internet Mail messages [RFC5322] over ACP 142 P_MUL. 129 2. Conventions Used in This Document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 This document is also using terminology from [RFC5321] and [RFC5598]. 137 3. MULE 139 MULE is an electronic mail transport of Internet messages [RFC5322] 140 over ACP 142 P_MUL network. It provided service similar to SMTP 141 [RFC5321]. 143 An important feature of MULE is its capability to transport mail 144 across multiple networks, usually referred to as "MULE mail 145 relaying". A network consists of the mutually-ACP142-accessible 146 nodes. Using MULE, a process can transfer mail to another process on 147 the same ACP 142 network or to some other ACP 142 network via a relay 148 or gateway process accessible to both networks. 150 Relaying a message using MULE is performed as follows: 152 1. The message is reassembled from one or more DATA_PDUs. 154 2. If the contentType-ShortForm value is 25, the BSMTP-like payload 155 is extracted from compressedContent field and uncompressed as 156 specified in Section 4.1.2. If the contentType-ShortForm value 157 is not 25, it is handled as described in [ACP142A]. 159 3. The list of recipients is extracted from RCPT-lines (see 160 Section 4.1.1). The set of ACP 142 destinations for the message 161 is created by extracting right hand sides (hostnames) of each 162 RCPT-line, eliminating duplicates and then converting each 163 hostname into next ACP 142 destination using static 164 configuration. 166 4. For each unique ACP 142 destination, the following steps are 167 performed: 169 A. A new BSMTP-like payload is formed, as described in 170 Section 4.1.1, which only contains RCPT-lines that correspond 171 to recipients that can receive mail through the ACP 142 172 destination. 174 B. The created payload is compressed and encoded as specified in 175 Section 4.1.2. 177 C. The compressed payload is sent by P_MUL as a series of 178 Address_PDU and one or more DATA_PDUs. When the message has 179 an associated MT-PRIORITY value [RFC6710], the 180 MappedPriority(value) is included as the Priority field of 181 corresponding ACP 142 PDUs, including Address_PDU, DATA_PDUs, 182 DISCARD_MESSAGE_PDU. Here MappedPriority(x) is defined as "6 183 - x". 185 4. Gatewaying from Internet Mail to MULE 187 4.1. Sending Internet Messages 189 When the content type for a message is an Internet message content 190 type (which may be 7bit, 8bit or binary MIME), this is transported 191 using ACP 142 [ACP142A] as follows: 193 1. For each mail message a BSMTP-like payload is formed, as 194 described in Section 4.1.1. 196 2. The created payload is compressed and encoded as specified in 197 Section 4.1.2. 199 3. The compressed payload is sent by P_MUL as a series of 200 Address_PDU and one or more DATA_PDUs. When the message has an 201 associated MT-PRIORITY value [RFC6710], the MappedPriority(value) 202 is included as the Priority field of corresponding ACP 142 PDUs, 203 including Address_PDU, DATA_PDUs, DISCARD_MESSAGE_PDU. Here 204 MappedPriority(x) is defined as "6 - x". 206 The sender of the message can assume that the receiver supports the 207 following ESMTP extensions: DSN [RFC3461], SIZE [RFC1870], 8BITMIME 208 [RFC6152], MT-PRIORITY [RFC6710], DELIVERBY [RFC2852], BINARYMIME and 209 CHUNKING [RFC3030]. (As the message content size can always be 210 determined from the compression wrapper and the size of the envelope, 211 no special handling is needed for binary messages.) 213 The set of ACP 142 destinations for the message is derived from the 214 next hop MTAs for each of the recipients. 216 4.1.1. BSMTP-like Payload construction 218 MULE uses BSMTP-like payload which differs from BSMTP [RFC2442]. As 219 with BSMTP, ESMTP capability negotiation is not used, since receiver 220 EMCON restrictions prohibit such real-time interaction. For that 221 reason, there is no point in including EHLO capabilities. "MAIL 222 FROM:" and "RCPT TO:" prefixes can also be eluded in order to save a 223 few bytes. 225 For each received message, the corresponding BSMTP-like payload is 226 constructed as follows (Lines are terminated using CR LF): 228 The first line is what would be used for the data following "MAIL 229 FROM:" in the SMTP dialogue. I.e. it contains the return-path 230 address, within <>'s followed by any ESMTP extension parameters to 231 the MAIL FROM command. 233 After that, there is a separate line for each recipient of the 234 message. The value is what would follow "RCPT TO:" in the SMTP 235 dialogue, i.e. the recipient address within <>'s followed by any 236 ESMTP extension parameters to the corresponding RCPT TO command. 238 The list of recipients is terminated by an empty line (i.e. just 239 CR LF) 241 The message content follows the empty line. There is no need for 242 transparency ("dot stuffing") or terminating CRLF.CRLF as the end 243 of the message content is indicated by the end of the data (See 244 Section 4.1.2 for more details). 246 Example of a BSMTP-like payload 248 MT-PRIORITY=4 BODY=8BITMIME RET=HDRS ENVID=QQ314159 249 NOTIFY=SUCCESS,FAILURE ORCPT=rfc822;Bob@enterprise.example.net 250 NOTIFY=SUCCESS,FAILURE 252 From: from@example.com 253 To: To1 , To2 254 Date: 27 Apr 2017 16:17 +0100 255 Subject: a test 256 MIME-Version: 1.0 257 Content-type: text/plain; charset=utf-8 258 Content-transfer-encoding: 8bit 260 This is worth 100 262 ABNF for the BSMTP-like payload is: 264 bsmtp-like-payload = envelope CRLF payload 265 envelope = FROM-line 1*RCPT-line 266 FROM-line = reverse-path [SP mail-parameters] CRLF 267 RCPT-line = forward-path [SP rcpt-parameters] CRLF 269 payload = *OCTET 270 ; Conforms to message syntax as defined in RFC 5322 and extended in MIME 272 OCTET = 273 reverse-path = 274 forward-path = 275 mail-parameters = 276 rcpt-parameters = 277 4.1.2. Payload compression 279 BSMTP-like payload (Section 4.1.1) is first compressed using 280 zlibCompress [RFC1951] and the compressed payload is placed in the 281 compressedContent field of the CompressedContentInfo element defined 282 in Section 4.2.6 of [STANAG-4406]. This is then encoded as BER 283 encoding [ITU.X690.2002] of the CompressedData ASN.1 structure. For 284 convenience, the original definition of ASN.1 of the CompressedData 285 structure is included below. The contentType-ShortForm value used by 286 MULE is 25. 288 The above procedure is similar to how X.400 messages are sent using 289 Annex E of STANAG 4406 Ed 2. This makes it easier to implement MTAs 290 that support both Internet messages and X.400 messages in the same 291 code base. 293 The Compressed Data Type (CDT) consists of content of any type that 294 is compressed using a specified algorithm. The following object 295 identifier identifies the Compressed Data Type: 297 id-mmhs-CDT ID ::= { iso(1) identified-organization(3) nato(26) stanags(0) 298 mmhs(4406) object-identifiers(0) id-mcont(4) 2 } 300 The Compressed Data Type are defined by the following ASN.1 type: 302 DEFINITIONS ::= 303 BEGIN 304 CompressedData ::= SEQUENCE { 305 compressionAlgorithm CompressionAlgorithmIdentifier, 306 compressedContentInfo CompressedContentInfo 307 } 308 CompressionAlgorithmIdentifier ::= CHOICE { 309 algorithmID-ShortForm [0] AlgorithmID-ShortForm, 310 algorithmID-OID [1] OBJECT IDENTIFIER 311 } 312 AlgorithmID-ShortForm ::= INTEGER { zlibCompress (0) } 313 CompressedContentInfo ::= SEQUENCE { 314 CHOICE { 315 contentType-ShortForm [0] ContentType-ShortForm, 316 contentType-OID [1] OBJECT IDENTIFIER 317 }, 318 compressedContent [0] EXPLICIT OCTET STRING 319 } 320 ContentType-ShortForm ::= INTEGER { 321 unidentified (0), 322 external (1), -- identified by the object-identifier 323 -- of the EXTERNAL content 324 p1 (2), 325 p3 (3), 326 p7 (4) 327 } 328 END 330 4.2. Error handling 332 As MULE doesn't allow next hop MTA to return immediate Response Codes 333 for FROM-line or any of recipients in RCPT-line, MTAs that are 334 compliant with this specification that receive a message that can't 335 be delivered MUST generate a non delivery DSN report [RFC6522] 336 message which includes message/delivery-status body part [RFC3464] 337 and submit it using MULE to the FROM-line return-path address. 339 TBC: Also need to describe how to handle FROM-line or RCPT-line 340 parameters that we don't understand. Probably, they can be rejected 341 on receipt or be relayed to the final destination/gateway, which can 342 decide what to do with them. 344 4.3. Use of BDAT 346 If a message is received by a gateway, through SMTP transfers using 347 the CHUNKING [RFC3030] extension, the message is rebuilt by the 348 receiving MTA into its complete form and is then used as a single 349 MULE message payload. Use of BINARYMIME [RFC3030] extension is 350 conveyed in the FROM-line. 352 BURL [RFC4468] SMTP extension only applies to SMTP Submission, so it 353 is already mapped to BDAT/DATA by the time it reaches MULE. 355 5. Gatewaying from MULE to Internet Mail 357 Gatewaying from ACP 142 environment to Internet Email is the reverse 358 of the process specified in Section 4.1. 360 1. The ACP 142 message is reassembled from one or more DATA_PDUs. 362 2. If the contentType-ShortForm value is 25, the BSMTP-like payload 363 is extracted from compressedContent field and uncompressed as 364 specified in Section 4.1.2. If the contentType-ShortForm value 365 is not 25, it is handled as described in [ACP142A]. 367 3. The BSMTP-like payload is converted to SMTP transaction (see 368 Section 4.1.1). (The first line of the BSMTP-like payload is 369 prepended with "MAIL FROM:" and each following line (until the 370 empty line is encountered) is prepended with "RCPT TO:". After 371 skipping the empty delimiting line, the rest of the payload is 372 the message body. This can be either sent using DATA or a series 373 of BDAT commands, depending on capabilities of the receiving SMTP 374 system. For example, presence of BODY=BINARY in FROM-line would 375 necessitate use of BDAT or downconversion of the message to 7-bit 376 compatible representation.) 378 5.1. Error handling 380 ESMTP extension parameters to MAIL FROM and RCPT TO SMTP commands 381 obtained from BSMTP-like payload are processed according to 382 specifications of the corresponding ESMTP extensions. 384 Failures to extract or uncompress BSMTP-like payload are handled 385 according to ACP 142. 387 6. IANA Considerations 389 IANA is requested to create a new registry "Multicast Email SMTP 390 extensions". SMTP extensions registered in the "SMTP Service 391 Extensions" IANA registry can be registered in this new registry. 393 Registration procedure for the new registry is "Specification 394 Required" [RFC8126], but the registration reviewers will be appointed 395 and managed by the editors of this document together with the 396 Independent Submissions Editor. Registration requests should include 397 SMTP extension name, status (see Section 6.1) and specification 398 reference. 400 6.1. Mapping of existing SMTP extensions to MULE 402 The following table summarizes how different SMTP extensions can be 403 gatewayed to/from MULE. Each extension has one of the following 404 statuses: "required" (required to be supported on the SMTP side), 405 "disallowed" (incompatible with this protocol), "N/A" (not relevant, 406 because they affect commands other than MAIL FROM and RCPT TO. Can 407 be used on the SMTP side) or "supported". 409 +---------------------+-----------+---------------------------------+ 410 | SMTP Extension | Reference | Status | 411 | Keyword | | | 412 +---------------------+-----------+---------------------------------+ 413 | SIZE | [RFC1870] | Required | 414 | | | | 415 | 8BITMIME | [RFC6152] | Required | 416 | | | | 417 | DSN | [RFC3461] | Required | 418 | | | | 419 | MT-PRIORITY | [RFC6710] | Required | 420 | | | | 421 | DELIVERBY | [RFC2852] | Required | 422 | | | | 423 | BINARYMIME | [RFC3030] | Required | 424 | | | | 425 | PIPELINING | [RFC2920] | N/A | 426 | | | | 427 | CHUNKING | [RFC3030] | N/A | 428 | | | | 429 | BURL | [RFC4468] | N/A | 430 | | | | 431 | ENHANCEDSTATUSCODES | [RFC2034] | Supported (through DSN) | 432 | | | | 433 | CHECKPOINT | [RFC1845] | Disallowed | 434 | | | | 435 | RRVS | [RFC7293] | Supported | 436 | | | | 437 | NO-SOLICITING | [RFC3865] | N/A | 438 | | | | 439 | SUBMITTER | [RFC4405] | Supported | 440 | | | | 441 | CONNEG | [RFC4141] | Disallowed | 442 | | | | 443 | STARTTLS | [RFC3207] | N/A | 444 | | | | 445 | AUTH | [RFC4954] | N/A (MAIL FROM parameter is | 446 | | | supported) | 447 +---------------------+-----------+---------------------------------+ 449 7. Security Considerations 451 TBD. 453 8. References 455 8.1. Normative References 457 [ACP142A] "Common Messaging strategy and procedures", ACP 142(A), 458 August 2008. 460 [ITU.X690.2002] 461 International Telecommunications Union, "Information 462 Technology - ASN.1 encoding rules: Specification of Basic 463 Encoding Rules (BER), Canonical Encoding Rules (CER) and 464 Distinguished Encoding Rules (DER)", ITU-T Recommendation 465 X.690, July 2002. 467 [RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service 468 Extension for Message Size Declaration", STD 10, RFC 1870, 469 DOI 10.17487/RFC1870, November 1995, 470 . 472 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 473 version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, 474 . 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, 478 DOI 10.17487/RFC2119, March 1997, 479 . 481 [RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, 482 DOI 10.17487/RFC2852, June 2000, 483 . 485 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 486 of Large and Binary MIME Messages", RFC 3030, 487 DOI 10.17487/RFC3030, December 2000, 488 . 490 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 491 Extension for Delivery Status Notifications (DSNs)", 492 RFC 3461, DOI 10.17487/RFC3461, January 2003, 493 . 495 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 496 for Delivery Status Notifications", RFC 3464, 497 DOI 10.17487/RFC3464, January 2003, 498 . 500 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 501 Specifications: ABNF", STD 68, RFC 5234, 502 DOI 10.17487/RFC5234, January 2008, 503 . 505 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 506 DOI 10.17487/RFC5321, October 2008, 507 . 509 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 510 DOI 10.17487/RFC5322, October 2008, 511 . 513 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 514 DOI 10.17487/RFC5598, July 2009, 515 . 517 [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed., 518 "SMTP Service Extension for 8-bit MIME Transport", STD 71, 519 RFC 6152, DOI 10.17487/RFC6152, March 2011, 520 . 522 [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for 523 the Reporting of Mail System Administrative Messages", 524 STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, 525 . 527 [RFC6710] Melnikov, A. and K. Carlberg, "Simple Mail Transfer 528 Protocol Extension for Message Transfer Priorities", 529 RFC 6710, DOI 10.17487/RFC6710, August 2012, 530 . 532 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 533 Writing an IANA Considerations Section in RFCs", BCP 26, 534 RFC 8126, DOI 10.17487/RFC8126, June 2017, 535 . 537 [STANAG-4406] 538 "STANAG 4406 Edition 2: Military Message Handling System", 539 STANAG 4406 Ed. 2, March 2005. 541 8.2. Informative References 543 [RFC1845] Crocker, D., Freed, N., and A. Cargille, "SMTP Service 544 Extension for Checkpoint/Restart", RFC 1845, 545 DOI 10.17487/RFC1845, September 1995, 546 . 548 [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced 549 Error Codes", RFC 2034, DOI 10.17487/RFC2034, October 550 1996, . 552 [RFC2442] Freed, N., Newman, D., Belissent, J., and M. Hoy, "The 553 Batch SMTP Media Type", RFC 2442, DOI 10.17487/RFC2442, 554 November 1998, . 556 [RFC2920] Freed, N., "SMTP Service Extension for Command 557 Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920, 558 September 2000, . 560 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 561 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 562 February 2002, . 564 [RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer 565 Protocol (SMTP) Service Extension", RFC 3865, 566 DOI 10.17487/RFC3865, September 2004, 567 . 569 [RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for 570 Content Conversion", RFC 4141, DOI 10.17487/RFC4141, 571 November 2005, . 573 [RFC4405] Allman, E. and H. Katz, "SMTP Service Extension for 574 Indicating the Responsible Submitter of an E-Mail 575 Message", RFC 4405, DOI 10.17487/RFC4405, April 2006, 576 . 578 [RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468, 579 DOI 10.17487/RFC4468, May 2006, 580 . 582 [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service 583 Extension for Authentication", RFC 4954, 584 DOI 10.17487/RFC4954, July 2007, 585 . 587 [RFC7293] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid- 588 Since Header Field and SMTP Service Extension", RFC 7293, 589 DOI 10.17487/RFC7293, July 2014, 590 . 592 Appendix A. Acknowledgements 594 Thank you to Steve Kille for suggestions, comments and corrections on 595 this document. Additional thank you goes to Barry Leiba and Dave 596 Crocker for reviews and comments on this document. 598 Some text was borrowed from draft-riechmann-multicast-mail-00, thus 599 work of authors of that document is greatefully acknowledged. 601 Authors' Addresses 603 David Wilson 604 Isode Ltd 605 14 Castle Mews 606 Hampton, Middlesex TW12 2NP 607 UK 609 EMail: David.Wilson@isode.com 611 Alexey Melnikov (editor) 612 Isode Ltd 613 14 Castle Mews 614 Hampton, Middlesex TW12 2NP 615 UK 617 EMail: Alexey.Melnikov@isode.com