[RFCs/IDs] [Plain Text] [Nits]
Versions: 00
INTERNET-DRAFT Eric A. Hall
Document: draft-hall-deferrals-00.txt January 2007
Expires: August, 2007
Category: Standards-Track
SMTP Service Extension for Deferred RCPT
Status of this Memo
By submitting this Internet-Draft, each author represents
that any applicable patent or other IPR claims of which he
or she is aware have been or will be disclosed, and any of
which he or she becomes aware will be disclosed, in
accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2007). All Rights Reserved.
Abstract
This memo describes a mechanism for the negotiation and transfer
of per-recipient notification responses in SMTP.
Internet Draft draft-hall-deferrals-00.txt January 2007
Table of Contents
1. Introduction..............................................2
2. Prerequisites and Terminology.............................3
3. The DEFERRALS SMTP Service Extension......................3
4. The DEFERRALS Keyword.....................................4
5. The DEFERRALS Command Extension...........................4
6. The End-of-Data Response Codes............................4
6.1. The 352 Response Code..................................4
6.2. The 353 Response Code..................................5
6.3. The Per-Recipient Response Codes.......................5
6.4. The Final Response Code................................6
6.5. Failure and Timing Considerations......................7
7. Usage Examples............................................8
7.1. One Failure, One Success...............................8
7.2. Total Failure..........................................8
7.3. Mixed-Mode.............................................9
8. Security Considerations...................................9
9. Normative References.....................................10
10. Informative References...................................10
Author's Address..............................................10
Acknowledgments...............................................10
Full Copyright Statement......................................10
1. Introduction
The Simple Mail Transfer Protocol (SMTP) [RFC2821] currently uses
a single response code to indicate whether or not an email message
[RFC2822] has been successfully transferred. This response code
applies to the message data specifically, and therefore applies to
all of the message's recipients collectively, regardless of the
number of recipients which may have been specified in the envelope
or their individual preferences.
However, it has become common practice for different recipients to
have their own content filters, and a single response code is not
sufficiently granular to accurately reflect these differences. For
example, some users may suffer under policy rules which require
them to refuse email messages that contain certain words, while
other users may be required to accept all messages regardless of
content. But since the current SMTP model only allows a single
response code to apply to any given message transfer, the only
legitimate way to accommodate these differences is for a message
to be accepted so that it can be examined off-line, with one or
Hall I-D Expires: August 2007 [page 2]
Internet Draft draft-hall-deferrals-00.txt January 2007
more failure notification messages being returned to the original
sender if the message content later proves to be unacceptable.
This process model introduces a significant burden on both the
sender and recipient servers. The original recipient system must
create, queue, and transfer each of the notification messages, and
the original sender system must map these individual notifications
back to an original message. Simply put, it would be much more
efficient for the recipient system to simply refuse certain email
messages on a per-recipient basis immediately, while the transfer
session was still active. This would alleviate recipient systems
from needing to generate notification messages after-the-fact, and
would also allow the sending system to generate and return a
single notification message immediately.
This specification is intended to provide just that service. This
is achieved through the definition of an SMTP service extension
which advertises support for the service defined herein, a command
extension to the MAIL verb which indicates that a client wishes to
use the service, a set of unique response codes for use when the
service is active, and behavioral rules which implementations are
required to follow when the service has been activated.
2. Prerequisites and Terminology
Readers of this document are expected to be familiar with the
specifications for SMTP (RFC 2821), command pipelining (STD 60)
[STD60], and enhanced status codes (RFC 2034) [RFC2034].
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 RFC 2119
[RFC2119].
3. The DEFERRALS SMTP Service Extension
The extension is defined as follows:
a. the name of the SMTP service extension is DEFERRALS;
b. the EHLO keyword value associated with the extension is
DEFERRALS;
c. the DEFERRALS EHLO keyword has no parameters;
Hall I-D Expires: August 2007 [page 3]
Internet Draft draft-hall-deferrals-00.txt January 2007
d. a DEFERRALS extension is defined for the MAIL FROM
command;
e. the DEFERRALS extension to the MAIL FROM command has no
parameters;
f. no additional commands are extended;
g. no new verbs are defined by this extension;
h. the 352 and 353 response codes are defined for use when the
DEFERRALS extension has been activated; and,
i. the next section specifies how support for the extension
affects the behavior of a server and client SMTP.
4. The DEFERRALS Keyword
The presence of the DEFERRALS keyword in the EHLO greeting
response indicates that the server supports this extension. No
parameters are defined for this keyword.
Servers which offer this service MUST support the command
pipelining extension defined in STD 60 [STD60], and SHOULD support
the extended status codes defined in RFC 2034 [RFC2034].
5. The DEFERRALS Command Extension
Clients indicate that they wish to use the DEFERRALS extension by
providing DEFERRALS as an extension to the MAIL FROM command.
Clients MUST NOT transmit this command extension unless the server
has advertised support for the DEFERRALS service extension in the
EHLO greeting response.
No parameters are defined for this command extension.
6. The DEFERRALS Response Codes
6.1. The 352 Response Code
The 352 response code is used by a server to indicate that the
mailbox address specified in the associated RCPT TO command
appears to be valid, but its validity will not be confirmed until
after the message data has been transferred.
Hall I-D Expires: August 2007 [page 4]
Internet Draft draft-hall-deferrals-00.txt January 2007
Servers MUST NOT generate the 352 response code for this purpose
unless the client has used the DEFERRALS command extension to the
MAIL FROM command during the current envelope exchange.
Clients which receive the 352 response code in response to a RCPT
TO command MUST be prepared for the corresponding recipient to be
rejected after the message data is transferred.
6.2. The 353 Response Code
The 353 response code is used by a server to indicate that the
message appears to be valid, but that one or more of the
recipients may refuse the message.
Servers MUST NOT use the 353 response code for this purpose unless
the server has already used the 352 response code in response to a
RCPT TO command for the current message.
If the message is accepted or refused by every recipient, the 353
response code and the subsequent responses MAY be substituted with
a single response code which reflects the global outcome. For
example, if all of the recipients accepted the email message, then
a single 250 response code MAY be returned in lieu of the 353
response code, the per-recipient response codes, and the final
response code. See section 6.4 for considerations about these
final response codes.
6.3. The Per-Recipient Response Codes
Clients which receive the 353 response code MUST be prepared to
receive recipient-specific response codes for each of the
recipients which had earlier returned 352 response codes during
the current envelope exchange.
When this response code is returned, absolute response codes for
each of the recipients which were earlier acknowledged with a 352
response code during the envelope exchange MUST be provided, and
must be provided in the order in which they were originally
received from the SMTP client.
The per-recipient response codes indicate whether or not the
message content was acceptable for each particular recipient. If
the 353 response code (as described in the preceding section) was
received, the per-recipient response codes MUST be used by the
SMTP client to generate any notification messages.
Hall I-D Expires: August 2007 [page 5]
Internet Draft draft-hall-deferrals-00.txt January 2007
Any response code which is valid for the RCPT TO command is valid
for any per-recipient response code. Each of the recipient-
specific responses MUST use the syntax rules associated with the
canonical definition of that response code. For example, if a
server needs to use the 551 response code to indicate that a
recipient has relocated to another address, that particular
response MUST include the destination mailbox address, as per the
syntax rules defined in RFC 2821.
Servers SHOULD include the appropriate enhanced status code with
each of the per-recipient responses, as defined in RFC 2034
[RFC2034].
Each of these response codes MUST be returned as independent
responses (one per line, or one per multi-line response, as
necessary). Once all of the recipient-specific response codes have
been returned, a final response code MUST be transmitted which
indicates the overall completion result (see section 6.4 for more
information on this final response code).
Note that the per-recipient response codes DO NOT indicate that
the server has accepted responsibility for delivering the message
to that recipient, but instead only indicate whether or not the
recipient is valid. Acceptance for delivery only occurs if and
when the final response code is issued.
6.4. The Final Response Code
Once all of the recipient-specific response codes have been
returned (as described in section 6.2), a final response code MUST
be returned which indicates the actual disposition of the message
transfer operation. This response code MUST reflect the transfer
as a whole, and MUST NOT reflect any particular recipient.
As a rule, if the server has accepted the message for any
recipients, then it MUST return a positive final response. But if
the server has refused to accept the message for all of the
recipients, it MUST return a negative final response, and SHOULD
use a response code which is globally applicable if available. In
those cases where a temporary condition is causing some recipients
to reject the message, then a temporary failure final response
code (4xx) MUST be used.
For example, if the message transfer succeeded but some recipients
were rejected, the transfer will still have succeeded, and would
therefore need to be acknowledged with a positive response code.
Hall I-D Expires: August 2007 [page 6]
Internet Draft draft-hall-deferrals-00.txt January 2007
Conversely, if a shortage of disk space had caused the server to
reject the message for all of the recipients (irregardless of any
of their individual quota restrictions), then the final response
code would need to indicate that condition. If all of the
recipients had rejected the message on permanent grounds, then the
server should return a permanent failure response code as well.
When the server issues the final response code, it accepts
responsibility for delivery of the message to the acknowledged
recipients. The server MUST NOT begin processing the message until
the final response code has been issued.
6.5. Failure and Timing Considerations
There are a handful of scenarios where the client may be unable to
read all of the response codes from the server, resulting in a
state of confusion as to which system actually owns the message.
For example, the connection between the client and server may be
lost while the server is enumerating the per-recipient responses,
with the client having an incomplete view of the actual
disposition. Similarly, the client may time-out while waiting for
the server to enumerate all of the per-recipient response codes.
RFC 1047 [RFC1047] discusses similar scenarios which have occurred
in the past, and which are somewhat more applicable to the
proposed mechanisms described herein.
Clients MUST retain ownership of the message until a final
response code has been received. Servers MUST NOT issue a final
response code until they have enumerated all of the recipients or
are able to apply a global response to all of the recipients. Once
the server has issued the final response, it MUST take ownership
of the message for subsequent processing.
Clients MUST wait 10 minutes for any of the per-recipient and
final response codes to arrive before giving up the transfer. Each
response code received from the server MUST reset the timer.
Servers MUST generate each of the post-data response codes within
one minute of the prior post-data response codes. If a server is
unable to determine an accurate response code during that period,
it MUST return a temporary failure code of some kind, and exit the
subroutine as orderly as possible.
Clients which have an excessive number of problems with a specific
server are generally encouraged to make note of it, and to avoid
Hall I-D Expires: August 2007 [page 7]
Internet Draft draft-hall-deferrals-00.txt January 2007
using the DEFERRALS extension with subsequent queuing operations
for that server.
7. Usage Examples
7.1. One Failure, One Success
The following dialog illustrates a message with two recipients,
one of which refuses the content, the other of which accepts:
S: <waits for connection on TCP port 25>
C: <opens connection>
S: 220 server.example.net
C: EHLO client.example.com
S: 250-server.example.net Hello there
S: 250-DEFERRALS
S: 250-PIPELINING
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<sender@example.com> DEFERRALS
S: 250 okay
C: RCPT TO:<fighter@example.net>
S: 352 recipient looks okay but wait for confirmation
C: RCPT TO:<lover@example.net>
S: 352 recipient looks okay but wait for confirmation
C: DATA
S: 354 go ahead
C: <sends data>
C: <crlf>.<crlf>
S: 353 data looks okay but wait for confirmation
S: 550 5.6.0 <fighter@example.net> refuses the content
S: 250 2.1.5 <lover@example.net> accepts the content
S: 250 data accepted by some recipients
7.2. Total Failure
The following dialog illustrates a message with two recipients,
both of which refuse to accept the message (note that this example
only shows the envelope and data exchange):
C: MAIL FROM:<sender@example.com> DEFERRALS
S: 250 okay
C: RCPT TO:<fighter@example.net>
S: 352 recipient looks okay but wait for confirmation
C: RCPT TO:<lover@example.net>
Hall I-D Expires: August 2007 [page 8]
Internet Draft draft-hall-deferrals-00.txt January 2007
S: 352 recipient looks okay but wait for confirmation
C: DATA
S: 354 go ahead
C: <sends data>
C: <crlf>.<crlf>
S: 550 5.6.0 data refused by all recipients
Since the message contents were refused by all of the recipients,
the data transfer was simply rejected, and it was unnecessary for
the server to generate per-recipient responses.
7.3. Mixed-Mode
The following dialog illustrates a transfer that incorporates
historical response codes as well as the 352 response code (note
that this example only shows the envelope and data exchange):
C: MAIL FROM:<sender@example.com> DEFERRALS
S: 250 okay
C: RCPT TO:<postmaster@example.net>
S: 250 this recipient accepts all messages
C: RCPT TO:<fighter@example.net>
S: 352 recipient looks okay but wait for confirmation
C: RCPT TO:<lover@example.net>
S: 352 recipient looks okay but wait for confirmation
C: RCPT TO:<old-user@example.net>
S: 550 this recipient no longer exists
C: DATA
S: 354 go ahead
C: <sends data>
C: <crlf>.<crlf>
S: 353 data looks okay but wait for confirmation
S: 550 5.6.0 <fighter@example.net> refuses the content
S: 250 2.1.5 <lover@example.net> accepts the content
S: 250 data accepted by some users
Note that the postmaster and old-user mailboxes were not itemized
in the deferred responses, since they were not deferred during the
envelope exchange.
8. Security Considerations
TBD
Hall I-D Expires: August 2007 [page 9]
Internet Draft draft-hall-deferrals-00.txt January 2007
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC
2119, March 1997.
[RFC2034] Freed, N., "SMTP Service Extension for
Returning Enhanced Error Codes", RFC 2034,
December 1996.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[STD60] Freed, N., "SMTP Service Extension for Command
Pipelining", STD 60, RFC 2920, September 2000.
10. Informative References
[RFC2822] Resnick, P., "Internet Message Format", RFC
2822, April 2001.
[RFC1047] Partridge, C., "DUPLICATE MESSAGES AND SMTP",
RFC 1047, February 1988.
Author's Address
Eric A. Hall
ehall@ehsco.com
Acknowledgments
Funding for the RFC editor function is currently provided by the
Internet Society.
Portions of this document were funded by VeriSign Labs.
The first version of this specification was co-authored by Andrew
Newton of VeriSign Labs, and subsequent versions continue to be
developed with his active participation. Edward Lewis and Peter
Gietz also contributed significant feedback to this specification
in the later stages of its developments.
Hall I-D Expires: August 2007 [page 10]
Internet Draft draft-hall-deferrals-00.txt January 2007
Full Copyright Statement
Copyright (C) The Internet Society (2007). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein
are provided on an "AS IS" basis and THE CONTRIBUTOR, THE
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE
INTERNET SOCIETY, (THE IETF TRUST) AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Hall I-D Expires: August 2007 [page 11]
Html markup produced by rfcmarkup 1.70, available from
http://tools.ietf.org/tools/rfcmarkup/