INTERNET-DRAFT Eric A. Hall draft-hall-prdr-00.txt 5 March 2007 Category: Standards Track Expires: September 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 a "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 5 March 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...........................6 4.4. Message Data Commands and Responses......................7 4.5. The Per-Recipient Data Response Block....................7 4.6. Post-Transfer Processing................................11 4.7. Failure and Timing Considerations.......................12 5. Usage Examples................................................13 5.1. One Failure, One Success................................13 5.2. Total Failure...........................................14 6. Security Considerations.......................................14 7. IANA Considerations...........................................15 8. Acknowledgements..............................................15 Normative References..............................................15 Informative References............................................16 Author's Address..................................................16 Full Copyright Statement..........................................16 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 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. Eric A. Hall Standards-Track [page 2] Internet-Draft draft-hall-prdr-00.txt 5 March 2007 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. 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. Eric A. Hall Standards-Track [page 3] Internet-Draft draft-hall-prdr-00.txt 5 March 2007 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. 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 Eric A. Hall Standards-Track [page 4] Internet-Draft draft-hall-prdr-00.txt 5 March 2007 (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: 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; Eric A. Hall Standards-Track [page 5] Internet-Draft draft-hall-prdr-00.txt 5 March 2007 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. 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. Eric A. Hall Standards-Track [page 6] Internet-Draft draft-hall-prdr-00.txt 5 March 2007 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 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. Eric A. Hall Standards-Track [page 7] Internet-Draft draft-hall-prdr-00.txt 5 March 2007 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 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 Eric A. Hall Standards-Track [page 8] Internet-Draft draft-hall-prdr-00.txt 5 March 2007 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. 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. Eric A. Hall Standards-Track [page 9] Internet-Draft draft-hall-prdr-00.txt 5 March 2007 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. 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 Eric A. Hall Standards-Track [page 10] Internet-Draft draft-hall-prdr-00.txt 5 March 2007 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 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. Eric A. Hall Standards-Track [page 11] Internet-Draft draft-hall-prdr-00.txt 5 March 2007 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. 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. Eric A. Hall Standards-Track [page 12] Internet-Draft draft-hall-prdr-00.txt 5 March 2007 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. 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: C: 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: PRDR S: 250 2.1.0 you look okay, PRDR enabled C: RCPT TO: S: 250 2.1.5 that recipient is known to me C: RCPT TO: S: 250 2.1.5 that recipient is known to me C: DATA S: 354 go ahead C: C: . Eric A. Hall Standards-Track [page 13] Internet-Draft draft-hall-prdr-00.txt 5 March 2007 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): C: MAIL FROM: PRDR S: 250 2.1.0 you look okay, PRDR enabled C: RCPT TO: S: 250 2.1.5 that recipient is known to me C: RCPT TO: S: 250 2.1.5 that recipient is known to me C: DATA S: 354 go ahead C: C: . 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 Eric A. Hall Standards-Track [page 14] Internet-Draft draft-hall-prdr-00.txt 5 March 2007 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 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. Eric A. Hall Standards-Track [page 15] Internet-Draft draft-hall-prdr-00.txt 5 March 2007 [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. Author's Address Eric A. Hall ehall@ntrg.com Full Copyright Statement Copyright (C) The Internet Society (2007). All Rights Reserved. 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. 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 Eric A. Hall Standards-Track [page 16] Internet-Draft draft-hall-prdr-00.txt 5 March 2007 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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. 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 17]