idnits 2.17.1 draft-melnikov-email-over-pmul-08.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 7 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 (September 1, 2018) is 2064 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 330 -- Looks like a reference, but probably isn't: '1' on line 328 ** Obsolete normative reference: RFC 7601 (Obsoleted by RFC 8601) -- Obsolete informational reference (is this intentional?): RFC 5750 (Obsoleted by RFC 8550) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 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: March 5, 2019 September 1, 2018 7 Multicast Email (MULE) over Allied Communications Publication (ACP) 142 8 draft-melnikov-email-over-pmul-08 10 Abstract 12 Allied Communications Publication (ACP) 142 defines P_MUL, which is a 13 protocol for reliable multicast suitable for bandwidth constrained 14 and delayed acknowledgement (Emissions Control or "EMCON") 15 environments running over UDP. This document defines an application 16 protocol called MULE (Multicast Email) for transferring of Internet 17 Mail messages (as described in RFC 5322) over P_MUL (as defined in 18 ACP 142A). MULE enables Message Transfer Agent (MTA) to MTA transfer 19 and doesn't provide a service similar to SMTP Submission (as 20 described in RFC 6409). 22 This document explains how MULE can be used in conjunction with 23 Simple Mail Transfer Protocol (SMTP, RFC 5321), including some common 24 SMTP extensions, to provide an alternate MTA to MTA transfer 25 mechanism. 27 This is not an IETF specification, but describes an existing 28 implementation. It is provided in order to facilitate interoperable 29 implementations and third-party diagnostics. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 5, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 67 3. MULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. BSMTP-like Payload construction . . . . . . . . . . . . . 5 69 3.2. Payload compression . . . . . . . . . . . . . . . . . . . 7 70 3.3. Error handling . . . . . . . . . . . . . . . . . . . . . 9 71 4. Gatewaying from Internet Mail to MULE . . . . . . . . . . . . 9 72 4.1. Use of BDAT . . . . . . . . . . . . . . . . . . . . . . . 9 73 5. Gatewaying from MULE to Internet Mail . . . . . . . . . . . . 10 74 5.1. Handling of ESMTP extensions and Error handling . . . . . 10 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 6.1. SMTP Extension Support in MULE . . . . . . . . . . . . . 11 77 6.2. SMTP Extension Support in MULE . . . . . . . . . . . . . 11 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 81 8.2. Informative References . . . . . . . . . . . . . . . . . 16 82 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 P_MUL [ACP142A] is a transport protocol for reliable multicast in 88 bandwidth constrained and delayed acknowledgement environments 89 running on top of UDP. This document defines an application protocol 90 called MULE for transferring Internet Mail messages [RFC5322] over 91 ACP 142 P_MUL. The objectives of MULE are first to take advantage of 92 the bandwidth saving feature of using the multicast service as 93 supported by modern computer networks and second to allow message 94 transfer under EMCON (Emission Control) conditions. EMCON or "Radio 95 Silence" means that although receiving nodes are able to receive 96 messages, they are not able to acknowledge the receipt of messages. 98 The objective of this protocol is to take advantage of multicast 99 communication for the transfer of messages between MTAs (Message 100 Transfer Agents) on a single multicast network under normal - which 101 means dialogue oriented - communication condition and under EMCON 102 condition. EMCON condition means that a receiving node is able to 103 receive messages, but it cannot - for a relatively long time (hours 104 or even days) - acknowledge the received messages. 106 This illustrates a simple multicast scenario, where the same message 107 has to be sent from MTA A (through G/W) to MTA 1, MTA 2, MTA 3 and 108 MTA 4. 110 +-------+ +-------+ 111 | MTA 1 |<-\ /->| MTA 3 | 112 +-------+ +-----+ +-------+ \ +-------+ / +-------+ 113 | MTA A |<--->| G/W |<---------------->| Router|< 114 +-------+ +-----+ +-------+ / +-------+ \ +-------+ 115 | MTA 2 |<-/ \->| MTA 4 | 116 +-------+ +-------+ 118 |< -------------- MULE ---------------->| 120 Typical MULE Deployment. The gateway (G/W) and Router might or might 121 not be running on the same system. 123 Figure 1 125 Due to multicast use (instead of a unicast communication service) in 126 the above MTA configuration only one message transmission from the 127 gateway to the Router is required in order to reach MTA 1, MTA 2, MTA 128 3 and MTA 4, instead of 4 as required with unicast. This saves the 129 transmision of 3 message transactions and thus network bandwidth 130 utilisation. Depending on the network bandwidth (in some radio 131 networks less than 9.6 Kb/s) this saving can be of vital importance. 132 The saving in bandwidth utilisation becomes even greater with every 133 additional receiving MTA. 135 P_MUL employs a connectionless transport protocol to transmit 136 messages: this guarantees reliable message transfer (through ACP 142 137 retransmissions), even in those cases, when for a certain period of 138 time, one or more of the receiving MTAs are not able or allowed to 139 acknowledge completely received messages. 141 This protocol specification requires fixed multicast groups and a 142 well known knowledge at each participating node (MTA) about the group 143 memberships in one or more multicast groups of each participating 144 node. Membership in multicast groups needs to be established before 145 MULE messages can be sent. 147 MULE enables Message Transfer Agents (MTA) to MTA transfer and 148 doesn't provide service similar to SMTP Submission. 150 2. Conventions Used in This Document 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in BCP 155 14 [RFC2119] [RFC8174] when, and only when, they appear in all 156 capitals, as shown here. 158 This document also uses terminology from [RFC5321] and [RFC5598]. 160 3. MULE 162 MULE is an electronic mail transport of Internet messages [RFC5322] 163 over ACP 142 P_MUL network. It provides service similar to MTA-to- 164 MTA SMTP [RFC5321]. This document doesn't define a service similar 165 to Message Submission ([RFC6409]). 167 An important feature of MULE is its capability to transport mail 168 across multiple networks, referred to as "MULE mail relaying". A 169 network consists of the mutually-ACP142-accessible nodes. Using 170 MULE, a process can transfer mail to another process on the same ACP 171 142 network or to some other ACP 142 network via a relay or gateway 172 process accessible to both networks. 174 MULE reuses ESMTP extension framework defined in [RFC5321]. MULE 175 servers MUST support the following ESMTP extensions: DSN [RFC3461], 176 SIZE [RFC1870], 8BITMIME [RFC6152], MT-PRIORITY [RFC6710], DELIVERBY 177 [RFC2852], BINARYMIME and CHUNKING [RFC3030]. (As the message 178 content size can always be determined from the compression wrapper 179 and the size of the envelope, no special handling is needed for 180 binary messages.) 182 Relaying a message using MULE is performed as follows: 184 1. The message is reassembled from one or more DATA_PDUs [ACP142A]. 186 2. If the contentType-ShortForm value is 25, the BSMTP-like payload 187 is extracted from compressedContent field and uncompressed as 188 specified in Section 3.2. If the contentType-ShortForm value is 189 not 25, it is handled as described in [ACP142A]. This document 190 doesn't discuss further any cases where contentType-ShortForm 191 value is not 25. 193 3. The list of recipients is extracted from RCPT-lines (see 194 Section 3.1). If the receiving node is not responsible (directly 195 or inderectly) for any of the recipients, the message is 196 discarded and no further processing is done. 198 4. The relay adds trace header fields, for example the Received 199 header field. See Section 4.4. of [RFC5321] and [RFC7601]. 201 5. The set of ACP 142 destinations for the message is created by 202 extracting right hand sides (hostnames) of each RCPT-line, 203 eliminating duplicates and then converting each hostname into 204 next ACP 142 destination using static configuration. 206 6. For each unique ACP 142 destination, the following steps are 207 performed: 209 A. A new BSMTP-like payload is formed, as described in 210 Section 3.1, which only contains RCPT-lines that correspond 211 to recipients that can receive mail through the ACP 142 212 destination. 214 B. The created payload is compressed and encoded as specified in 215 Section 3.2. 217 C. The compressed payload is sent by P_MUL as a series of 218 Address_PDU and one or more DATA_PDUs. When the message has 219 an associated MT-PRIORITY value [RFC6710], the 220 MappedPriority(value) is included as the Priority field of 221 corresponding ACP 142 PDUs, including Address_PDU, DATA_PDUs, 222 DISCARD_MESSAGE_PDU. Here MappedPriority(x) is defined as "6 223 - x". 225 3.1. BSMTP-like Payload construction 227 MULE uses BSMTP-like payload which differs from Batch SMTP (BSMTP, 228 [RFC2442]) in that it eliminates unnecessary information. As with 229 BSMTP, ESMTP capability negotiation is not used, since receiver EMCON 230 restrictions prohibit such real-time interaction. For that reason, 231 there is no point in including EHLO capabilities. "MAIL FROM:" and 232 "RCPT TO:" prefixes are also eluded in order to save a few bytes. 234 For each received message, the corresponding BSMTP-like payload is 235 constructed as follows (Lines are terminated using CR LF).: 237 The first line is what would be used for the data following "MAIL 238 FROM:" in the SMTP dialogue. I.e. it contains the return-path 239 address, within <>'s followed by any ESMTP extension parameters to 240 the MAIL FROM command. 242 After that, there is a separate line for each recipient of the 243 message. The value is what would follow "RCPT TO:" in the SMTP 244 dialogue, i.e. the recipient address within <>'s followed by any 245 ESMTP extension parameters to the corresponding RCPT TO command. 247 The list of recipients is terminated by an empty line (i.e. just 248 CR LF) 250 The message content follows the empty line. There is no need for 251 transparency ("dot stuffing") or terminating with a sequence "CR 252 LF . CR LF", as the end of the message content is indicated by the 253 end of the data (See Section 3.2 for more details). 255 An example of BSMTP-like payload follows 257 MT-PRIORITY=4 BODY=8BITMIME RET=HDRS ENVID=QQ314159 258 NOTIFY=SUCCESS,FAILURE ORCPT=rfc822;Bob@enterprise.example.net 259 NOTIFY=SUCCESS,FAILURE 261 From: from@example.com 262 To: To1 , To2 263 Date: 27 Apr 2017 16:17 +0100 264 Subject: a test 265 MIME-Version: 1.0 266 Content-type: text/plain; charset=utf-8 267 Content-transfer-encoding: 8bit 269 This is worth 100 270 ABNF [RFC5234] for the BSMTP-like payload is: 272 bsmtp-like-payload = envelope CRLF payload 273 envelope = FROM-line 1*RCPT-line 274 FROM-line = reverse-path [SP mail-parameters] CRLF 275 RCPT-line = forward-path [SP rcpt-parameters] CRLF 277 payload = *OCTET 278 ; Conforms to message syntax as defined in RFC 5322 and extended in MIME 280 OCTET = 281 reverse-path = 282 forward-path = 283 mail-parameters = 284 rcpt-parameters = 286 3.2. Payload compression 288 A BSMTP-like payload (Section 3.1) is first compressed using 289 zlibCompress [RFC1950] and the compressed payload is placed in the 290 compressedContent field of the CompressedContentInfo element defined 291 in Section 4.2.6 of [STANAG-4406]. This is then encoded as BER 292 encoding [ITU.X690.2002] of the CompressedData ASN.1 structure. For 293 convenience, the original definition of ASN.1 of the CompressedData 294 structure is included below. The contentType-ShortForm value used by 295 MULE MUST be 25. (The contentType-OID alternative is never used by 296 MULE.) 298 The above procedure is similar to how X.400 messages are sent using 299 Annex E of STANAG 4406 Ed 2. This makes it easier to implement MTAs 300 that support both Internet messages and X.400 messages in the same 301 code base. 303 The Compressed Data Type (CDT) consists of content of any type that 304 is compressed using a specified algorithm. The following object 305 identifier identifies the Compressed Data Type: 307 id-mmhs-CDT ID ::= { iso(1) identified-organization(3) nato(26) stanags(0) 308 mmhs(4406) object-identifiers(0) id-mcont(4) 2 } 310 The Compressed Data Type is defined by the following ASN.1 type (Note 311 that this definition is copied from [STANAG-4406] and only reproduced 312 here for reader's convenience): 314 DEFINITIONS ::= 315 BEGIN 316 CompressedData ::= SEQUENCE { 317 compressionAlgorithm CompressionAlgorithmIdentifier, 318 compressedContentInfo CompressedContentInfo 319 } 320 CompressionAlgorithmIdentifier ::= CHOICE { 321 algorithmID-ShortForm [0] AlgorithmID-ShortForm, 322 algorithmID-OID [1] OBJECT IDENTIFIER 323 } 324 AlgorithmID-ShortForm ::= INTEGER { zlibCompress (0) } 325 CompressedContentInfo ::= SEQUENCE { 326 CHOICE { 327 contentType-ShortForm [0] ContentType-ShortForm, 328 contentType-OID [1] OBJECT IDENTIFIER 329 }, 330 compressedContent [0] EXPLICIT OCTET STRING 331 } 332 ContentType-ShortForm ::= INTEGER { 333 unidentified (0), 334 external (1), -- identified by the object-identifier 335 -- of the EXTERNAL content 336 p1 (2), 337 p3 (3), 338 p7 (4) 339 } 340 END 342 This document effectively adds another enumeration choice to the 343 ContentType-ShortForm definition. The updated definition looks like 344 this: 346 ContentType-ShortForm ::= INTEGER { 347 unidentified (0), 348 external (1), -- identified by the object-identifier 349 -- of the EXTERNAL content 350 p1 (2), 351 p3 (3), 352 p7 (4), 353 mule (25) 354 } 356 3.3. Error handling 358 As MULE doesn't allow next hop MTA/MDA to return immediate Response 359 Codes for FROM-line or any of the recipients in RCPT-line, MTAs/MDAs 360 that are compliant with this specification that receive a message 361 that can't be relayed further or delivered MUST generate a non 362 delivery DSN report [RFC6522] message which includes message/ 363 delivery-status body part [RFC3464] and submit it using MULE to the 364 FROM-line return-path address. 366 MULE relays (unlike MULE MDAs) don't need to verify that they 367 understand all FROM-line and/or RCPT-line parameters. This keeps 368 relay-only implementations simpler and avoids the need to upgrade 369 them when MULE MDAs are updated to support extra SMTP extensions. 371 4. Gatewaying from Internet Mail to MULE 373 A gateway from Internet Mail to MULE acts as an SMTP server on the 374 receiving side and as a MULE client on the sending side. 376 When the content type for a message is an Internet message content 377 type (which may be 7bit, 8bit or binary MIME), this is transported 378 using ACP 142 [ACP142A] as follows: 380 1. For each mail message a BSMTP-like payload is formed, as 381 described in Section 3.1. 383 2. The created payload is compressed and encoded as specified in 384 Section 3.2. 386 3. The compressed payload is sent by P_MUL as a series of 387 Address_PDU and one or more DATA_PDUs. When the message has an 388 associated MT-PRIORITY value [RFC6710], the MappedPriority(value) 389 is included as the Priority field of corresponding ACP 142 PDUs, 390 including Address_PDU, DATA_PDUs, DISCARD_MESSAGE_PDU. Here 391 MappedPriority(x) is defined as "6 - x". 393 The set of ACP 142 destinations for the message is derived from the 394 next hop MTAs for each of the recipients. 396 4.1. Use of BDAT 398 If a message is received by a gateway, through SMTP transfers using 399 the CHUNKING [RFC3030] extension, the message is rebuilt by the 400 receiving MTA into its complete form and is then used as a single 401 MULE message payload. Use of BINARYMIME [RFC3030] extension is 402 conveyed by inclusion of BODY=BINARY parameter in the FROM-line. 404 5. Gatewaying from MULE to Internet Mail 406 A gateway from MULE to Internet Mail acts as a MULE server on the 407 receiving side and as an SMTP client on the sending side. 409 Gatewaying from ACP 142 environment to Internet Email is the reverse 410 of the process specified in Section 4. 412 1. The ACP 142 message is reassembled from one or more DATA_PDUs. 414 2. If the contentType-ShortForm value is 25, the BSMTP-like payload 415 is extracted from compressedContent field and uncompressed as 416 specified in Section 3.2. If the contentType-ShortForm value is 417 not 25, it is handled as described in [ACP142A]. 419 3. The BSMTP-like payload is converted to an SMTP transaction (see 420 Section 3.1). (The first line of the BSMTP-like payload is 421 prepended with "MAIL FROM:" and each following line (until the 422 empty line is encountered) is prepended with "RCPT TO:". After 423 skipping the empty delimiting line, the rest of the payload is 424 the message body. This can be either sent using DATA or a series 425 of BDAT commands, depending on capabilities of the receiving SMTP 426 system. For example, the presence of BODY=BINARY parameter in 427 FROM-line would necessitate use of BDAT or downconversion of the 428 message to 7-bit compatible representation.) 430 5.1. Handling of ESMTP extensions and Error handling 432 ESMTP extension parameters to MAIL FROM and RCPT TO SMTP commands 433 obtained from BSMTP-like payload are processed according to 434 specifications of the corresponding ESMTP extensions, including 435 dealing with absence of support for ESMTP extensions that correspond 436 to MAIL FROM/RCPT TO parameters found in the BSMTP-like payload. 438 Failures to extract or uncompress BSMTP-like payload should result in 439 the receiver discarding such payloads. 441 6. IANA Considerations 443 IANA is requested to create a new registry "Multicast Email SMTP 444 extensions". Registration procedure for the new registry is 445 "Specification Required" [RFC8126], but the Designated Expert(s) will 446 be appointed and managed by the editors of this document together 447 with the Independent Submissions Editor. Selected Designated 448 Expert(s) should (collectively) have good knowledge of SMTP protocol 449 (and its extensions/extensibility mechanisms), and ACP 142 and its 450 limitations. Subsections of this section provide more details. In 451 particular, Section 6.1 specifies instructions for the Designated 452 Expert(s) and Section 6.2 defines the initial content of the 453 registry. 455 6.1. SMTP Extension Support in MULE 457 The Designated Expert for the new "Multicast Email SMTP extensions" 458 registry verifies that 460 1. the requested SMTP extension is already registered in the "SMTP 461 Service Extensions" registry in the "Mail Parameters" section of 462 the IANA Website or is well documented on a stable, publicly 463 accessible web page. 465 2. the requested SMTP extension has the correct status as specified 466 in Section 6.2. When deciding on status, the Designated 467 Expert(s) is provided with the following guidelines: 469 1. If the SMTP extension only affects commands other than MAIL 470 FROM/RCPT TO, then the status should be "N/A". 472 2. If the SMTP extension only applies to SMTP submission (and 473 not to SMTP relay or final SMTP delivery), then the status 474 should be "N/A". 476 3. If the SMTP extension changes which commands are allowed 477 during an SMTP transaction (e.g. if it adds commands 478 alternative to DATA or declares commands other than MAIL 479 FROM/RCPT TO/DATA/BDAT to be a part of SMTP transaction), 480 then the status should be "Disallowed" or "Special". 482 4. If the SMTP extension adds extra round trips during SMTP 483 transaction, then the status should be "Disallowed" or 484 "Special". 486 Registration requests should include SMTP extension name, status (see 487 Section 6.2), specification reference and may include an optional 488 note. 490 6.2. SMTP Extension Support in MULE 492 The following table summarizes how different SMTP extensions can be 493 used with MULE. Each extension has one of the following statuses: 494 "Required" (required to be supported by MULE relays, SMTP-to-MULE 495 gateway or MULE-to-SMTP gateway), "Disallowed" (incompatible with 496 MULE), "N/A" (not relevant, because they affect commands other than 497 MAIL FROM and/or RCPT TO, or only defined for SMTP Submission. Such 498 extensions can still be used on the receiving SMTP side of SMTP-to- 499 MULE gateway) "Supported" (can be used with MULE, but requires 500 bilateral agreement between sender and receiver), or "Special". 501 "Special" needs to be accompanied by an explanation. 503 SMTP Extension Support in MULE: 505 +------------------------+-----------+---------------+ 506 | SMTP Extension Keyword | Reference | Status | 507 +------------------------+-----------+---------------+ 508 | SIZE | [RFC1870] | Required | 509 | | | | 510 | 8BITMIME | [RFC6152] | Required | 511 | | | | 512 | DSN | [RFC3461] | Required | 513 | | | | 514 | MT-PRIORITY | [RFC6710] | Required | 515 | | | | 516 | DELIVERBY | [RFC2852] | Required | 517 | | | | 518 | BINARYMIME | [RFC3030] | Required | 519 | | | | 520 | CHUNKING | [RFC3030] | Special (*) | 521 | | | | 522 | ENHANCEDSTATUSCODES | [RFC2034] | Special (**) | 523 | | | | 524 | RRVS | [RFC7293] | Supported | 525 | | | | 526 | SUBMITTER | [RFC4405] | Supported | 527 | | | | 528 | PIPELINING | [RFC2920] | N/A | 529 | | | | 530 | STARTTLS | [RFC3207] | N/A | 531 | | | | 532 | AUTH | [RFC4954] | Special (***) | 533 | | | | 534 | BURL | [RFC4468] | N/A | 535 | | | | 536 | NO-SOLICITING | [RFC3865] | N/A | 537 | | | | 538 | CHECKPOINT | [RFC1845] | Disallowed | 539 | | | | 540 | CONNEG | [RFC4141] | Disallowed | 541 +------------------------+-----------+---------------+ 543 (*) - SMTP CHUNKING MUST be supported on the receiving SMTP side of a 544 SMTP-to-MULE gateway and MAY be used on the sending side of MULE-to- 545 SMTP gateway. A MULE relay doesn't need to do anything special for 546 this extension. 548 (**) - ENHANCEDSTATUSCODES extension is supported by including 549 relevant status codes in DSN [RFC3461] reports. 551 (***) - The AUTH parameter to MAIL FROM command is "supported", but 552 the rest of AUTH extension is not applicable to MULE. 554 Note that the above table is not exhaustive. Future RFCs can define 555 how SMTP Extensions not listed above can be used in MULE. 557 7. Security Considerations 559 As MULE provides a service similar to SMTP, many of Security 560 Considerations from [RFC5321] apply to MULE as well, in particular 561 Sections 7.1, 7.2, 7.4, 7.6, 7.7, 7.9 of [RFC5321] still apply to 562 MULE. 564 As MULE doesn't support capability negotiation or SMTP HELP command, 565 Section 7.5 of [RFC5321] ("Information Disclosure in Announcements") 566 doesn't apply to MULE. 568 As MULE doesn't support VRFY or EXPN SMTP commands, Section 7.3 of 569 [RFC5321] ("VRFY, EXPN, and Security") that talks about email 570 harvesting doesn't apply to MULE. 572 Arguably, it is more difficult to cause an application layer Denial- 573 of-Service attack on a MULE server than on an SMTP server. This is 574 partially due to fact that ACP 142 is used in radio/wireless networks 575 with relatively low bandwidth and very long round trip time 576 (especially if EMCON is in force). However, as MULE is using 577 multicast, multiple MULE nodes can receive the same message and spend 578 CPU processing it, even if the message is addressed to recipients 579 that are not going to be handled by such nodes. As MULE lacks 580 transport layer source authentication, this can be abused by 581 malicious senders. 583 For Security Considerations related to use of zlib compression see 584 [RFC6713]. 586 Due to the multicast nature of MULE, it cannot use TLS or DTLS. 587 Accordingly, it does not support STARTTLS [RFC3207]. Users should 588 not depend on hop-by-hop confidentiality or integrity protection of 589 mail transfered among MULE MTAs (in the same way they can't generally 590 rely on use of STARTTLS on SMTP MTA-to-MTA links), and should 591 consider the use of end-to-end protection, such as S/MIME [RFC5750] 592 [RFC5751]. 594 8. References 596 8.1. Normative References 598 [ACP142A] "Common Messaging strategy and procedures", ACP 142(A), 599 August 2008. 601 [ITU.X690.2002] 602 International Telecommunications Union, "Information 603 Technology - ASN.1 encoding rules: Specification of Basic 604 Encoding Rules (BER), Canonical Encoding Rules (CER) and 605 Distinguished Encoding Rules (DER)", ITU-T Recommendation 606 X.690, July 2002. 608 [RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service 609 Extension for Message Size Declaration", STD 10, RFC 1870, 610 DOI 10.17487/RFC1870, November 1995, 611 . 613 [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format 614 Specification version 3.3", RFC 1950, 615 DOI 10.17487/RFC1950, May 1996, 616 . 618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels", BCP 14, RFC 2119, 620 DOI 10.17487/RFC2119, March 1997, 621 . 623 [RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, 624 DOI 10.17487/RFC2852, June 2000, 625 . 627 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 628 of Large and Binary MIME Messages", RFC 3030, 629 DOI 10.17487/RFC3030, December 2000, 630 . 632 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 633 Extension for Delivery Status Notifications (DSNs)", 634 RFC 3461, DOI 10.17487/RFC3461, January 2003, 635 . 637 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 638 for Delivery Status Notifications", RFC 3464, 639 DOI 10.17487/RFC3464, January 2003, 640 . 642 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 643 Specifications: ABNF", STD 68, RFC 5234, 644 DOI 10.17487/RFC5234, January 2008, 645 . 647 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 648 DOI 10.17487/RFC5321, October 2008, 649 . 651 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 652 DOI 10.17487/RFC5322, October 2008, 653 . 655 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 656 DOI 10.17487/RFC5598, July 2009, 657 . 659 [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed., 660 "SMTP Service Extension for 8-bit MIME Transport", STD 71, 661 RFC 6152, DOI 10.17487/RFC6152, March 2011, 662 . 664 [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for 665 the Reporting of Mail System Administrative Messages", 666 STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, 667 . 669 [RFC6710] Melnikov, A. and K. Carlberg, "Simple Mail Transfer 670 Protocol Extension for Message Transfer Priorities", 671 RFC 6710, DOI 10.17487/RFC6710, August 2012, 672 . 674 [RFC6713] Levine, J., "The 'application/zlib' and 'application/gzip' 675 Media Types", RFC 6713, DOI 10.17487/RFC6713, August 2012, 676 . 678 [RFC7601] Kucherawy, M., "Message Header Field for Indicating 679 Message Authentication Status", RFC 7601, 680 DOI 10.17487/RFC7601, August 2015, 681 . 683 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 684 Writing an IANA Considerations Section in RFCs", BCP 26, 685 RFC 8126, DOI 10.17487/RFC8126, June 2017, 686 . 688 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 689 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 690 May 2017, . 692 [STANAG-4406] 693 "STANAG 4406 Edition 2: Military Message Handling System", 694 STANAG 4406 Ed. 2, March 2005. 696 8.2. Informative References 698 [RFC1845] Crocker, D., Freed, N., and A. Cargille, "SMTP Service 699 Extension for Checkpoint/Restart", RFC 1845, 700 DOI 10.17487/RFC1845, September 1995, 701 . 703 [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced 704 Error Codes", RFC 2034, DOI 10.17487/RFC2034, October 705 1996, . 707 [RFC2442] Freed, N., Newman, D., Belissent, J., and M. Hoy, "The 708 Batch SMTP Media Type", RFC 2442, DOI 10.17487/RFC2442, 709 November 1998, . 711 [RFC2920] Freed, N., "SMTP Service Extension for Command 712 Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920, 713 September 2000, . 715 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 716 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 717 February 2002, . 719 [RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer 720 Protocol (SMTP) Service Extension", RFC 3865, 721 DOI 10.17487/RFC3865, September 2004, 722 . 724 [RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for 725 Content Conversion", RFC 4141, DOI 10.17487/RFC4141, 726 November 2005, . 728 [RFC4405] Allman, E. and H. Katz, "SMTP Service Extension for 729 Indicating the Responsible Submitter of an E-Mail 730 Message", RFC 4405, DOI 10.17487/RFC4405, April 2006, 731 . 733 [RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468, 734 DOI 10.17487/RFC4468, May 2006, 735 . 737 [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service 738 Extension for Authentication", RFC 4954, 739 DOI 10.17487/RFC4954, July 2007, 740 . 742 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 743 Mail Extensions (S/MIME) Version 3.2 Certificate 744 Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, 745 . 747 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 748 Mail Extensions (S/MIME) Version 3.2 Message 749 Specification", RFC 5751, DOI 10.17487/RFC5751, January 750 2010, . 752 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 753 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 754 . 756 [RFC7293] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid- 757 Since Header Field and SMTP Service Extension", RFC 7293, 758 DOI 10.17487/RFC7293, July 2014, 759 . 761 Appendix A. Acknowledgements 763 Thank you to Steve Kille for suggestions, comments and corrections on 764 this document. Additional thank you goes to Barry Leiba, Sean 765 Turner, Dave Crocker and Nick Hudson for reviews and comments on this 766 document. 768 Some text was borrowed from draft-riechmann-multicast-mail-00, thus 769 work of authors of that document is greatefully acknowledged. 771 Authors' Addresses 773 David Wilson 774 Isode Ltd 775 14 Castle Mews 776 Hampton, Middlesex TW12 2NP 777 UK 779 EMail: David.Wilson@isode.com 781 Alexey Melnikov (editor) 782 Isode Ltd 783 14 Castle Mews 784 Hampton, Middlesex TW12 2NP 785 UK 787 EMail: Alexey.Melnikov@isode.com