[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                        A. Melnikov
Internet-Draft                                                 Isode Ltd
Intended status: Standards Track                           April 6, 2011
Expires: October 8, 2011


Simple Mail Transfer Protocol extension for Alternate Recipient Delivery
                                 Option
                draft-melnikov-smtp-altrecip-on-error-01

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 October 8, 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 October 8, 2011                [Page 1]


Internet-Draft  SMTP Alternate Recipient Delivery Option      April 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 . . . . . . . . . . . . . . . . . .  5
   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 . . . .  6
     5.3.  Relay of messages to non-conforming SMTP servers . . . . .  7
     5.4.  Local delivery of messages . . . . . . . . . . . . . . . .  8
     5.5.  Gatewaying a message into a foreign environment  . . . . .  8
     5.6.  Delivery to an alternate recipient on delivery failure . .  8
     5.7.  Deployment considerations  . . . . . . . . . . . . . . . .  9
   6.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     10.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 14

















Melnikov                 Expires October 8, 2011                [Page 2]


Internet-Draft  SMTP Alternate Recipient Delivery Option      April 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 a critical message, as bouncing back to the submitter may add too
   much (human or transport) delay to processing of the message.  For
   example the sender might be offline when an relay/delivery error
   occurs and thus might not be able to remedy the situation.

   The extension also designates a single recipient (among one primary
   and one alternate recipient) to be the intended recipient of the
   message at any given time.  Additional trace information added to the
   message allows the alternate recipient to discover why the primary
   recipient was not reachable.

   This extension might be useful for emergency services, aviation/
   military, and sales/support types of 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".




Melnikov                 Expires October 8, 2011                [Page 3]


Internet-Draft  SMTP Alternate Recipient Delivery Option      April 2011


   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
       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 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 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 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 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].








Melnikov                 Expires October 8, 2011                [Page 4]


Internet-Draft  SMTP Alternate Recipient Delivery Option      April 2011


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 <esmtp-value> ([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 <esmtp-values>.
       However, if the associated <esmtp-value> 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 <esmtp-values> 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, if any of the
   RCPT commands contained an ARCPT parameter (see Section 6).  After
   that processing continues as specified in subsequent sections of this



Melnikov                 Expires October 8, 2011                [Page 5]


Internet-Draft  SMTP Alternate Recipient Delivery Option      April 2011


   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).

   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
       <esmtp-value>.  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 <alt-recip-address> 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 find (due to DNS
          resolution failures) or 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].







Melnikov                 Expires October 8, 2011                [Page 6]


Internet-Draft  SMTP Alternate Recipient Delivery Option      April 2011


5.3.  Relay of messages to non-conforming SMTP servers

   The following rules govern the behavior of a conforming MTA (in the
   role of an SMTP 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
       or relayed before deliver-by-time (the BY timer expires) and the
       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 no NOTIFY
       parameter [RFC3461] was supplied, 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].  If both the
       ARCPT and the NOTIFY parameters were supplied for a recipient,
       then processing rules regarding generation and non generation of
       DSNs as specified in [RFC3461] apply.

   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.





Melnikov                 Expires October 8, 2011                [Page 7]


Internet-Draft  SMTP Alternate Recipient Delivery Option      April 2011


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
   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 the by-mode of "R") to the MAIL command), then relaying is
   attempted to the alternate recipient specified in the ARCPT
   parameter.

   Before an attempt to relay the message to the alternate recipient is
   made the message MUST be prepended with a new Delivery-Error header



Melnikov                 Expires October 8, 2011                [Page 8]


Internet-Draft  SMTP Alternate Recipient Delivery Option      April 2011


   field (see Section 6) which records the reason for the failure to
   deliver the message to the original recipient.  This header field
   should be considered a part of the Trace Information [RFC5321].  Note
   that comments in this header field can be used to report a human
   readable version of the error cause.

   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
   parameter value (if specified) becomes the new BY parameter 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 parameter value becomes the new recipient address used in the
   RCPT command.  If an ORCPT parameter was present when the message was
   received, the corresponding RCPT command SHOULD include an ORCPT
   parameter with the value of the ARCPT parameter.

   The new SMTP transaction proceeds as specified in [RFC3461] and
   [RFC2852].

5.7.  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.

   For a given recipient an MTA can accept a message and generate a non
   delivery DSN later instead of just rejecting the recipient at the
   SMTP protocol level.  The extension defined in this document can be
   defeated if the next hop on the route to a primary recipient is such
   an SMTP relay which doesn't conform to this document.  The previous
   hop to such a relay would generate a "relayed" DSN (as per
   Section 5.3), so the sender should be able to discover such
   condition.

   One possible way to address this problem would be to intercept DSNs



