Internet DRAFT - draft-hall-prdr
draft-hall-prdr
INTERNET-DRAFT Eric A. Hall
draft-hall-prdr-00.txt 2 April 2007
Category: Standards Track
Expires: October 2007
SMTP Service Extension for Per-Recipient Data
Responses (PRDR)
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This memo defines an extension to the SMTP protocol that allows for
the use of recipient-specific responses to message transfers.
Hall Standards Track [page 1]
Internet-Draft draft-hall-prdr-00.txt 2 April 2007
Table of Contents
1. Introduction...................................................2
2. Prerequisites..................................................4
3. Functional Overview............................................4
4. The PRDR Extension to SMTP.....................................5
4.1. The PRDR EHLO Keyword....................................6
4.2. The PRDR Extension to the MAIL FROM Command..............6
4.3. RCPT TO Commands and Responses...........................7
4.4. Message Data Commands and Responses......................7
4.5. The Per-Recipient Data Response Block....................8
4.6. Post-Transfer Processing................................11
4.7. Failure and Timing Considerations.......................13
5. Usage Examples................................................14
5.1. One Failure, One Success................................14
5.2. Total Failure...........................................14
6. Security Considerations.......................................15
7. IANA Considerations...........................................16
8. Acknowledgements..............................................16
Normative References..............................................16
Informative References............................................16
Author's Address..................................................17
Disclaimer........................................................17
Full Copyright Statement..........................................17
Intellectual Property.............................................17
1. Introduction
The Simple Mail Transfer Protocol (SMTP) [RFC2821] provides the
ability for an SMTP client to specify multiple recipients for a
single email message [RFC2822], with the SMTP server using
individual response codes to indicate whether or not each of the
named recipients are acceptable to the server. Since this exchange
occurs before the actual message data is transferred, the server
responses are generally only useful for indicating whether or not
an SMTP server considers the recipient(s) acceptable for the
purpose of processing any email message that might ever be
transferred, and cannot be used to indicate the suitability of any
recipient(s) for a particular message (some exceptions to this
general principle exist, such as the SIZE extension defined in
RFC1870 [RFC1870], but those exceptions do not significantly change
the underlying SMTP model).
Separately, SMTP also provides a single response code for SMTP
servers to use after the actual message data has been transferred.
However, since SMTP is limited to a single response code for the
message data, that response code is generally only useful for
indicating whether or not a message is acceptable to the SMTP
Eric A. Hall Standards-Track [page 2]
Internet-Draft draft-hall-prdr-00.txt 2 April 2007
server itself, or to all or none of the recipients. More
specifically, a single response code is not sufficient for
indicating that a particular message is acceptable for some
recipients but not for others.
Over the last few years, however, it has become increasingly common
for different users to have different rules and filters for the
types of email messages that they will accept. For example, some
organizations have email policies that require specific types of
messages to be rejected outright (this is particularly common with
viruses and worms), but still require certain users to accept all
incoming messages regardless of content (this is often found with
administrative accounts such as "postmaster" and "abuse", but is
also common in some regulated industries).
In these types of environments, the use of a single response for
message data has been shown to be a significant limitation.
Furthermore, the historical solutions to this problem have also
proven to be somewhat inefficient. For example, servers that accept
all incoming messages and then generate failure notifications
after-the-fact for recipients who refused to accept the message
locally requires notification messages to be generated and
delivered to the listed sender of the original message (who may not
have been the actual sender), which imposes significant expense on
the email network as a whole. Meanwhile, some operators limit SMTP
transfers to a single recipient so that incoming messages can be
inspected on a per-recipient basis implicitly, although this
approach also introduces additional burden on the email network,
since it requires the SMTP clients and servers to perform multiple
transfers for messages that have multiple recipients.
In order to avoid these types of penalties, this memo describes an
SMTP service extension called Per-Recipient Data Responses (PRDR),
which enables SMTP servers to accept or refuse email messages on a
per-recipient basis during the transfer process, thereby allowing
message data to be accepted or rejected by each recipient while the
transfer session is still active.
Note that the mechanism described here is only applicable for SMTP
transfers, and does not apply to any kind of filtering that may
occur elsewhere. For example, some mail system operators perform
content inspection while writing incoming email messages into a
recipient's mail-store, while other operators rely on user agents
to filter and sort messages that have already been written to a
mail-store. In both of those cases, the incoming messages would
have already been accepted by an SMTP server, so it would be too
late for the mechanism described here to be called upon.
Eric A. Hall Standards-Track [page 3]
Internet-Draft draft-hall-prdr-00.txt 2 April 2007
Furthermore, this mechanism depends on bilateral agreement between
the participants of an SMTP session, and there will be many SMTP
senders who choose not to employ it for one reason or another. As
such, implementers and operators may find that they still need to
rely on historical mechanisms in many situations.
2. Prerequisites
Readers of this document are expected to be familiar with the
specifications for SMTP ([RFC2821]), 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" are to
be interpreted as they are described in [BCP14].
3. Functional Overview
Essentially, the PRDR extension to SMTP allows (but does not
require) an SMTP server to issue multiple responses after a message
has been transferred, by mutual consent of the client and server.
SMTP clients that support the PRDR extension then use the expanded
responses as supplemental data to the responses that were received
during the earlier envelope exchange.
More specifically, the PRDR extension consists of the following
major elements:
o SMTP servers indicate that they support the PRDR extension by
providing a "PRDR" keyword in their EHLO response.
o SMTP clients indicate that they are willing to use the PRDR
extension by providing a "PRDR" parameter to the MAIL FROM
command during the SMTP envelope exchange.
o SMTP clients enumerate the message recipients with the RCPT TO
command as normal; no additional parameters to the RCPT TO
command are needed by the PRDR extension. SMTP servers also
generate response codes to each RCPT TO command as normal; no
modifications to the RCPT TO responses are needed by the PRDR
extension.
o Any recipient that is acknowledged by the server with a
positive response code (2xx) during the envelope exchange will
be eligible for per-recipient responses after the associated
message data is subsequently transferred. Because of this, the
SMTP client and server must each temporarily store any such
recipients until after the SMTP server issues responses for the
message data.
Eric A. Hall Standards-Track [page 4]
Internet-Draft draft-hall-prdr-00.txt 2 April 2007
o SMTP clients transfer the message body as normal, using any of
the standardized mechanisms available. When the message data
has been completely transferred, the SMTP server can inspect
the message data and begin the process of indicating whether or
not it is acceptable for each of the recipients.
o If the SMTP server knows that it will generate the same
response for all of the named recipients, it can use the
traditional (single) response syntax, thereby avoiding the need
to enumerate all of the recipients individually.
o If the SMTP server needs to enumerate discrete responses for
each recipient, it transmits a response block containing the
following discrete elements, each on a separate line:
a) The server transmits a response line beginning with "353",
thereby informing the client that the server is using the
full PRDR response format.
b) The server then transmits discrete response lines for each
recipient that was positively acknowledged during the
envelope exchange, indicating whether or not the server
considers the message to be acceptable for each respective
recipient. Separate responses are sent for each of the
recipients, in the same order as they were provided in the
envelope exchange.
The SMTP client creates a temporary mapping between these
response codes and the recipients that were positively
acknowledged during the envelope exchange, but does not act
on the information until the entire response block is
successfully received.
c) Once the recipient-specific responses have been
transmitted, the server transmits a final response. The
final response serves the same purpose as the traditional
end-of-data response, and indicates whether or not the
server will accept the message for processing.
After the SMTP client receives the final response line, it
can begin the process of determining which recipients were
accepted or rejected, and react accordingly.
The remainder of this document describes these operating principles
in more detail.
4. The PRDR Extension to SMTP
The PRDR extension to SMTP is defined as follows:
Eric A. Hall Standards-Track [page 5]
Internet-Draft draft-hall-prdr-00.txt 2 April 2007
a) the full name of the extension is "Per-Recipient Data
Responses", abbreviated as "PRDR";
b) the EHLO keyword value associated with the extension is "PRDR";
c) the PRDR extension to EHLO has no parameters or values;
d) the MAIL FROM command is extended with the optional "PRDR"
parameter;
e) the PRDR parameter to the MAIL FROM command has no additional
parameters or values;
f) the length of the MAIL FROM command is extended by five octets
to account for the PRDR parameter and whitespace;
g) no additional commands are extended;
h) no new verbs are defined;
i) the 353 response code is defined for use when the PRDR
extension has been activated; and
j) no additional response codes are defined.
SMTP end-points that implement the PRDR service extension MUST also
implement command pipelining as defined in STD 60 [STD60], and
extended status codes as defined in RFC 2034 [RFC2034].
The remainder of this section defines how the PRDR extension is to
be implemented, and how the extension affects SMTP clients and
servers that implement it.
4.1. The PRDR EHLO Keyword
The presence of the PRDR keyword in the EHLO greeting response
indicates that an SMTP server supports this extension. SMTP
servers that wish to use this extension MUST provide the PRDR
keyword in response to the EHLO command, using the response
format described in [RFC2821].
4.2. The PRDR Extension to the MAIL FROM Command
An SMTP client informs an SMTP server that it supports the PRDR
extension by specifying "PRDR" as a parameter to the MAIL FROM
command. SMTP clients MUST NOT specify this command parameter
unless the SMTP server has already advertised support for the
PRDR extension in the EHLO response as described above.
Eric A. Hall Standards-Track [page 6]
Internet-Draft draft-hall-prdr-00.txt 2 April 2007
SMTP servers respond to the MAIL FROM command using the syntax
and response codes defined in [RFC2821] or relevant SMTP
extension. No new MAIL FROM response codes are defined for use
with PRDR.
4.3. RCPT TO Commands and Responses
No new parameters are defined for the RCPT TO command, nor are
any new response codes defined for these commands. However, there
are some protocol considerations associated with these commands
and their associated responses.
In particular, every message recipient that is identified in a
RCPT TO command and is acknowledged by the SMTP server with a
positive response code (2xx) is automatically eligible for per-
recipient responses after the message data is subsequently
transferred. In order to ensure that these recipients are
properly acknowledged at the appropriate time, SMTP clients and
servers MUST create temporary lists of any such recipients, and
SMTP servers MUST also record the response codes that are sent
for each of those recipients. Both end-points MUST maintain their
individual lists until the message data is subsequently
acknowledged, as described in section 4.4.
Only those recipients that receive positive responses to their
associated RCPT TO commands are to be tracked in this manner; any
recipient that receives any other class of response code to their
associated RCPT TO commands MUST NOT be included in these lists.
4.4. Message Data Commands and Responses
No new commands are defined for transferring message data. SMTP
clients and servers may use any means available to them for
achieving this purpose.
Upon the successful completion of the transfer, however, SMTP
servers can use one of the following two methods to indicate
whether or not the message data is acceptable to the server
and/or any of the recipients who were previously acknowledged
with a positive response code:
o SMTP servers MAY use a single (traditional) response line to
indicate whether or not the message is acceptable, as per the
syntax rules associated with each of the transfer methods.
This method is generally more efficient and its usage is
encouraged when suitable and appropriate.
o SMTP servers MAY use the expanded response format described
in section 4.5 to indicate whether or not the message is
acceptable to each of the message recipients. This method is
Eric A. Hall Standards-Track [page 7]
Internet-Draft draft-hall-prdr-00.txt 2 April 2007
generally only needed when two or more recipients have
different rules or policies, or when a server is otherwise
unable to consolidate the recipient responses.
The response model that is used is solely at the discretion of
the SMTP server.
SMTP end-points that claim to implement this specification MUST
support both response models.
4.5. The Per-Recipient Data Response Block
When a server needs to return per-recipient responses, it MUST
use the exact response model described in this section.
SMTP servers MUST NOT use this response syntax unless the client
has indicated that it supports the PRDR extension, as described
in section 4.2.
4.5.1. The 353 Response
SMTP servers indicate that they are using the PRDR response
syntax by issuing a single response line that begins with the
exact character sequence of "353". Additional string data MAY
be provided on the response line if needed, as per the syntax
rules defined in [RFC2821].
No enhanced status codes are currently defined for use with
this response line, and enhanced status codes MUST NOT be used
with this response line, unless one is specifically defined for
use by a subsequent specification.
SMTP clients which receive the 353 response code after the
message data MUST be prepared to receive recipient-specific
responses for each of the recipients who had received positive
responses to their associated RCPT TO commands.
SMTP servers SHOULD transmit the 353 response as quickly as
possible, so that the SMTP client can detect it quickly.
SMTP clients MUST wait at least 10 minutes for the 353
response, in conformance with the timeout values specified in
[RFC2821]. Due to the increased risk of timeouts that can
appear from server-side content analysis, this is REQUIRED from
all SMTP clients that implement this extension.
4.5.2. The Per-Recipient Responses
After the 353 response line has been sent, SMTP servers
transmit individual response lines for each of the recipients
Eric A. Hall Standards-Track [page 8]
Internet-Draft draft-hall-prdr-00.txt 2 April 2007
who had earlier received positive responses to their associated
RCPT TO commands. The per-recipient responses MUST be returned
in the same sequence that the original recipients were
identified in the associated RCPT TO commands, MUST include one
response for every recipient that received a positive response
to an associated RCPT TO command, and MUST NOT include
responses for any recipients that did not receive a positive
response to the associated RCPT TO command.
The individual response lines signify whether or not the server
believes that the message is acceptable for each individual
recipient. Note that these responses do not indicate that the
server has accepted responsibility for getting the message to
each recipient, but instead only indicate whether or not the
server would be willing to process the message for each
recipient if it subsequently accepts that responsibility in the
final response. Furthermore, positive responses are not a
guarantee that any subsequent transfer or delivery operations
will also succeed, but instead only indicate that the message
appears to be acceptable for the recipient according to the
rules and policies that are known to the current server.
The individual response lines MUST use the syntax rules
described in [RFC2821], and SHOULD use the enhanced status
codes described in [RFC2034].
If the server determines that the message is acceptable for a
particular recipient, it SHOULD reuse the exact same response
code that was used to positively acknowledge the recipient for
the associated RCPT TO command. The only allowable exception to
this rule is when a more-explicit response becomes available as
a result of examining the message.
For example, if the server determines that a recipient's email
address is actually an alias for another email address, the
server MAY replace a previously-issued "250" generic response
with a more-explicit "251" response, but the reverse transition
MUST NOT occur. In general, servers should minimize disruption
to clients, and SHOULD only change response code when those
changes are significant.
If the server determines that the message is unacceptable for a
particular recipient for some reason, it MUST use a response
code that is valid and appropriate for the RCPT TO command to
signify the problem condition. The appropriate response code to
be used will depend on the error condition, and is left to the
implementer to decide, but generally speaking the response code
ought to reflect the leading problem that is preventing the
recipient from accepting the message.
Eric A. Hall Standards-Track [page 9]
Internet-Draft draft-hall-prdr-00.txt 2 April 2007
For example, [RFC2821] defines the "550" response code for use
when a policy violation is preventing a recipient from
receiving a message, and that is an appropriate response code
to use when a content filter is causing the message to be
rejected. Similarly, [RFC1870] defines the "452" and "552"
response codes to indicate that the message is too large
(either temporarily or permanently), and those would be
appropriate response codes if the same situation were to become
apparent while the server was the processing the message.
If the server is unable to analyze the message for a recipient
due to a lack of resources on the server itself, the server
MUST use the "452" response code defined in [RFC2821] for each
affected recipient. If the server encounters a fatal error that
requires immediate shutdown, the server SHOULD attempt to
transmit the entire response sequence before closing the
session.
SMTP servers MUST NOT begin processing the message until they
have successfully generated the final response code described
in the following section.
SMTP clients MUST record each of the response lines as they are
received, and MUST replace the RCPT TO responses that were
received earlier with the response that are received here. SMTP
clients MUST NOT act on these responses until the final
response is received, as described in the following section.
SMTP clients MUST wait at least 10 minutes for each of the per-
recipient responses, in conformance with the timeout values
specified in [RFC2821]. Due to the increased risk of timeouts
that can appear from server-side content analysis, this is
REQUIRED from all SMTP clients that implement this extension.
4.5.3. The Final Response Code
After the server has transmitted all of the recipient-specific
response lines, a final response that indicates whether or not
the server will accept responsibility for the email message as
a whole MUST be returned.
As a general rule, if the server has indicated that it believes
an email message is acceptable for any of the recipients, and
if the server is able to accept the message as a whole, then it
SHOULD return a positive final response. However, if the server
has refused to accept the message for all of the recipients, or
if the server is unable to accept the message as a whole (for
whatever reason), then it MUST return an appropriate negative
response code in the final response.
Eric A. Hall Standards-Track [page 10]
Internet-Draft draft-hall-prdr-00.txt 2 April 2007
If an SMTP server issues a positive final response code, it
accepts responsibility for moving the message towards the
acknowledged recipients, and causes the SMTP client to release
the message from its queue. At this point, the end-point
systems can begin to take any post-transfer actions that may be
needed (see the discussion in section 0). Until a positive
final reply code is issued, however, the SMTP client MUST
retain ownership and responsibility for the email message.
In those cases where a temporary condition is causing the
server to reject the message, then an appropriate temporary
failure response code (4xx) MUST be used in the final response.
For example, if a shortage of disk space causes the server to
refuse to accept the message (regardless of any per-recipient
responses that may have already been sent) then the final
response code would need to indicate that error condition.
Similarly, if all of the recipients had rejected the message
due to individual quota shortages that were discovered as part
of the content inspection routines, then the server MUST use a
final response code that reflects the temporary nature of the
failure condition.
Note that it is entirely possible for a server to positively
acknowledge all of the message recipients, yet still return a
failure in the final response. For example, the server may have
had a disk disappear before it could write the message to local
storage. As such, SMTP clients MUST wait for the final
response, or wait for a timeout condition to be triggered,
before proceeding with any post-transfer cleanup.
SMTP clients MUST treat the final response as a normal response
to the data transfer process, and react appropriately. For
example, if a server issues a 250 final response code, then the
server has agreed to accept responsibility for the message, and
the client needs to release ownership of the message and clear
it from the outbound queue. Similarly, if a server issues a 550
final response code, then the transfer has failed and the SMTP
client is still considered the owner of the message.
SMTP clients MUST wait at least 10 minutes for the final
response, in conformance with the timeout values specified in
[RFC2821]. Due to the increased risk of timeouts that can
appear from server-side content analysis, this is REQUIRED from
all SMTP clients that implement this extension.
4.6. Post-Transfer Processing
Once an SMTP server has sent all of the needed response lines
(whether this is a single traditional response or the block of
Eric A. Hall Standards-Track [page 11]
Internet-Draft draft-hall-prdr-00.txt 2 April 2007
PRDR responses described in section 4.5), the SMTP client can
begin to perform post-transfer cleanup that may be needed, such
as generating disposition or error messages, requeuing messages
for retry later, and so forth.
For these types of purposes, SMTP clients MUST treat per-
recipient responses as if they had been received in response to
the original RCPT TO commands, and MUST treat a final response
line as if it were a traditional response to the message data.
Furthermore, SMTP clients MUST give priority to the final
response for the purpose of generating any notification or
errors, and MUST NOT generate notifications or errors for
individual recipients unless those recipients received a
different outcome from the final response. These principles
ensure that the fewest number of notifications are generated, and
is therefore REQUIRED.
For example, if a server issued a final response indicating that
it refused to accept a message in general (regardless of any
recipient-specific responses), then the SMTP client MUST use that
final response code when generating notification or error
messages, and MUST NOT generate per-recipient notifications or
errors.
If a server has generated a positive final response, but has
refused to accept the message for one or more individual
recipients, the SMTP client MUST use the final response for any
positive notifications that may have been requested.
If the SMTP server indicates that the message is being
temporarily refused for some of the recipients, then the SMTP
client MUST requeue the message for later retransmission to the
affected recipients (and only those recipients), as appropriate.
SMTP clients MAY consolidate failed recipients into failure
notification messages, but MUST preserve the individual response
codes in any such consolidation. For example, if some recipients
were unable to accept a message due to quota problems, but other
recipients were unable to accept that same message due to policy,
the SMTP client MUST NOT consolidate all of these recipients into
a single failure notification.
In all these cases, the appropriate course of action should
follow from the principle that SMTP clients are expected to treat
the per-recipient responses as if they had been received in
response to the RCPT TO commands, while treating the final
response code as if it was the only response to the message data.
Eric A. Hall Standards-Track [page 12]
Internet-Draft draft-hall-prdr-00.txt 2 April 2007
4.7. Failure and Timing Considerations
There are a handful of scenarios where an SMTP client may be
unable to read the complete set of responses from the SMTP
server, resulting in some confusion as to which system actually
owns the message, potentially resulting in duplicate or lost
messages in some situations.
This problem is known to exist with SMTP in general (and is
discussed in that context in RFC 1047 [RFC1047]), but this
problem can be substantially exacerbated by the use of the PRDR
extension. For one, an SMTP server may take an unexpectedly long
time to analyze a message within the context of each individual
recipient, which may result in more timeouts with problematic
clients, or within the network itself. Meanwhile, the use of very
large PRDR response blocks also exposes SMTP sessions to randomly
dropped connections as a side effect of their longer lifetimes.
In order to avoid these types of problems to the extent that is
possible, clients and servers MUST strictly comply with the
timeout values defined in this standard. Furthermore, SMTP
clients and servers that implement this specification MUST use
command pipelining to ensure that the response data can be
transmitted from the server to the client as quickly as possible.
If there is cause for belief that the client is no longer
connected, SMTP servers SHOULD issue temporary failure response
codes for any outstanding replies that are needed, and then close
the connection.
SMTP servers are also strongly encouraged to use traditional
single responses wherever possible, as this can significantly
reduce the potential for timeout-related failures. For example,
if a server receives an email message with a virus that is
addressed to a thousand recipients who are all known to refuse
such content, a single negative response would be much more
efficient than having the server iterate through all of the
recipients, since the latter approach is an unnecessary waste of
computing and network resources with the potential to trigger
timing-related problems.
SMTP clients that frequently have timeout related problems with a
specific server are also generally encouraged to make note of
that fact, and to avoid using the PRDR extension with subsequent
transfers to that server.
Eric A. Hall Standards-Track [page 13]
Internet-Draft draft-hall-prdr-00.txt 2 April 2007
5. Usage Examples
This section contains examples which are only intended to serve as
illustration. Refer to the preceding sections for the actual
conformance requirements.
5.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> PRDR
S: 250 2.1.0 you look okay, PRDR enabled
C: RCPT TO:<fighter@example.net>
S: 250 2.1.5 that recipient is known to me
C: RCPT TO:<lover@example.net>
S: 250 2.1.5 that recipient is known to me
C: DATA
S: 354 go ahead
C: <sends data>
C: <crlf>.<crlf>
S: 353 content analysis has started
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
Since the message was acceptable to one of the recipients, and
since the server is able to accept the message for subsequent
processing, the final response indicates success. At this point,
the SMTP client would need to clear the message from its queue,
and then generate a disposition or error message on behalf of the
failing recipient.
5.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):
Eric A. Hall Standards-Track [page 14]
Internet-Draft draft-hall-prdr-00.txt 2 April 2007
C: MAIL FROM:<sender@example.com> PRDR
S: 250 2.1.0 you look okay, PRDR enabled
C: RCPT TO:<fighter@example.net>
S: 250 2.1.5 that recipient is known to me
C: RCPT TO:<lover@example.net>
S: 250 2.1.5 that recipient is known to me
C: DATA
S: 354 go ahead
C: <sends data>
C: <crlf>.<crlf>
S: 550 5.6.0 message unacceptable due to local policy
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.
6. Security Considerations
SMTP servers that perform content inspection on incoming messages
expose themselves to certain types of resource-consumption attacks.
For example, a hostile client can generate complex messages with
multiple recipients and send them to a server that has advertised
PRDR capabilities, with the intention of tying up the server's
computing resources.
These kinds of attacks can be mitigated with multiple techniques.
For starters, SMTP server developers and operators should give due
consideration to the placement of content inspection technologies,
and try to use them appropriately. For example, some types of
content inspection can be efficiently implemented at the server
level, while others may require implementation on a per-user basis
in order to work correctly. To the extent that a global filtering
process can detect such attacks before the server examines the
message in the context of each recipient, it is possible to reject
these messages with a single traditional response, thereby
eliminating the need to perform per-recipient analysis.
It is also possible for SMTP servers to limit the number of
recipients that are allowed for any given message when the PRDR
extension is enabled, which provides a certain amount of
computational throttling. Since the client requests the extension
by specifying the PRDR keyword as part of the MAIL FROM command,
which happens before the RCPT TO command can be called, it is
possible for servers to limit the number of recipients that are
allowed when the PRDR extension has been explicitly requested.
On a more general note, effective server management is ultimately
the responsibility of the server operator. Many organizations have
been doing content inspection in SMTP for several years, and most
Eric A. Hall Standards-Track [page 15]
Internet-Draft draft-hall-prdr-00.txt 2 April 2007
of them have had to face challenges with effective load management
during that time period. Usually this involves tradeoffs, such as
disabling or moving CPU-intensive inspection routines to other
parts of the delivery process, but sometimes requires additional
investments in computing resources in order to meet the minimum
levels of demand. Organizations that choose to use the PRDR
extension on their mail servers will likely face these same
challenges, and it is ultimately their responsibility to ensure
that their servers are capable of handling the load.
7. IANA Considerations
IANA is expected to record relevant information about the PRDR
extension in their online catalog of SMTP extensions.
8. Acknowledgements
Significant feedback and editorial contributions to this
specification were contributed by Claus Assmann, Tony Finch, and
Peter Holzer. The author would also like to express appreciation to
the ietf-smtp working group mailing list in general.
Funding for the RFC editor function is currently provided by the
Internet Society.
Normative References
[BCP14] 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.
Informative References
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[RFC1870] Klensin, J., et al, "SMTP Service Extension for Message
Size Declaration", RFC 1870, November 1995.
[RFC1047] Partridge, C., "DUPLICATE MESSAGES AND SMTP", RFC 1047,
February 1988.
Eric A. Hall Standards-Track [page 16]
Internet-Draft draft-hall-prdr-00.txt 2 April 2007
Author's Address
Eric A. Hall
ehall@ntrg.com
Disclaimer
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.
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Eric A. Hall Standards-Track [page 17]
Internet-Draft draft-hall-prdr-00.txt 2 April 2007
Information on the ISOC's procedures with respect to rights in ISOC
Documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Eric A. Hall Standards-Track [page 18]
