Network Working Group A. Melnikov Internet-Draft Isode Ltd Intended status: Standards Track January 20, 2011 Expires: July 24, 2011 Simple Mail Transfer Protocol extension for Alternate Recipient Delivery Option draft-melnikov-smtp-altrecip-on-error-00 Abstract This document describes an SMTP extension for allowing the submitter to specify an alternate message recipient to be used in case where there is an error or delay delivering the message to a primary recipient. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 24, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Melnikov Expires July 24, 2011 [Page 1] Internet-Draft SMTP Alternate Recipient Delivery Option January 2011 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. SMTP protocol interactions . . . . . . . . . . . . . . . . . . 4 5. Handling of messages received via SMTP . . . . . . . . . . . . 5 5.1. Receipt of a messages by a conforming SMTP servers . . . . 5 5.2. Relay of messages to other conforming SMTP servers . . . . 5 5.3. Relay of messages to non-conforming SMTP servers . . . . . 6 5.4. Local delivery of messages . . . . . . . . . . . . . . . . 7 5.5. Gatewaying a message into a foreign environment . . . . . 8 5.6. Delivery to an alternate recipient on delivery failure . . 8 5.7. Interaction with non-conforming SMTP servers which accept a message and then generate a Non Delivery Report . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.8. Deployment considerations . . . . . . . . . . . . . . . . 9 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Melnikov Expires July 24, 2011 [Page 2] Internet-Draft SMTP Alternate Recipient Delivery Option January 2011 1. Introduction This document describes an SMTP extension for allowing the submitter to specify for each primary recipient an alternate message recipient to be used in case where there is an error or delay delivering the message to the corresponding primary recipient. The submitter can also optionally specify a controlling time. If the message is delivered normally to the primary recipient, the alternate recipient is never used. However if there is a problem delivering to the primary recipient, such as a permanent failure (5xx) reply-code from the next hop MTA/MDA, connection timeout to the next hop MTA/MDA, timer expiration or continuous transient failure (4xx) reply-codes, then the message is forwarded to the alternate recipient and the controlling time (if specified) is used as the new timer for the forwarded message. The motivation behind this extension is to allow automatic handling of critical messages, as bouncing back to the submitter may add too much delay to processing of the message. This extension might be useful for military and support type environments. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234] notation including the core rules defined in Appendix B of RFC 5234 [RFC5234]. 3. Definition The following service extension is defined: 1. The name of the SMTP service extension is "Alternate Recipient on delivery failure". 2. The EHLO keyword value associated with this extension is "ALTRECIP". 3. No parameter values are defined for this EHLO keyword value. In order to permit future (although unanticipated) extensions, the EHLO response MUST NOT contain any parameters for that keyword. Clients MUST ignore any parameters; that is, clients MUST behave as if the parameters do not appear. If a server includes Melnikov Expires July 24, 2011 [Page 3] Internet-Draft SMTP Alternate Recipient Delivery Option January 2011 ALTRECIP in its EHLO response, it MUST be fully compliant with this version of this specification. 4. No additional SMTP verbs are defined by this extension. 5. One optional parameter ("ABY") is added to the MAIL FROM command. The ABY parameter specifies an alternate BY parameter [RFC2852] value that will be used if the message can't be delivered to one of the recipients (possibly within the time period specified in the BY parameter, if it is also present). The ABY parameter includes the by-time field (see Section 6) and some processing flags. The by-time field specifies the a decimal representation of the number of seconds within which the message should be delivered and has the range -999,999,999 seconds <= by-time <= +999,999,999 seconds. 6. One optional parameter ("ARCPT") is added to the RCPT TO command. The ARCPT parameter specifies an alternate email address to deliver this message to in case the corresponding original recipient is unreachable or unreachable within the specified period of time as specified in the MAIL FROM BY parameter. 7. The maximum length of a MAIL FROM command line is increased by up to 18 octets by the possible addition of the ABY keyword and value. The maximum length of a RCPT TO command line is increased by up to 501 octets by the possible addition of the ARCPT keyword and value. 8. Servers offering this extension MUST provide support for, and announce, the DSN [RFC3461] extension and the DELIVERBY [RFC2852] extension. 9. The ALTRECIP extension is valid for the submission service [RFC4409]. The ALTRECIP extension is not valid for LMTP [RFC2033]. 4. SMTP protocol interactions The following rules apply to SMTP transactions in which any of the ABY or ARCPT keywords are used: 1. If an SMTP client issues a MAIL command containing a valid ABY parameter and associated ([RFC5321] Section 4.1.2), a conforming SMTP server MUST return the same reply-code (and Enhanced Status Code) as it would to the same MAIL command without the ABY parameter. A conforming SMTP server MUST NOT refuse a MAIL command based on the absence or presence of a syntactically valid ABY, or on their associated . Melnikov Expires July 24, 2011 [Page 4] Internet-Draft SMTP Alternate Recipient Delivery Option January 2011 However, if the associated is not valid (i.e., contains illegal characters), or if there is more than one ABY parameter in a particular MAIL command, the server MUST issue the reply-code 501 (with 5.5.2 Enhanced Status Code) with an appropriate message (e.g., "syntax error in parameter"). 2. If an SMTP client issues a RCPT command containing any valid ARCPT parameter, a conforming SMTP server MUST return the same response (and Enhanced Status Code) as it would to the same RCPT command without those ARCPT parameter. A conforming SMTP server MUST NOT refuse a RCPT command based on the presence or absence of this parameter. However, if the associated is not valid, or if there is more than one ARCPT parameter in a particular RCPT command, the server SHOULD issue the response "501 syntax error in parameter" (with 5.5.2 Enhanced Status Code). The validity check MUST include verification for syntactic validity, and MAY include verification of the validity of the domain part of the address using DNS or verification of the validity of the whole address (e.g. using SMTP VRFY command, etc.). The entire ARCPT parameter MAY be up to 500 characters in length. 5. Handling of messages received via SMTP This section describes how a conforming MTA should handle any messages received via SMTP. 5.1. Receipt of a messages by a conforming SMTP servers Messages received by an MTA/MSA compliant with this specification are processed as specified by [RFC5321]. Additionally, when inserting a Received header field as specified in Section 4.4 of [RFC5321], the compliant MTA/MSA SHOULD include the ALTRECIP clause which syntax is specified in Section 6. ([[anchor7: Open Issue: Should another Received clause be added that contains the ARCPT value? If yes, it would have implications similar to the currently defined FOR clause.]]) After that processing continues as specified is subsequent sections of this document. 5.2. Relay of messages to other conforming SMTP servers The following rules govern the behavior of a conforming MTA, when relaying a message which was received via the SMTP protocol, to an SMTP server that supports the ALTRECIP SMTP extension. (Note that this section doesn't apply to Mediators, which are covered in Section 5.4). Melnikov Expires July 24, 2011 [Page 5] Internet-Draft SMTP Alternate Recipient Delivery Option January 2011 1. If the ABY parameter was supplied for a message when the message was received, the MAIL command issued when the message is relayed MUST also contain the ABY parameter along with its associated . If the ABY parameter was not supplied when the message was received, the ABY parameter MUST NOT be supplied for that message when the message is relayed. 2. If any ARCPT parameter was present in the RCPT command for a recipient when the message was received, an ARCPT parameter with the identical MUST appear in the RCPT command issued for that recipient when relaying the message. (For example, the MTA acting as a relay therefore MUST NOT change the case of any alphabetic characters in an ARCPT parameter.) If no ARCPT parameter was present in the RCPT command when the message was received, an ARCPT parameter MUST NOT be added to the RCPT command when the message is relayed, unless the receiving MTA is a Mail Submission Agent (MSA). 3. The client MUST act as specified in Section 5.6, if the ARCPT parameter was supplied for a recipient and any of these conditions apply: * the SMTP server returns a permanent failure (5xx) reply-code in response to the RCPT command * the sending MTA is unable to deliver or relay the message to the recipients for an extended length of time (to be determined by the MTA, see [RFC5321]), e.g. due to continuous transient failures (4xx), or inability to contact the next hop MTA. * the sending MTA is unable to deliver or relay the message before deliver-by-time (the BY timer expires) and the by-mode of "R" was specified [RFC2852]. 5.3. Relay of messages to non-conforming SMTP servers The following rules govern the behavior of a conforming MTA (in the role of client), when relaying a message which was received via the SMTP protocol, to an SMTP server that does not support the ALTRECIP SMTP extension: 1. ABY or ARCPT parameters MUST NOT be issued when relaying the message. 2. Parameters to MAIL and RCPT commands specified in [RFC3461] and [RFC2852] cause actions as specified in the respective documents, with the following exception: if the the message is not delivered Melnikov Expires July 24, 2011 [Page 6] Internet-Draft SMTP Alternate Recipient Delivery Option January 2011 or relayed before deliver-by-time (the BY timer expires) and a by-mode of "R" was specified, the client MUST act as specified Section 5.6. 3. If the ARCPT parameter was supplied for a recipient, and the SMTP server returns a permanent failure (5xx) reply-code in response to the RCPT command, the client MUST act as specified Section 5.6. 4. If the ARCPT parameter was supplied for a recipient, and the SMTP server returns a transient failure (4xx) reply-code in response to the RCPT command, and the sending MTA is unable to deliver or relay the message to the recipients for an extended length of time (to be determined by the MTA, see [RFC5321]), the client MUST act as specified Section 5.6. 5. If the ARCPT parameter was supplied for a recipient, and the SMTP server returns a success (2xx) reply-code in response to the RCPT command, the client MUST issue a "relayed" DSN for that recipient, as if the recipient included NOTIFY=SUCCESS value [RFC3461]. Note: relaying to non-conformant MTAs is on the "best effort" basis. While this is not ideal, one of the motivations behind this extension is to avoid the need for the submitter to take explicit action in case a delivery to a primary recipient fails. So this document is recommending an attempt to deliver the message to the primary recipient when ALTRECIP is not supported by the next hop, in favor of bouncing the message or forwarding it to the corresponding alternative recipient. 5.4. Local delivery of messages Upon successful delivery of a message that was received via the SMTP protocol, to a local recipient's mailbox, a conforming MTA MUST ignore the ARCPT and the ABY parameters. This extension doesn't require the MTA to perform any additional actions. "Delivery" means that the message has been handed to the recipient's mailbox. For messages which are transmitted to a mailbox for later retrieval via [RFC3501], [RFC1939] or a similar message access protocol, "delivery" occurs when the message is made available to the IMAP (POP, etc.) service, rather than when the message is retrieved by the recipient's user agent. Similarly, for a recipient address which corresponds to a Mediator (as defined in [RFC5598]), such as a mailing list exploder, an alias or a ReSender, "delivery" occurs when the message is made available Melnikov Expires July 24, 2011 [Page 7] Internet-Draft SMTP Alternate Recipient Delivery Option January 2011 to that mediator, even though the mediator might refuse to deliver that message to its recipient(s). 5.5. Gatewaying a message into a foreign environment The following rules govern the behavior of a conforming MTA, when gatewaying a message that was received via the SMTP protocol, into a foreign (non-SMTP) environment: 1. If the destination environment is unable to provide an equivalent of ABY and ARCPT parameters, the conforming MTA SHOULD behave as if it is relaying to a non-conformant SMTP (Section 5.3). In particular note the requirement to generate a "relayed" DSN on successful gatewaying for a recipient. 2. If the destination environment is capable of providing an equivalent of ABY and ARCPT parameters, the conforming MTA SHOULD behave as if it is relaying to a conformant SMTP (Section 5.2). Note that gateways to such environments can map ABY/ARCPT parameters as required. 5.6. Delivery to an alternate recipient on delivery failure When delivery to an original recipient fails (or doesn't succeed within the specified time period as described by the BY parameter (with by-mode of "R") to the MAIL command), then a delivery is attempted to the alternate recipient specified in the ARCPT parameter. Because the value of the BY parameter to the MAIL command is decreasing with each hop, it is not suitable for use in the new transaction to alternate recipients. The ABY ("Alternate BY") parameter is used to replace it in the new transaction. The new MAIL command includes all MAIL parameters originally specified (unless a future SMTP extension explicitly excludes one of the parameters), with the exception of ABY (if any) and BY (if any). The ABY value (if specified) becomes the new BY value. The new RCPT command includes all RCPT parameters originally specified (unless a future SMTP extension explicitly excludes one of the parameters), with the exception of ARPCT and ORCPT (if any). The ARCPT value becomes the new recipient address used by the RCPT command. The new SMTP transaction proceeds as specified in [RFC3461] and [RFC2852]. [[anchor9: Open Issue: Should an extra Received header field be added Melnikov Expires July 24, 2011 [Page 8] Internet-Draft SMTP Alternate Recipient Delivery Option January 2011 that contains information about the error condition that caused redirect? How does this interact with loop detection (and does it matter)? Alternatively, a new header field can be defined for this purpose.]] 5.7. Interaction with non-conforming SMTP servers which accept a message and then generate a Non Delivery Report [[anchor11: Open Issue: As some non-conforming SMTP relays are going to accept a message and generate an NDN, instead of rejecting the corresponding recipient over the protocol, the document should specify if some system on the way back to the submitter (e.g. MDA for the Return-path) needs to intercept NDNs that correspond to ALTRECIP SMTP transactions and convert them to new SMTP transactions. Maybe this is just another deployment consideration.]] 5.8. Deployment considerations Organizations often authorize multiple servers to accept mail addressed to them. For example, the organization may itself operate more than one server, and may also or instead have an agreement with other organizations to accept mail as a backup. Authorized servers are generally listed in MX records as described in [RFC5321]. When more than one server accepts mail for the domain-part of a mailbox, it is strongly advised that either all or none of them support the ALTRECIP extension. Otherwise, unpredictable behavior and mail failures might occur. 6. Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in [RFC5234]. Terms not defined here are taken from [RFC2852], [RFC3461] and [RFC5321]. alt-rcpt-parameter = "ARCPT=" alt-recip-address alt-recip-address = addr-type ";" xtext ; and ; are defined in RFC 3461. aby-parameter = "ABY=" by-value by-value = by-time ";" by-mode [by-trace] ; , and ; are defined in RFC 2852. ; ; is a decimal representation of ; the number of seconds within which the message Melnikov Expires July 24, 2011 [Page 9] Internet-Draft SMTP Alternate Recipient Delivery Option January 2011 ; should be delivered and has the range ; -999,999,999 seconds <= by-time <= +999,999,999 seconds Opt-info = [Via] [With] [ID] [For] [AltRecip] [Additional-Registered-Clauses] ; Updates the Opt-info defined in RFC 5321 AltRecip = CFWS "ALTRECIP" FWS AltRecip-Value ; Complies with the ; non-terminal syntax from RFC 5321. AltRecip-Value = "yes" addr-type = xtext = by-time = by-mode = by-trace = Via = With = ID = For = Additional-Registered-Clauses = CFWS = 7. Example An original SMTP transaction with 2 recipients: Melnikov Expires July 24, 2011 [Page 10] Internet-Draft SMTP Alternate Recipient Delivery Option January 2011 S: 220 example.net SMTP server here C: EHLO example.com S: 250-example.net S: 250-DSN S: 250-DELIVERBY S: 250-ALTRECIP C: MAIL FROM: BY=120;R ENVID=QQ314159 ABY=60;R S: 250 sender ok C: RCPT TO: ARCPT=rfc822;bottom-apple@loc2.example.org S: 250 recipient ok C: RCPT TO: NOTIFY=SUCCESS,FAILURE ORCPT=rfc822;Dana@Ivory.example.net S: 250 recipient ok C: DATA S: 354 okay, send message C: (message goes here) C: . S: 250 message accepted C: QUIT S: 221 goodbye The receiving MTA then tries to deliver the message to the next hop. If delivery to the first recipient fails (e.g. due to timer expiration or receipt of a 5XX status code), the message will be forwarded to an alternate recipient for the first message. The new SMTP transaction would look like: S: 220 loc2.example.org SMTP server here C: EHLO example.net S: 250-loc2.example.org S: 250-DSN S: 250-DELIVERBY S: 250-ALTRECIP C: MAIL FROM: ENVID=QQ314159 BY=60;R S: 250 sender ok C: RCPT TO: S: 250 is welcomed here C: DATA S: 354 okay, send message C: (message goes here) C: . S: 250 message accepted C: QUIT S: 221 goodbye Melnikov Expires July 24, 2011 [Page 11] Internet-Draft SMTP Alternate Recipient Delivery Option January 2011 8. IANA Considerations This specification requests IANA to add the following SMTP extension to the list of registered SMTP Extensions: ALTRECIP. This specification also requests IANA to add the following new Received header field clause to help with tracing email messages delivered using the ALTRECIP SMTP extension: Clause name: ALTRECIP Description: Signals whether an ARCPT parameter is specified for any of the recipients of the message Syntax of the value: See Section 6 of RFCXXXX Reference: [[anchor15: RFCXXXX]] 9. Security Considerations Use of this extension can advertise to an attacker criticality or urgency of a message. In addition to this, the use of ARCPT parameter to RCPT command can advertise relationship of a primary recipient to the corresponding alternate recipient. If such information is confidential, use of a SMTP extension that can provide connection confidentiality such as [RFC3207] is recommended. Also see Security Considerations of [RFC3461] and [RFC2852] for information of security considerations related to SMTP DSN and SMTP DELIVERBY extensions respectively. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003. [RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000. Melnikov Expires July 24, 2011 [Page 12] Internet-Draft SMTP Alternate Recipient Delivery Option January 2011 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006. [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. 10.2. Informative References [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996. [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. Appendix A. Acknowledgements Many thanks for input provided by Steve Kille, John Klensin, Dave Crocker and David Wilson. The author of this document copied lots of text from RFC 3461 and RFC 2852. Author's Address Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK EMail: Alexey.Melnikov@isode.com Melnikov Expires July 24, 2011 [Page 13]