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

Versions: 00

   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]
   

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