idnits 2.17.1 draft-melnikov-email-over-pmul-04.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 (March 4, 2018) is 2243 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 299 -- Looks like a reference, but probably isn't: '1' on line 297 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: September 5, 2018 March 4, 2018 7 Multicast Email (MULE) over ACP 142 8 draft-melnikov-email-over-pmul-04 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 describes how to gateway this basic protocol to/from Simple Mail 17 Transfer Protocol (RFC 5321), including some common SMTP extensions. 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 September 5, 2018. 36 Copyright Notice 38 Copyright (c) 2018 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 3.1. BSMTP-like Payload construction . . . . . . . . . . . . . 5 57 3.2. Payload compression . . . . . . . . . . . . . . . . . . . 6 58 4. Gatewaying from Internet Mail to MULE . . . . . . . . . . . . 7 59 4.1. Error handling . . . . . . . . . . . . . . . . . . . . . 8 60 4.2. Use of BDAT . . . . . . . . . . . . . . . . . . . . . . . 8 61 5. Gatewaying from MULE to Internet Mail . . . . . . . . . . . . 8 62 5.1. Handling of ESMTP extensions and Error handling . . . . . 9 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 6.1. SMTP Extension Support in MULE . . . . . . . . . . . . . 9 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 68 8.2. Informative References . . . . . . . . . . . . . . . . . 13 69 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 72 1. Introduction 74 P_MUL [ACP142A] is a transport protocol for reliable multicast in 75 bandwidth constrained and delayed acknowledgement environments 76 running on top of UDP. The objectives of this protocol are first to 77 take advantage of the bandwidth saving feature of using the multicast 78 service as supported by modern computer networks and second to allow 79 message transfer under EMCON conditions. EMCON (Emission Control) or 80 "Radio Silence" means that, although receiving nodes are able to 81 receive messages, they are not able to acknowledge the receipt of 82 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 normal - which 87 means dialogue oriented - communication condition and under EMCON 88 condition. EMCON condition means that a receiving node is able to 89 receive messages, but it cannot - for a relative long time (hours or 90 even days) - acknowledge the received messages. 92 This illustrates a simple multicast scenario, where the same message 93 has to be sent from MTA 1 to MTA 2 and to MTA 3. 95 +-------+ +-------+ 96 | MTA 1 |<-\ /->| MTA 3 | 97 +-------+ +-----+ +-------+ \ +-------+ / +-------+ 98 | MTA A |<--->| G/W |<---------------->| Router|< 99 +-------+ +-----+ +-------+ / +-------+ \ +-------+ 100 | MTA 2 |<-/ \->| MTA 4 | 101 +-------+ +-------+ 103 |< -------------- MULE ---------------->| 105 Typical MULE Deployment. The gateway (G/W) and Router might or might 106 not be running on the same system. 108 Figure 1 110 Using a multicast instead of an unicast communication service in the 111 above MTA configuration only one message transmission from MTA 1 to 112 the Router is required, instead of two as required with unicast. 113 This saves the transmision of one message and thus network bandwidth 114 utilisation. Depending on the network bandwidth (in some radio 115 networks less than 9.6 Kb/s) this saving can be of vital importance. 116 The saving in bandwidth utilisation becomes even greater with every 117 additional receiving MTA. 119 P_MUL employs a connectionless transport protocol to transmit 120 messages, that guarantees reliable message transfer, even in those 121 cases, when for a certain period of time one or more of the receiving 122 MTAs are not able or allowed to acknowledge completely received 123 messages. 125 This protocol specification requires fixed multicast groups and a 126 well known knowledge at each participating node(MTA) about the group 127 memberships to one or more multicast groups of each participating 128 node. 130 This document defines application protocol MULE (Multicast Email) for 131 transferring Internet Mail messages [RFC5322] over ACP 142 P_MUL. 133 2. Conventions Used in This Document 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 This document is also using terminology from [RFC5321] and [RFC5598]. 141 3. MULE 143 MULE is an electronic mail transport of Internet messages [RFC5322] 144 over ACP 142 P_MUL network. It provided service similar to SMTP 145 [RFC5321]. 147 An important feature of MULE is its capability to transport mail 148 across multiple networks, usually referred to as "MULE mail 149 relaying". A network consists of the mutually-ACP142-accessible 150 nodes. Using MULE, a process can transfer mail to another process on 151 the same ACP 142 network or to some other ACP 142 network via a relay 152 or gateway process accessible to both networks. 154 MULE reuses ESMTP extension framework [RFC5321]. MULE servers MUST 155 support the following ESMTP extensions: DSN [RFC3461], SIZE 156 [RFC1870], 8BITMIME [RFC6152], MT-PRIORITY [RFC6710], DELIVERBY 157 [RFC2852], BINARYMIME and CHUNKING [RFC3030]. (As the message 158 content size can always be determined from the compression wrapper 159 and the size of the envelope, no special handling is needed for 160 binary messages.) 162 Relaying a message using MULE is performed as follows: 164 1. The message is reassembled from one or more DATA_PDUs [ACP142A]. 166 2. If the contentType-ShortForm value is 25, the BSMTP-like payload 167 is extracted from compressedContent field and uncompressed as 168 specified in Section 3.2. If the contentType-ShortForm value is 169 not 25, it is handled as described in [ACP142A]. 171 3. The list of recipients is extracted from RCPT-lines (see 172 Section 3.1). The set of ACP 142 destinations for the message is 173 created by extracting right hand sides (hostnames) of each RCPT- 174 line, eliminating duplicates and then converting each hostname 175 into next ACP 142 destination using static configuration. 177 4. For each unique ACP 142 destination, the following steps are 178 performed: 180 A. A new BSMTP-like payload is formed, as described in 181 Section 3.1, which only contains RCPT-lines that correspond 182 to recipients that can receive mail through the ACP 142 183 destination. 185 B. The created payload is compressed and encoded as specified in 186 Section 3.2. 188 C. The compressed payload is sent by P_MUL as a series of 189 Address_PDU and one or more DATA_PDUs. When the message has 190 an associated MT-PRIORITY value [RFC6710], the 191 MappedPriority(value) is included as the Priority field of 192 corresponding ACP 142 PDUs, including Address_PDU, DATA_PDUs, 193 DISCARD_MESSAGE_PDU. Here MappedPriority(x) is defined as "6 194 - x". 196 3.1. BSMTP-like Payload construction 198 MULE uses BSMTP-like payload which differs from BSMTP [RFC2442]. As 199 with BSMTP, ESMTP capability negotiation is not used, since receiver 200 EMCON restrictions prohibit such real-time interaction. For that 201 reason, there is no point in including EHLO capabilities. "MAIL 202 FROM:" and "RCPT TO:" prefixes can also be eluded in order to save a 203 few bytes. 205 For each received message, the corresponding BSMTP-like payload is 206 constructed as follows (Lines are terminated using CR LF): 208 The first line is what would be used for the data following "MAIL 209 FROM:" in the SMTP dialogue. I.e. it contains the return-path 210 address, within <>'s followed by any ESMTP extension parameters to 211 the MAIL FROM command. 213 After that, there is a separate line for each recipient of the 214 message. The value is what would follow "RCPT TO:" in the SMTP 215 dialogue, i.e. the recipient address within <>'s followed by any 216 ESMTP extension parameters to the corresponding RCPT TO command. 218 The list of recipients is terminated by an empty line (i.e. just 219 CR LF) 221 The message content follows the empty line. There is no need for 222 transparency ("dot stuffing") or terminating CRLF.CRLF as the end 223 of the message content is indicated by the end of the data (See 224 Section 3.2 for more details). 226 Example of a BSMTP-like payload 228 MT-PRIORITY=4 BODY=8BITMIME RET=HDRS ENVID=QQ314159 229 NOTIFY=SUCCESS,FAILURE ORCPT=rfc822;Bob@enterprise.example.net 230 NOTIFY=SUCCESS,FAILURE 232 From: from@example.com 233 To: To1 , To2 234 Date: 27 Apr 2017 16:17 +0100 235 Subject: a test 236 MIME-Version: 1.0 237 Content-type: text/plain; charset=utf-8 238 Content-transfer-encoding: 8bit 240 This is worth 100 242 ABNF [RFC5234] for the BSMTP-like payload is: 244 bsmtp-like-payload = envelope CRLF payload 245 envelope = FROM-line 1*RCPT-line 246 FROM-line = reverse-path [SP mail-parameters] CRLF 247 RCPT-line = forward-path [SP rcpt-parameters] CRLF 249 payload = *OCTET 250 ; Conforms to message syntax as defined in RFC 5322 and extended in MIME 252 OCTET = 253 reverse-path = 254 forward-path = 255 mail-parameters = 256 rcpt-parameters = 258 3.2. Payload compression 260 BSMTP-like payload (Section 3.1) is first compressed using 261 zlibCompress [RFC1951] and the compressed payload is placed in the 262 compressedContent field of the CompressedContentInfo element defined 263 in Section 4.2.6 of [STANAG-4406]. This is then encoded as BER 264 encoding [ITU.X690.2002] of the CompressedData ASN.1 structure. For 265 convenience, the original definition of ASN.1 of the CompressedData 266 structure is included below. The contentType-ShortForm value used by 267 MULE is 25. 269 The above procedure is similar to how X.400 messages are sent using 270 Annex E of STANAG 4406 Ed 2. This makes it easier to implement MTAs 271 that support both Internet messages and X.400 messages in the same 272 code base. 274 The Compressed Data Type (CDT) consists of content of any type that 275 is compressed using a specified algorithm. The following object 276 identifier identifies the Compressed Data Type: 278 id-mmhs-CDT ID ::= { iso(1) identified-organization(3) nato(26) stanags(0) 279 mmhs(4406) object-identifiers(0) id-mcont(4) 2 } 281 The Compressed Data Type are defined by the following ASN.1 type: 283 DEFINITIONS ::= 284 BEGIN 285 CompressedData ::= SEQUENCE { 286 compressionAlgorithm CompressionAlgorithmIdentifier, 287 compressedContentInfo CompressedContentInfo 288 } 289 CompressionAlgorithmIdentifier ::= CHOICE { 290 algorithmID-ShortForm [0] AlgorithmID-ShortForm, 291 algorithmID-OID [1] OBJECT IDENTIFIER 292 } 293 AlgorithmID-ShortForm ::= INTEGER { zlibCompress (0) } 294 CompressedContentInfo ::= SEQUENCE { 295 CHOICE { 296 contentType-ShortForm [0] ContentType-ShortForm, 297 contentType-OID [1] OBJECT IDENTIFIER 298 }, 299 compressedContent [0] EXPLICIT OCTET STRING 300 } 301 ContentType-ShortForm ::= INTEGER { 302 unidentified (0), 303 external (1), -- identified by the object-identifier 304 -- of the EXTERNAL content 305 p1 (2), 306 p3 (3), 307 p7 (4) 308 } 309 END 311 4. Gatewaying from Internet Mail to MULE 313 A gateway from Internet Mail to MULE acts as SMTP server on the 314 receiving side and as MULE client on the sending side. 316 When the content type for a message is an Internet message content 317 type (which may be 7bit, 8bit or binary MIME), this is transported 318 using ACP 142 [ACP142A] as follows: 320 1. For each mail message a BSMTP-like payload is formed, as 321 described in Section 3.1. 323 2. The created payload is compressed and encoded as specified in 324 Section 3.2. 326 3. The compressed payload is sent by P_MUL as a series of 327 Address_PDU and one or more DATA_PDUs. When the message has an 328 associated MT-PRIORITY value [RFC6710], the MappedPriority(value) 329 is included as the Priority field of corresponding ACP 142 PDUs, 330 including Address_PDU, DATA_PDUs, DISCARD_MESSAGE_PDU. Here 331 MappedPriority(x) is defined as "6 - x". 333 The set of ACP 142 destinations for the message is derived from the 334 next hop MTAs for each of the recipients. 336 4.1. Error handling 338 As MULE doesn't allow next hop MTA to return immediate Response Codes 339 for FROM-line or any of recipients in RCPT-line, MTAs that are 340 compliant with this specification that receive a message that can't 341 be delivered MUST generate a non delivery DSN report [RFC6522] 342 message which includes message/delivery-status body part [RFC3464] 343 and submit it using MULE to the FROM-line return-path address. 345 TBC: Also need to describe how to handle FROM-line or RCPT-line 346 parameters that we don't understand. Probably, they can be rejected 347 on receipt or be relayed to the final destination/gateway, which can 348 decide what to do with them. 350 4.2. Use of BDAT 352 If a message is received by a gateway, through SMTP transfers using 353 the CHUNKING [RFC3030] extension, the message is rebuilt by the 354 receiving MTA into its complete form and is then used as a single 355 MULE message payload. Use of BINARYMIME [RFC3030] extension is 356 conveyed in the FROM-line. 358 5. Gatewaying from MULE to Internet Mail 360 A gateway from MULE to Internet Mail acts as a MULE server on the 361 receiving side and as an SMTP client on the sending side. 363 Gatewaying from ACP 142 environment to Internet Email is the reverse 364 of the process specified in Section 4. 366 1. The ACP 142 message is reassembled from one or more DATA_PDUs. 368 2. If the contentType-ShortForm value is 25, the BSMTP-like payload 369 is extracted from compressedContent field and uncompressed as 370 specified in Section 3.2. If the contentType-ShortForm value is 371 not 25, it is handled as described in [ACP142A]. 373 3. The BSMTP-like payload is converted to SMTP transaction (see 374 Section 3.1). (The first line of the BSMTP-like payload is 375 prepended with "MAIL FROM:" and each following line (until the 376 empty line is encountered) is prepended with "RCPT TO:". After 377 skipping the empty delimiting line, the rest of the payload is 378 the message body. This can be either sent using DATA or a series 379 of BDAT commands, depending on capabilities of the receiving SMTP 380 system. For example, presence of BODY=BINARY parameter in FROM- 381 line would necessitate use of BDAT or downconversion of the 382 message to 7-bit compatible representation.) 384 5.1. Handling of ESMTP extensions and Error handling 386 ESMTP extension parameters to MAIL FROM and RCPT TO SMTP commands 387 obtained from BSMTP-like payload are processed according to 388 specifications of the corresponding ESMTP extensions, including 389 dealing with absence of support for ESMTP extensions that correspond 390 to MAIL FROM/RCPT TO parameters found in the BSMTP-like payload. 392 Failures to extract or uncompress BSMTP-like payload are handled 393 according to ACP 142. 395 6. IANA Considerations 397 IANA is requested to create a new registry "Multicast Email SMTP 398 extensions". SMTP extensions registered in the "SMTP Service 399 Extensions" IANA registry can be registered in this new registry. 400 Registration procedure for the new registry is "Specification 401 Required" [RFC8126], but the registration reviewers will be appointed 402 and managed by the editors of this document together with the 403 Independent Submissions Editor. Registration requests should include 404 SMTP extension name, status (see Section 6.1) with an optional note 405 and specification reference. (At IANA's discretion the new registry 406 can instead be represented as an extra column in the existing "SMTP 407 Service Extensions" registry.) 409 6.1. SMTP Extension Support in MULE 411 The following table summarizes how different SMTP extensions can be 412 used with MULE. Each extension has one of the following statuses: 413 "Required" (required to be supported by MULE relays, SMTP-to-MULE 414 gateway or MULE-to-SMTP gateway), "Disallowed" (incompatible with 415 MULE), "N/A" (not relevant, because they affect commands other than 416 MAIL FROM and/or RCPT TO, or only defined for SMTP Submission. Such 417 extensions can still be used on the receiving SMTP side of SMTP-to- 418 MULE gateway) "Supported" (can be used with MULE, but requires 419 bilateral agreement between sender and receiver), or "Special". 420 "Special" needs to be accompanied by an explanation. 422 SMTP Extension Support in MULE: 424 +------------------------+-----------+---------------+ 425 | SMTP Extension Keyword | Reference | Status | 426 +------------------------+-----------+---------------+ 427 | SIZE | [RFC1870] | Required | 428 | | | | 429 | 8BITMIME | [RFC6152] | Required | 430 | | | | 431 | DSN | [RFC3461] | Required | 432 | | | | 433 | MT-PRIORITY | [RFC6710] | Required | 434 | | | | 435 | DELIVERBY | [RFC2852] | Required | 436 | | | | 437 | BINARYMIME | [RFC3030] | Required | 438 | | | | 439 | CHUNKING | [RFC3030] | Special (*) | 440 | | | | 441 | ENHANCEDSTATUSCODES | [RFC2034] | Special (**) | 442 | | | | 443 | RRVS | [RFC7293] | Supported | 444 | | | | 445 | SUBMITTER | [RFC4405] | Supported | 446 | | | | 447 | PIPELINING | [RFC2920] | N/A | 448 | | | | 449 | STARTTLS | [RFC3207] | N/A | 450 | | | | 451 | AUTH | [RFC4954] | Special (***) | 452 | | | | 453 | BURL | [RFC4468] | N/A | 454 | | | | 455 | NO-SOLICITING | [RFC3865] | N/A | 456 | | | | 457 | CHECKPOINT | [RFC1845] | Disallowed | 458 | | | | 459 | CONNEG | [RFC4141] | Disallowed | 460 +------------------------+-----------+---------------+ 462 (*) - SMTP CHUNKING MUST be supported on the receiving SMTP side of a 463 SMTP-to-MULE gateway and MAY be used on the sending side of MULE-to- 464 SMTP gateway. MULE relay doesn't need to do anything special for 465 this extension. 467 (**) - ENHANCEDSTATUSCODES extension is supported by including 468 relevant status codes in DSN [RFC3461] reports. 470 (***) - The AUTH parameter to MAIL FROM command is "supported", but 471 the rest of AUTH extension is not applicable to MULE. 473 Note that the above table is not exhaustive. Future RFCs can define 474 how SMTP Extensions not listed above can be used in MULE. 476 7. Security Considerations 478 TBD. 480 8. References 482 8.1. Normative References 484 [ACP142A] "Common Messaging strategy and procedures", ACP 142(A), 485 August 2008. 487 [ITU.X690.2002] 488 International Telecommunications Union, "Information 489 Technology - ASN.1 encoding rules: Specification of Basic 490 Encoding Rules (BER), Canonical Encoding Rules (CER) and 491 Distinguished Encoding Rules (DER)", ITU-T Recommendation 492 X.690, July 2002. 494 [RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service 495 Extension for Message Size Declaration", STD 10, RFC 1870, 496 DOI 10.17487/RFC1870, November 1995, 497 . 499 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 500 version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, 501 . 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, 505 DOI 10.17487/RFC2119, March 1997, 506 . 508 [RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, 509 DOI 10.17487/RFC2852, June 2000, 510 . 512 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 513 of Large and Binary MIME Messages", RFC 3030, 514 DOI 10.17487/RFC3030, December 2000, 515 . 517 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 518 Extension for Delivery Status Notifications (DSNs)", 519 RFC 3461, DOI 10.17487/RFC3461, January 2003, 520 . 522 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 523 for Delivery Status Notifications", RFC 3464, 524 DOI 10.17487/RFC3464, January 2003, 525 . 527 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 528 Specifications: ABNF", STD 68, RFC 5234, 529 DOI 10.17487/RFC5234, January 2008, 530 . 532 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 533 DOI 10.17487/RFC5321, October 2008, 534 . 536 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 537 DOI 10.17487/RFC5322, October 2008, 538 . 540 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 541 DOI 10.17487/RFC5598, July 2009, 542 . 544 [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed., 545 "SMTP Service Extension for 8-bit MIME Transport", STD 71, 546 RFC 6152, DOI 10.17487/RFC6152, March 2011, 547 . 549 [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for 550 the Reporting of Mail System Administrative Messages", 551 STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, 552 . 554 [RFC6710] Melnikov, A. and K. Carlberg, "Simple Mail Transfer 555 Protocol Extension for Message Transfer Priorities", 556 RFC 6710, DOI 10.17487/RFC6710, August 2012, 557 . 559 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 560 Writing an IANA Considerations Section in RFCs", BCP 26, 561 RFC 8126, DOI 10.17487/RFC8126, June 2017, 562 . 564 [STANAG-4406] 565 "STANAG 4406 Edition 2: Military Message Handling System", 566 STANAG 4406 Ed. 2, March 2005. 568 8.2. Informative References 570 [RFC1845] Crocker, D., Freed, N., and A. Cargille, "SMTP Service 571 Extension for Checkpoint/Restart", RFC 1845, 572 DOI 10.17487/RFC1845, September 1995, 573 . 575 [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced 576 Error Codes", RFC 2034, DOI 10.17487/RFC2034, October 577 1996, . 579 [RFC2442] Freed, N., Newman, D., Belissent, J., and M. Hoy, "The 580 Batch SMTP Media Type", RFC 2442, DOI 10.17487/RFC2442, 581 November 1998, . 583 [RFC2920] Freed, N., "SMTP Service Extension for Command 584 Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920, 585 September 2000, . 587 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 588 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 589 February 2002, . 591 [RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer 592 Protocol (SMTP) Service Extension", RFC 3865, 593 DOI 10.17487/RFC3865, September 2004, 594 . 596 [RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for 597 Content Conversion", RFC 4141, DOI 10.17487/RFC4141, 598 November 2005, . 600 [RFC4405] Allman, E. and H. Katz, "SMTP Service Extension for 601 Indicating the Responsible Submitter of an E-Mail 602 Message", RFC 4405, DOI 10.17487/RFC4405, April 2006, 603 . 605 [RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468, 606 DOI 10.17487/RFC4468, May 2006, 607 . 609 [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service 610 Extension for Authentication", RFC 4954, 611 DOI 10.17487/RFC4954, July 2007, 612 . 614 [RFC7293] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid- 615 Since Header Field and SMTP Service Extension", RFC 7293, 616 DOI 10.17487/RFC7293, July 2014, 617 . 619 Appendix A. Acknowledgements 621 Thank you to Steve Kille for suggestions, comments and corrections on 622 this document. Additional thank you goes to Barry Leiba and Dave 623 Crocker for reviews and comments on this document. 625 Some text was borrowed from draft-riechmann-multicast-mail-00, thus 626 work of authors of that document is greatefully acknowledged. 628 Authors' Addresses 630 David Wilson 631 Isode Ltd 632 14 Castle Mews 633 Hampton, Middlesex TW12 2NP 634 UK 636 EMail: David.Wilson@isode.com 638 Alexey Melnikov (editor) 639 Isode Ltd 640 14 Castle Mews 641 Hampton, Middlesex TW12 2NP 642 UK 644 EMail: Alexey.Melnikov@isode.com