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]