Melnikov                 Expires October 8, 2011                [Page 9]


Internet-Draft  SMTP Alternate Recipient Delivery Option      April 2011


   on the way to the MAIL FROM address and resend the original message
   to the alternate recipient.  However this solution is going to be
   more complicated to implement (due to the need to parse DSNs and
   possibly include extra storage for the original message and/or some
   associated state) than just implementing the extension defined in
   this document.  Additionally, such solution would require that the
   MAIL FROM address is to be hosted on a server which can intercept
   such DSNs, which is not always going to be the case.

   For the reason stated above it is RECOMMENDED that, in a particular
   environment where the ALTRECIP extension is to be used, all MTAs/
   MSAs/MDAs on a path to primary recipients support the ALTRECIP SMTP
   extension.

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
                        ; <addr-type> and <xtext>
                        ; are defined in RFC 3461.

   aby-parameter      = "ABY=" by-value

   by-value           = by-time ";" by-mode [by-trace]
                        ; <by-time>, <by-mode> and <by-trace>
                        ; are defined in RFC 2852.
                        ;
                        ; <by-time> is 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

   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 <Additional-Registered-Clauses>
               ; non-terminal syntax from RFC 5321.

   AltRecip-Value = "yes"





Melnikov                 Expires October 8, 2011               [Page 10]


Internet-Draft  SMTP Alternate Recipient Delivery Option      April 2011


   addr-type = <defined in RFC 3461>

   xtext = <defined in RFC 3461>

   by-time = <defined in RFC 2852>

   by-mode = <defined in RFC 2852>

   by-trace = <defined in RFC 2852>

   Via = <defined in RFC 5321>

   With = <defined in RFC 5321>

   ID = <defined in RFC 5321>

   For = <defined in RFC 5321>

   Additional-Registered-Clauses = <defined in RFC 5321>

   CFWS = <defined in RFC 5321>

   Delivery-Error-header-field = "Delivery-Error:" [CFWS] status-code [CFWS] CRLF

   status-code = <defined in RFC 3464>

7.  Example

   An original SMTP transaction with 2 recipients:






















Melnikov                 Expires October 8, 2011               [Page 11]


Internet-Draft  SMTP Alternate Recipient Delivery Option      April 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:<eljefe@example.com> BY=120;R ENVID=QQ314159 ABY=60;R
     S: 250 <eljefe@example.com> sender ok
     C: RCPT TO:<topbanana@example.net> ARCPT=rfc822;bottom-apple@loc2.example.org
     S: 250 <topbanana@example.net> recipient ok
     C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS,FAILURE
         ORCPT=rfc822;Dana@Ivory.example.net
     S: 250 <Dana@Ivory.example.net> 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:<eljefe@example.com> ENVID=QQ314159 BY=60;R
        S: 250 <eljefe@example.com> sender ok
        C: RCPT TO:<bottom-apple@loc2.example.org>
        S: 250 <bottom-apple@loc2.example.org> 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 October 8, 2011               [Page 12]


Internet-Draft  SMTP Alternate Recipient Delivery Option      April 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 was specified for any
   of the recipients of the message
   Syntax of the value: See Section 6 of RFCXXXX
   Reference: [[anchor11: RFCXXXX]]

   IANA is also requested to add the following header field to the list
   of Permanent Message Header Fields to be used by the "mail" protocol:

   Header field: Delivery-Error
   Applicable protocol: mail
   Status: standard
   Author/change controller: Alexey Melnikov / IETF (iesg@ietf.org)
   Specification document(s): [[anchor12: this document]]

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,



Melnikov                 Expires October 8, 2011               [Page 13]


Internet-Draft  SMTP Alternate Recipient Delivery Option      April 2011


              October 2008.

   [RFC3461]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)",
              RFC 3461, January 2003.

   [RFC3464]  Moore, K. and G. Vaudreuil, "An Extensible Message Format
              for Delivery Status Notifications", RFC 3464,
              January 2003.

   [RFC2852]  Newman, D., "Deliver By SMTP Service Extension", RFC 2852,
              June 2000.

   [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.











Melnikov                 Expires October 8, 2011               [Page 14]


Internet-Draft  SMTP Alternate Recipient Delivery Option      April 2011


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 October 8, 2011               [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/