idnits 2.17.00 (12 Aug 2021) /tmp/idnits3564/draft-melnikov-smtp-altrecip-on-error-01.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 3 instances of too long lines in the document, the longest one being 10 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 6, 2011) is 4056 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Via' is mentioned on line 450, but not defined == Missing Reference: 'With' is mentioned on line 450, but not defined == Missing Reference: 'ID' is mentioned on line 450, but not defined == Missing Reference: 'For' is mentioned on line 450, but not defined == Missing Reference: 'AltRecip' is mentioned on line 450, but not defined == Missing Reference: 'Additional-Registered-Clauses' is mentioned on line 451, but not defined == Missing Reference: 'CFWS' is mentioned on line 481, but not defined == Unused Reference: 'RFC3464' is defined on line 588, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4409 (Obsoleted by RFC 6409) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode Ltd 4 Intended status: Standards Track April 6, 2011 5 Expires: October 8, 2011 7 Simple Mail Transfer Protocol extension for Alternate Recipient Delivery 8 Option 9 draft-melnikov-smtp-altrecip-on-error-01 11 Abstract 13 This document describes an SMTP extension for allowing the submitter 14 to specify an alternate message recipient to be used in case where 15 there is an error or delay delivering the message to a primary 16 recipient. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 8, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 66 3. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. SMTP protocol interactions . . . . . . . . . . . . . . . . . . 5 68 5. Handling of messages received via SMTP . . . . . . . . . . . . 5 69 5.1. Receipt of a messages by a conforming SMTP servers . . . . 5 70 5.2. Relay of messages to other conforming SMTP servers . . . . 6 71 5.3. Relay of messages to non-conforming SMTP servers . . . . . 7 72 5.4. Local delivery of messages . . . . . . . . . . . . . . . . 8 73 5.5. Gatewaying a message into a foreign environment . . . . . 8 74 5.6. Delivery to an alternate recipient on delivery failure . . 8 75 5.7. Deployment considerations . . . . . . . . . . . . . . . . 9 76 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 83 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 This document describes an SMTP extension for allowing the submitter 88 to specify for each primary recipient an alternate message recipient 89 to be used in case where there is an error or delay delivering the 90 message to the corresponding primary recipient. The submitter can 91 also optionally specify a controlling time. If the message is 92 delivered normally to the primary recipient, the alternate recipient 93 is never used. However if there is a problem delivering to the 94 primary recipient, such as a permanent failure (5xx) reply-code from 95 the next hop MTA/MDA, connection timeout to the next hop MTA/MDA, 96 timer expiration or continuous transient failure (4xx) reply-codes, 97 then the message is forwarded to the alternate recipient and the 98 controlling time (if specified) is used as the new timer for the 99 forwarded message. 101 The motivation behind this extension is to allow automatic handling 102 of a critical message, as bouncing back to the submitter may add too 103 much (human or transport) delay to processing of the message. For 104 example the sender might be offline when an relay/delivery error 105 occurs and thus might not be able to remedy the situation. 107 The extension also designates a single recipient (among one primary 108 and one alternate recipient) to be the intended recipient of the 109 message at any given time. Additional trace information added to the 110 message allows the alternate recipient to discover why the primary 111 recipient was not reachable. 113 This extension might be useful for emergency services, aviation/ 114 military, and sales/support types of environments. 116 2. Conventions Used in This Document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234] 123 notation including the core rules defined in Appendix B of RFC 5234 124 [RFC5234]. 126 3. Definition 128 The following service extension is defined: 130 1. The name of the SMTP service extension is "Alternate Recipient on 131 delivery failure". 133 2. The EHLO keyword value associated with this extension is 134 "ALTRECIP". 136 3. No parameter values are defined for this EHLO keyword value. In 137 order to permit future (although unanticipated) extensions, the 138 EHLO response MUST NOT contain any parameters for that keyword. 139 Clients MUST ignore any parameters; that is, clients MUST behave 140 as if the parameters do not appear. If a server includes 141 ALTRECIP in its EHLO response, it MUST be fully compliant with 142 this version of this specification. 144 4. No additional SMTP verbs are defined by this extension. 146 5. One optional parameter ("ABY") is added to the MAIL command. The 147 ABY parameter specifies an alternate BY parameter [RFC2852] value 148 that will be used if the message can't be delivered to one of the 149 recipients (possibly within the time period specified in the BY 150 parameter, if it is also present). The ABY parameter includes 151 the by-time field (see Section 6) and some processing flags. The 152 by-time field specifies the a decimal representation of the 153 number of seconds within which the message should be delivered 154 and has the range -999,999,999 seconds <= by-time <= +999,999,999 155 seconds. 157 6. One optional parameter ("ARCPT") is added to the RCPT command. 158 The ARCPT parameter specifies an alternate email address to 159 deliver this message to in case the corresponding original 160 recipient is unreachable or unreachable within the specified 161 period of time as specified in the MAIL FROM BY parameter. 163 7. The maximum length of a MAIL command line is increased by up to 164 18 octets by the possible addition of the ABY keyword and value. 165 The maximum length of a RCPT command line is increased by up to 166 501 octets by the possible addition of the ARCPT keyword and 167 value. 169 8. Servers offering this extension MUST provide support for, and 170 announce, the DSN [RFC3461] extension and the DELIVERBY [RFC2852] 171 extension. 173 9. The ALTRECIP extension is valid for the submission service 174 [RFC4409]. The ALTRECIP extension is not valid for LMTP 175 [RFC2033]. 177 4. SMTP protocol interactions 179 The following rules apply to SMTP transactions in which any of the 180 ABY or ARCPT keywords are used: 182 1. If an SMTP client issues a MAIL command containing a valid ABY 183 parameter and associated ([RFC5321] Section 4.1.2), 184 a conforming SMTP server MUST return the same reply-code (and 185 Enhanced Status Code) as it would to the same MAIL command 186 without the ABY parameter. A conforming SMTP server MUST NOT 187 refuse a MAIL command based on the absence or presence of a 188 syntactically valid ABY, or on their associated . 189 However, if the associated is not valid (i.e., 190 contains illegal characters), or if there is more than one ABY 191 parameter in a particular MAIL command, the server MUST issue the 192 reply-code 501 (with 5.5.2 Enhanced Status Code) with an 193 appropriate message (e.g., "syntax error in parameter"). 195 2. If an SMTP client issues a RCPT command containing any valid 196 ARCPT parameter, a conforming SMTP server MUST return the same 197 response (and Enhanced Status Code) as it would to the same RCPT 198 command without those ARCPT parameter. A conforming SMTP server 199 MUST NOT refuse a RCPT command based on the presence or absence 200 of this parameter. However, if the associated is 201 not valid, or if there is more than one ARCPT parameter in a 202 particular RCPT command, the server SHOULD issue the response 203 "501 syntax error in parameter" (with 5.5.2 Enhanced Status 204 Code). The validity check MUST include verification for 205 syntactic validity, and MAY include verification of the validity 206 of the domain part of the address using DNS or verification of 207 the validity of the whole address (e.g. using SMTP VRFY command, 208 etc.). 210 The entire ARCPT parameter MAY be up to 500 characters in length. 212 5. Handling of messages received via SMTP 214 This section describes how a conforming MTA should handle any 215 messages received via SMTP. 217 5.1. Receipt of a messages by a conforming SMTP servers 219 Messages received by an MTA/MSA compliant with this specification are 220 processed as specified by [RFC5321]. Additionally, when inserting a 221 Received header field as specified in Section 4.4 of [RFC5321], the 222 compliant MTA/MSA SHOULD include the ALTRECIP clause, if any of the 223 RCPT commands contained an ARCPT parameter (see Section 6). After 224 that processing continues as specified in subsequent sections of this 225 document. 227 5.2. Relay of messages to other conforming SMTP servers 229 The following rules govern the behavior of a conforming MTA, when 230 relaying a message which was received via the SMTP protocol, to an 231 SMTP server that supports the ALTRECIP SMTP extension. (Note that 232 this section doesn't apply to Mediators, which are covered in 233 Section 5.4). 235 1. If the ABY parameter was supplied for a message when the message 236 was received, the MAIL command issued when the message is relayed 237 MUST also contain the ABY parameter along with its associated 238 . If the ABY parameter was not supplied when the 239 message was received, the ABY parameter MUST NOT be supplied for 240 that message when the message is relayed. 242 2. If any ARCPT parameter was present in the RCPT command for a 243 recipient when the message was received, an ARCPT parameter with 244 the identical MUST appear in the RCPT command 245 issued for that recipient when relaying the message. (For 246 example, the MTA acting as a relay therefore MUST NOT change the 247 case of any alphabetic characters in an ARCPT parameter.) If no 248 ARCPT parameter was present in the RCPT command when the message 249 was received, an ARCPT parameter MUST NOT be added to the RCPT 250 command when the message is relayed, unless the receiving MTA is 251 a Mail Submission Agent (MSA). 253 3. The client MUST act as specified in Section 5.6, if the ARCPT 254 parameter was supplied for a recipient and any of these 255 conditions apply: 257 * the SMTP server returns a permanent failure (5xx) reply-code 258 in response to the RCPT command 260 * the sending MTA is unable to deliver or relay the message to 261 the recipients for an extended length of time (to be 262 determined by the MTA, see [RFC5321]), e.g. due to continuous 263 transient failures (4xx), or inability to find (due to DNS 264 resolution failures) or contact the next hop MTA. 266 * the sending MTA is unable to deliver or relay the message 267 before deliver-by-time (the BY timer expires) and the by-mode 268 of "R" was specified [RFC2852]. 270 5.3. Relay of messages to non-conforming SMTP servers 272 The following rules govern the behavior of a conforming MTA (in the 273 role of an SMTP client), when relaying a message which was received 274 via the SMTP protocol, to an SMTP server that does not support the 275 ALTRECIP SMTP extension: 277 1. ABY or ARCPT parameters MUST NOT be issued when relaying the 278 message. 280 2. Parameters to MAIL and RCPT commands specified in [RFC3461] and 281 [RFC2852] cause actions as specified in the respective documents, 282 with the following exception: if the the message is not delivered 283 or relayed before deliver-by-time (the BY timer expires) and the 284 by-mode of "R" was specified, the client MUST act as specified 285 Section 5.6. 287 3. If the ARCPT parameter was supplied for a recipient, and the SMTP 288 server returns a permanent failure (5xx) reply-code in response 289 to the RCPT command, the client MUST act as specified 290 Section 5.6. 292 4. If the ARCPT parameter was supplied for a recipient, and the SMTP 293 server returns a transient failure (4xx) reply-code in response 294 to the RCPT command, and the sending MTA is unable to deliver or 295 relay the message to the recipients for an extended length of 296 time (to be determined by the MTA, see [RFC5321]), the client 297 MUST act as specified Section 5.6. 299 5. If the ARCPT parameter was supplied for a recipient and no NOTIFY 300 parameter [RFC3461] was supplied, and the SMTP server returns a 301 success (2xx) reply-code in response to the RCPT command, the 302 client MUST issue a "relayed" DSN for that recipient, as if the 303 recipient included NOTIFY=SUCCESS value [RFC3461]. If both the 304 ARCPT and the NOTIFY parameters were supplied for a recipient, 305 then processing rules regarding generation and non generation of 306 DSNs as specified in [RFC3461] apply. 308 Note: relaying to non-conformant MTAs is on the "best effort" basis. 309 While this is not ideal, one of the motivations behind this extension 310 is to avoid the need for the submitter to take explicit action in 311 case a delivery to a primary recipient fails. So this document is 312 recommending an attempt to deliver the message to the primary 313 recipient when ALTRECIP is not supported by the next hop, in favor of 314 bouncing the message or forwarding it to the corresponding 315 alternative recipient. 317 5.4. Local delivery of messages 319 Upon successful delivery of a message that was received via the SMTP 320 protocol, to a local recipient's mailbox, a conforming MTA MUST 321 ignore the ARCPT and the ABY parameters. This extension doesn't 322 require the MTA to perform any additional actions. 324 "Delivery" means that the message has been handed to the recipient's 325 mailbox. For messages which are transmitted to a mailbox for later 326 retrieval via [RFC3501], [RFC1939] or a similar message access 327 protocol, "delivery" occurs when the message is made available to the 328 IMAP (POP, etc.) service, rather than when the message is retrieved 329 by the recipient's user agent. 331 Similarly, for a recipient address which corresponds to a Mediator 332 (as defined in [RFC5598]), such as a mailing list exploder, an alias 333 or a ReSender, "delivery" occurs when the message is made available 334 to that mediator, even though the mediator might refuse to deliver 335 that message to its recipient(s). 337 5.5. Gatewaying a message into a foreign environment 339 The following rules govern the behavior of a conforming MTA, when 340 gatewaying a message that was received via the SMTP protocol, into a 341 foreign (non-SMTP) environment: 343 1. If the destination environment is unable to provide an equivalent 344 of ABY and ARCPT parameters, the conforming MTA SHOULD behave as 345 if it is relaying to a non-conformant SMTP (Section 5.3). In 346 particular note the requirement to generate a "relayed" DSN on 347 successful gatewaying for a recipient. 349 2. If the destination environment is capable of providing an 350 equivalent of ABY and ARCPT parameters, the conforming MTA SHOULD 351 behave as if it is relaying to a conformant SMTP (Section 5.2). 352 Note that gateways to such environments can map ABY/ARCPT 353 parameters as required. 355 5.6. Delivery to an alternate recipient on delivery failure 357 When delivery to an original recipient fails (or doesn't succeed 358 within the specified time period as described by the BY parameter 359 (with the by-mode of "R") to the MAIL command), then relaying is 360 attempted to the alternate recipient specified in the ARCPT 361 parameter. 363 Before an attempt to relay the message to the alternate recipient is 364 made the message MUST be prepended with a new Delivery-Error header 365 field (see Section 6) which records the reason for the failure to 366 deliver the message to the original recipient. This header field 367 should be considered a part of the Trace Information [RFC5321]. Note 368 that comments in this header field can be used to report a human 369 readable version of the error cause. 371 Because the value of the BY parameter to the MAIL command is 372 decreasing with each hop, it is not suitable for use in the new 373 transaction to alternate recipients. The ABY ("Alternate BY") 374 parameter is used to replace it in the new transaction. The new MAIL 375 command includes all MAIL parameters originally specified (unless a 376 future SMTP extension explicitly excludes one of the parameters), 377 with the exception of ABY (if any) and BY (if any). The ABY 378 parameter value (if specified) becomes the new BY parameter value. 380 The new RCPT command includes all RCPT parameters originally 381 specified (unless a future SMTP extension explicitly excludes one of 382 the parameters), with the exception of ARPCT and ORCPT (if any). The 383 ARCPT parameter value becomes the new recipient address used in the 384 RCPT command. If an ORCPT parameter was present when the message was 385 received, the corresponding RCPT command SHOULD include an ORCPT 386 parameter with the value of the ARCPT parameter. 388 The new SMTP transaction proceeds as specified in [RFC3461] and 389 [RFC2852]. 391 5.7. Deployment considerations 393 Organizations often authorize multiple servers to accept mail 394 addressed to them. For example, the organization may itself operate 395 more than one server, and may also or instead have an agreement with 396 other organizations to accept mail as a backup. Authorized servers 397 are generally listed in MX records as described in [RFC5321]. When 398 more than one server accepts mail for the domain-part of a mailbox, 399 it is strongly advised that either all or none of them support the 400 ALTRECIP extension. Otherwise, unpredictable behavior and mail 401 failures might occur. 403 For a given recipient an MTA can accept a message and generate a non 404 delivery DSN later instead of just rejecting the recipient at the 405 SMTP protocol level. The extension defined in this document can be 406 defeated if the next hop on the route to a primary recipient is such 407 an SMTP relay which doesn't conform to this document. The previous 408 hop to such a relay would generate a "relayed" DSN (as per 409 Section 5.3), so the sender should be able to discover such 410 condition. 412 One possible way to address this problem would be to intercept DSNs 413 on the way to the MAIL FROM address and resend the original message 414 to the alternate recipient. However this solution is going to be 415 more complicated to implement (due to the need to parse DSNs and 416 possibly include extra storage for the original message and/or some 417 associated state) than just implementing the extension defined in 418 this document. Additionally, such solution would require that the 419 MAIL FROM address is to be hosted on a server which can intercept 420 such DSNs, which is not always going to be the case. 422 For the reason stated above it is RECOMMENDED that, in a particular 423 environment where the ALTRECIP extension is to be used, all MTAs/ 424 MSAs/MDAs on a path to primary recipients support the ALTRECIP SMTP 425 extension. 427 6. Syntax 429 The following syntax specification uses the Augmented Backus-Naur 430 Form (ABNF) as described in [RFC5234]. Terms not defined here are 431 taken from [RFC2852], [RFC3461] and [RFC5321]. 433 alt-rcpt-parameter = "ARCPT=" alt-recip-address 435 alt-recip-address = addr-type ";" xtext 436 ; and 437 ; are defined in RFC 3461. 439 aby-parameter = "ABY=" by-value 441 by-value = by-time ";" by-mode [by-trace] 442 ; , and 443 ; are defined in RFC 2852. 444 ; 445 ; is a decimal representation of 446 ; the number of seconds within which the message 447 ; should be delivered and has the range 448 ; -999,999,999 seconds <= by-time <= +999,999,999 seconds 450 Opt-info = [Via] [With] [ID] [For] [AltRecip] 451 [Additional-Registered-Clauses] 452 ; Updates the Opt-info defined in RFC 5321 454 AltRecip = CFWS "ALTRECIP" FWS AltRecip-Value 455 ; Complies with the 456 ; non-terminal syntax from RFC 5321. 458 AltRecip-Value = "yes" 459 addr-type = 461 xtext = 463 by-time = 465 by-mode = 467 by-trace = 469 Via = 471 With = 473 ID = 475 For = 477 Additional-Registered-Clauses = 479 CFWS = 481 Delivery-Error-header-field = "Delivery-Error:" [CFWS] status-code [CFWS] CRLF 483 status-code = 485 7. Example 487 An original SMTP transaction with 2 recipients: 489 S: 220 example.net SMTP server here 490 C: EHLO example.com 491 S: 250-example.net 492 S: 250-DSN 493 S: 250-DELIVERBY 494 S: 250-ALTRECIP 495 C: MAIL FROM: BY=120;R ENVID=QQ314159 ABY=60;R 496 S: 250 sender ok 497 C: RCPT TO: ARCPT=rfc822;bottom-apple@loc2.example.org 498 S: 250 recipient ok 499 C: RCPT TO: NOTIFY=SUCCESS,FAILURE 500 ORCPT=rfc822;Dana@Ivory.example.net 501 S: 250 recipient ok 502 C: DATA 503 S: 354 okay, send message 504 C: (message goes here) 505 C: . 506 S: 250 message accepted 507 C: QUIT 508 S: 221 goodbye 510 The receiving MTA then tries to deliver the message to the next hop. 511 If delivery to the first recipient fails (e.g. due to timer 512 expiration or receipt of a 5XX status code), the message will be 513 forwarded to an alternate recipient for the first message. The new 514 SMTP transaction would look like: 516 S: 220 loc2.example.org SMTP server here 517 C: EHLO example.net 518 S: 250-loc2.example.org 519 S: 250-DSN 520 S: 250-DELIVERBY 521 S: 250-ALTRECIP 522 C: MAIL FROM: ENVID=QQ314159 BY=60;R 523 S: 250 sender ok 524 C: RCPT TO: 525 S: 250 is welcomed here 526 C: DATA 527 S: 354 okay, send message 528 C: (message goes here) 529 C: . 530 S: 250 message accepted 531 C: QUIT 532 S: 221 goodbye 534 8. IANA Considerations 536 This specification requests IANA to add the following SMTP extension 537 to the list of registered SMTP Extensions: ALTRECIP. 539 This specification also requests IANA to add the following new 540 Received header field clause to help with tracing email messages 541 delivered using the ALTRECIP SMTP extension: 543 Clause name: ALTRECIP 544 Description: Signals whether an ARCPT parameter was specified for any 545 of the recipients of the message 546 Syntax of the value: See Section 6 of RFCXXXX 547 Reference: [[anchor11: RFCXXXX]] 549 IANA is also requested to add the following header field to the list 550 of Permanent Message Header Fields to be used by the "mail" protocol: 552 Header field: Delivery-Error 553 Applicable protocol: mail 554 Status: standard 555 Author/change controller: Alexey Melnikov / IETF (iesg@ietf.org) 556 Specification document(s): [[anchor12: this document]] 558 9. Security Considerations 560 Use of this extension can advertise to an attacker criticality or 561 urgency of a message. In addition to this, the use of ARCPT 562 parameter to RCPT command can advertise relationship of a primary 563 recipient to the corresponding alternate recipient. If such 564 information is confidential, use of a SMTP extension that can provide 565 connection confidentiality such as [RFC3207] is recommended. 567 Also see Security Considerations of [RFC3461] and [RFC2852] for 568 information of security considerations related to SMTP DSN and SMTP 569 DELIVERBY extensions respectively. 571 10. References 573 10.1. Normative References 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, March 1997. 578 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 579 Specifications: ABNF", STD 68, RFC 5234, January 2008. 581 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 582 October 2008. 584 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 585 Extension for Delivery Status Notifications (DSNs)", 586 RFC 3461, January 2003. 588 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 589 for Delivery Status Notifications", RFC 3464, 590 January 2003. 592 [RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, 593 June 2000. 595 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 596 RFC 4409, April 2006. 598 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 599 Transport Layer Security", RFC 3207, February 2002. 601 10.2. Informative References 603 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 604 October 1996. 606 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 607 STD 53, RFC 1939, May 1996. 609 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 610 4rev1", RFC 3501, March 2003. 612 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 613 July 2009. 615 Appendix A. Acknowledgements 617 Many thanks for input provided by Steve Kille, John Klensin, Dave 618 Crocker and David Wilson. 620 The author of this document copied lots of text from RFC 3461 and RFC 621 2852. 623 Author's Address 625 Alexey Melnikov 626 Isode Ltd 627 5 Castle Business Village 628 36 Station Road 629 Hampton, Middlesex TW12 2BX 630 UK 632 EMail: Alexey.Melnikov@isode.com