idnits 2.17.1 draft-melnikov-email-over-pmul-06.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 (July 16, 2018) is 2112 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) Summary: 2 errors (**), 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: January 17, 2019 July 16, 2018 7 Multicast Email (MULE) over Allied Communications Publication (ACP) 142 8 draft-melnikov-email-over-pmul-06 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 Agents (MTA) to MTA 19 transfer and doesn't provide 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 January 17, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 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 of 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, that 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 is also using 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 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 recipients in RCPT-line, MTAs/MDAs that 360 are compliant with this specification that receive a message that 361 can't be relayed further or delivered MUST generate a non delivery 362 DSN report [RFC6522] message which includes message/delivery-status 363 body part [RFC3464] and submit it using MULE to the FROM-line return- 364 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 SMTP server on the 374 receiving side and as 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 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, presence of BODY=BINARY parameter in FROM- 427 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 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 registration reviewer(s) 446 will be appointed and managed by the editors of this document 447 together with the Independent Submissions Editor. Selected 448 Designated Expert(s) should (collectively) have good knowledge of 449 SMTP protocol (and its extensions/extensibility mechanisms), and ACP 450 142 and its limitations. Subsections of this section provide more 451 details. In particular, Section 6.1 specifies instructions for the 452 Designated Expert(s) and Section 6.2 defines the initial content of 453 the registry. 455 6.1. SMTP Extension Support in MULE 457 Designate 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. (At IANA's discretion the new registry can instead be 489 represented as an extra column in the existing "SMTP Service 490 Extensions" registry.) 492 6.2. SMTP Extension Support in MULE 494 The following table summarizes how different SMTP extensions can be 495 used with MULE. Each extension has one of the following statuses: 496 "Required" (required to be supported by MULE relays, SMTP-to-MULE 497 gateway or MULE-to-SMTP gateway), "Disallowed" (incompatible with 498 MULE), "N/A" (not relevant, because they affect commands other than 499 MAIL FROM and/or RCPT TO, or only defined for SMTP Submission. Such 500 extensions can still be used on the receiving SMTP side of SMTP-to- 501 MULE gateway) "Supported" (can be used with MULE, but requires 502 bilateral agreement between sender and receiver), or "Special". 503 "Special" needs to be accompanied by an explanation. 505 SMTP Extension Support in MULE: 507 +------------------------+-----------+---------------+ 508 | SMTP Extension Keyword | Reference | Status | 509 +------------------------+-----------+---------------+ 510 | SIZE | [RFC1870] | Required | 511 | | | | 512 | 8BITMIME | [RFC6152] | Required | 513 | | | | 514 | DSN | [RFC3461] | Required | 515 | | | | 516 | MT-PRIORITY | [RFC6710] | Required | 517 | | | | 518 | DELIVERBY | [RFC2852] | Required | 519 | | | | 520 | BINARYMIME | [RFC3030] | Required | 521 | | | | 522 | CHUNKING | [RFC3030] | Special (*) | 523 | | | | 524 | ENHANCEDSTATUSCODES | [RFC2034] | Special (**) | 525 | | | | 526 | RRVS | [RFC7293] | Supported | 527 | | | | 528 | SUBMITTER | [RFC4405] | Supported | 529 | | | | 530 | PIPELINING | [RFC2920] | N/A | 531 | | | | 532 | STARTTLS | [RFC3207] | N/A | 533 | | | | 534 | AUTH | [RFC4954] | Special (***) | 535 | | | | 536 | BURL | [RFC4468] | N/A | 537 | | | | 538 | NO-SOLICITING | [RFC3865] | N/A | 539 | | | | 540 | CHECKPOINT | [RFC1845] | Disallowed | 541 | | | | 542 | CONNEG | [RFC4141] | Disallowed | 543 +------------------------+-----------+---------------+ 545 (*) - SMTP CHUNKING MUST be supported on the receiving SMTP side of a 546 SMTP-to-MULE gateway and MAY be used on the sending side of MULE-to- 547 SMTP gateway. MULE relay doesn't need to do anything special for 548 this extension. 550 (**) - ENHANCEDSTATUSCODES extension is supported by including 551 relevant status codes in DSN [RFC3461] reports. 553 (***) - The AUTH parameter to MAIL FROM command is "supported", but 554 the rest of AUTH extension is not applicable to MULE. 556 Note that the above table is not exhaustive. Future RFCs can define 557 how SMTP Extensions not listed above can be used in MULE. 559 7. Security Considerations 561 As MULE provides service similar to SMTP, many of Security 562 Considerations from [RFC5321] apply to MULE as well, in particular 563 Sections 7.1, 7.2, 7.4, 7.6, 7.7, 7.9 of [RFC5321] still apply to 564 MULE. 566 As MULE doesn't support capability negotiation or SMTP HELP command, 567 Section 7.5 of [RFC5321] ("Information Disclosure in Announcements") 568 doesn't apply to MULE. 570 As MULE doesn't support VRFY or EXPN SMTP commands, Section 7.3 of 571 [RFC5321] ("VRFY, EXPN, and Security") that talks about email 572 harvesting doesn't apply to MULE. 574 Arguably, it is more difficult to cause application layer Denial-of- 575 Service attack on a MULE server than on an SMTP server. This is 576 partially due to fact that ACP 142 is used in radio/wireless networks 577 with relatively low bandwidth and very long round trip time 578 (especially if EMCON is in force). However, as MULE is using 579 multicast, multiple MULE nodes can receive the same message and spend 580 CPU processing it, even if the message is addressed to recipients 581 that are not going to be handled by such nodes. As MULE lacks 582 transport layer source authentication, this can be abused by 583 malicious senders. 585 For Security Considerations related to use of zlib compression see 586 [RFC6713]. 588 8. References 590 8.1. Normative References 592 [ACP142A] "Common Messaging strategy and procedures", ACP 142(A), 593 August 2008. 595 [ITU.X690.2002] 596 International Telecommunications Union, "Information 597 Technology - ASN.1 encoding rules: Specification of Basic 598 Encoding Rules (BER), Canonical Encoding Rules (CER) and 599 Distinguished Encoding Rules (DER)", ITU-T Recommendation 600 X.690, July 2002. 602 [RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service 603 Extension for Message Size Declaration", STD 10, RFC 1870, 604 DOI 10.17487/RFC1870, November 1995, 605 . 607 [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format 608 Specification version 3.3", RFC 1950, 609 DOI 10.17487/RFC1950, May 1996, 610 . 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, 614 DOI 10.17487/RFC2119, March 1997, 615 . 617 [RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, 618 DOI 10.17487/RFC2852, June 2000, 619 . 621 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 622 of Large and Binary MIME Messages", RFC 3030, 623 DOI 10.17487/RFC3030, December 2000, 624 . 626 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 627 Extension for Delivery Status Notifications (DSNs)", 628 RFC 3461, DOI 10.17487/RFC3461, January 2003, 629 . 631 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 632 for Delivery Status Notifications", RFC 3464, 633 DOI 10.17487/RFC3464, January 2003, 634 . 636 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 637 Specifications: ABNF", STD 68, RFC 5234, 638 DOI 10.17487/RFC5234, January 2008, 639 . 641 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 642 DOI 10.17487/RFC5321, October 2008, 643 . 645 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 646 DOI 10.17487/RFC5322, October 2008, 647 . 649 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 650 DOI 10.17487/RFC5598, July 2009, 651 . 653 [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed., 654 "SMTP Service Extension for 8-bit MIME Transport", STD 71, 655 RFC 6152, DOI 10.17487/RFC6152, March 2011, 656 . 658 [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for 659 the Reporting of Mail System Administrative Messages", 660 STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, 661 . 663 [RFC6710] Melnikov, A. and K. Carlberg, "Simple Mail Transfer 664 Protocol Extension for Message Transfer Priorities", 665 RFC 6710, DOI 10.17487/RFC6710, August 2012, 666 . 668 [RFC6713] Levine, J., "The 'application/zlib' and 'application/gzip' 669 Media Types", RFC 6713, DOI 10.17487/RFC6713, August 2012, 670 . 672 [RFC7601] Kucherawy, M., "Message Header Field for Indicating 673 Message Authentication Status", RFC 7601, 674 DOI 10.17487/RFC7601, August 2015, 675 . 677 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 678 Writing an IANA Considerations Section in RFCs", BCP 26, 679 RFC 8126, DOI 10.17487/RFC8126, June 2017, 680 . 682 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 683 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 684 May 2017, . 686 [STANAG-4406] 687 "STANAG 4406 Edition 2: Military Message Handling System", 688 STANAG 4406 Ed. 2, March 2005. 690 8.2. Informative References 692 [RFC1845] Crocker, D., Freed, N., and A. Cargille, "SMTP Service 693 Extension for Checkpoint/Restart", RFC 1845, 694 DOI 10.17487/RFC1845, September 1995, 695 . 697 [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced 698 Error Codes", RFC 2034, DOI 10.17487/RFC2034, October 699 1996, . 701 [RFC2442] Freed, N., Newman, D., Belissent, J., and M. Hoy, "The 702 Batch SMTP Media Type", RFC 2442, DOI 10.17487/RFC2442, 703 November 1998, . 705 [RFC2920] Freed, N., "SMTP Service Extension for Command 706 Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920, 707 September 2000, . 709 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 710 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 711 February 2002, . 713 [RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer 714 Protocol (SMTP) Service Extension", RFC 3865, 715 DOI 10.17487/RFC3865, September 2004, 716 . 718 [RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for 719 Content Conversion", RFC 4141, DOI 10.17487/RFC4141, 720 November 2005, . 722 [RFC4405] Allman, E. and H. Katz, "SMTP Service Extension for 723 Indicating the Responsible Submitter of an E-Mail 724 Message", RFC 4405, DOI 10.17487/RFC4405, April 2006, 725 . 727 [RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468, 728 DOI 10.17487/RFC4468, May 2006, 729 . 731 [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service 732 Extension for Authentication", RFC 4954, 733 DOI 10.17487/RFC4954, July 2007, 734 . 736 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 737 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 738 . 740 [RFC7293] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid- 741 Since Header Field and SMTP Service Extension", RFC 7293, 742 DOI 10.17487/RFC7293, July 2014, 743 . 745 Appendix A. Acknowledgements 747 Thank you to Steve Kille for suggestions, comments and corrections on 748 this document. Additional thank you goes to Barry Leiba, Sean Turner 749 and Dave Crocker for reviews and comments on this document. 751 Some text was borrowed from draft-riechmann-multicast-mail-00, thus 752 work of authors of that document is greatefully acknowledged. 754 Authors' Addresses 756 David Wilson 757 Isode Ltd 758 14 Castle Mews 759 Hampton, Middlesex TW12 2NP 760 UK 762 EMail: David.Wilson@isode.com 764 Alexey Melnikov (editor) 765 Isode Ltd 766 14 Castle Mews 767 Hampton, Middlesex TW12 2NP 768 UK 770 EMail: Alexey.Melnikov@isode.com