Oracle

ned.freed@mrochek.com

Art Internet-Draft This document defines a “Limits” extension for the Simple Mail Transfer Protocol (SMTP), including submisssion, as well as the Local Mail Transfer Protocol (LMTP). It also defines an associated limit registry. This extension provides the means for an SMTP, submission, or LMTP server to inform the client of limits the server intends to apply to the protocol during the current session. The client is then able to adapt its behavior in order to conform to those limits.

The Simple Mail Transfer Protocol provides the ability to transfer or submit multiple email messages from one host to another, each with multiple recipients, using a single or multiple connections. The Local Mail Transfer Protocol provides the ability to deliver messages to a system without its own mail queues. Like SMTP, it allows multiple messages with multiple recipients. In order to conserve resources as well as protect themselves from malicious clients, it is necessary for servers to enforce limits on various aspects of the protocol, e.g., a limit on the number of recipients that can be specified in a single transaction. Additionally, servers may also wish to alter the limits they apply depending on their assessment of the reputation of a particular client. The variability of the limits that may be in effect creates a situation where clients may inadvertently exceed a particular server’s limits, causing servers to respond with temporary (or in some cases, permanent) errors. This in turn can lead to delays or even failures in message transfer. The “Limits” extension provides the means for a server to inform a client about specific limits in effect for a particular SMTP or LMTP session in the EHLO or LHLO command response. This information, combined with the inherent flexibility of these protocols, makes it possible for clients to avoid server errors and the problems they cause. SMTP and LMTP servers have always been able to announce a limit using distinguished syntax in a reply, but this approach requires that the client first needs to issue a command. The mechanism specified here avoids the overhead of that approach by announcing limits prior to any substantive interaction. Limits are registered with the IANA. Each registration includes the limit name, value syntax, and a description of its semantics.

In this document, the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in BCP 14, RFC 2119 . This specification uses the Augmented Backus-Naur Form notation and its core rules to define the formal syntax of the “Limits” extension. This specification makes extensive use of the terminology specified and used in .

Extensions to SMTP are defined in Section 2.2 of . inherits SMTP’s extension mechanism. The name of the extension is “Limits”. Servers implementing this extension advertise an additional “LIMITS” EHLO (LHLO in LMTP) keyword. The associated parameter is used by the server to communicate one or more limits, each with an optional value, to the client. The syntax of the parameter is:

This extension introduces no new SMTP commands, and does not alter any existing command. However, it is possible for a LIMITS parameter to be associated with another SMTP extension that does these things.

In order to achieve consistent behavior, all limits MUST be registered with the IANA, as described below.

Limit names MUST be comprehensible, but also should be kept as short as possible. The use of commonly understood abbreviations, e.g., “MAX” for “maximum”, is encouraged. When a limit is associated with a particular command, its name SHOULD begin with the name of that command. Limit names SHOULD end with one or more terms that describe the type of limit.

The “Pipelining” extension is commonly used to improve performance, especially over high latency connections. Pipelining allows entire transaction to be sent without checking responses and in some cases it may be possible to send multiple transactions. The use of pipelining affects limits in an important way: Since a pipelining client cannot check intermediate command responses without stalling the pipeline, it cannot count the number of succesful versus failed responses and adjust its behavior accordingly. Limit designers need to take this into account. For example, it may seem like it would be better to impose a limit on the number of succesful RCPT TO commands as opposed to the way the RCPTMAX limit is specified in below. But counting the total number of RCPT TOs is simple, whereas counting the number of successful RCPT TO stalls the pipeline.

This extension provides an announcement as part of the reply to an EHLO command. Some servers vary their limits, as a session progresses, based on their obtaining more information. This extension does not attempt to handle in-session limit changes.

Section 4.5.3.1 of specifies minimum values for various server sizes, limits, and timeouts, e.g., servers must accept a minimum of 100 RCPT TO commands (section 4.5.3.1.8). Unfortunately, the reality is that servers routinely impose smaller limits than what SMTP requires, and when this is done it’s especially important for clients to be aware that this is happening. For this reason there is no requirement that the limits advertised by this extension comply with the minimums imposed by SMTP.

These protocols require that the EHLO command (LHLO in LMTP) be reissued under certain circumstances, e.g., after successful authentication or negotiation of a security layer . Servers MAY return updated limits any time the protocol requires clients to reissue the EHLO command. Clients MUST discard any previous limits in favor of those provided by the most recent EHLO. This includes the case where the original EHLO provided a set of limits but the subsequent EHLO did not; in this case the client MUST act as if no limits were communicated.

Syntax errors in the basic parameter syntax are best handled by ignoring the value in its entirety; in this case clients SHOULD proceed as if the LIMITS extension wasn’t used. Syntax errors in the value syntax of a specific limit are best handled by ignoring that limit; in this case the client SHOULD proceed as if that limit wasn’t specified. It is possible that future specification may create multiple limits that are interrelated in some way; in this case that specification MUST specify how an error in one limit’s value syntax affects the other limits.

Clients MAY cache limits determined during one session and use them to optimize their behavior for subsequent sessions. However, since servers are free to adjust their limits at any time, clients MUST be able to accommodate any limit changes that occur between sessions.

An initial set of limits are specified in the following sections.

Name: MAILMAX Value syntax: %x31-39 0*5DIGIT ; 0 not allowed, 6 digit maximum Description: MAILMAX specifies the maximum number of transactions (MAIL FROM commands) the server will accept in a single session. The count includes all MAIL FROM commands, regardless of whether they succeed or fail. Restrictions: None. Security Considerations: See

Name: RCPTMAX Value syntax: %x31-39 0*5DIGIT ; 0 not allowed, 6 digit maximum Description: RCPTMAX specifies the maximum number of RCPT TO commands the server will accept in a single transaction. It is not a limit on the actual number of recipients the message ends up being sent to; a single RCPT TO command may produce multiple recipients or, in the event of an error, none. Restrictions: None. Security Considerations: See

Name: RCPTDOMAINMAX Value syntax: %x31-39 0*5DIGIT ; 0 not allowed, 6 digit maximum Description: RCPTDOMAINMAX specifies the maximum number of different domains that can appear in a recipient (RCPT TO) address within a single session. This limit is imposed by some servers that bind to a specific internal delivery mechanism on receipt of the first RCPT TO command. Restrictions: None. Security Considerations: See

A server announces two limits it implements to the client, along with various other supported extensions, as follows:

The client now knows to limit the number of recipients in a transaction to twenty and the number of transaction in a session to five.

A malicious server can use limits to overly constrain client behavior, causing excessive use of client resources. A malicious client may use the limits a server advertises to optimize the delivery of unwanted messages. A man-in-the-middle attack on unprotected SMTP connections can be used to cause clients to misbehave, which in turn could result in delivery delays or failures. Loss of reputation for the client could also occur. All that said, decades of operational experience with the SMTP “SIZE” extension , which provides servers with the ability to indicate message size, indicates that such abuse is rare and unlikely to be a significant problem. Use of the Limits extension to provide client-specific information - as opposed to general server limits - unavoidably provides senders with feedback about their reputation. Malicious senders can exploit this in various ways, e.g., start by sending good email and then, once their reputation is established, sending bad email.

The IANA is requested to add “LIMITS” to the SMTP Service Extension Registry:

The IANA is requested to create a new registry for SMTP server limits. The policy for this registry is “Specification Required”. Registry entries consist of three required values: The name of the limit The syntax of the limit value, if the limit has one. Use of is preferred but not required. A description of the limit’s semantics Restrictions, if any, on the use of the limit. If the limit is specific to any of SMTP, message submission, or LMTP, it should be documented here. Security considerations for the limit The IANA is also requested to register the limits specified in this document.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service whereby a server can indicate the extent of its ability to accept multiple commands in a single Transmission Control Protocol (TCP) send operation. [STANDARDS-TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK] SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a mechanism for transferring mail reliably and efficiently. The design of the SMTP protocol effectively requires the server to manage a mail delivery queue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK] This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP.This document obsoletes RFC 2554. [STANDARDS-TRACK] This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.Message relay is unaffected, and continues to use SMTP over port 25.When conforming to this document, message submission uses the protocol specified here, normally over port 587.This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK]

A lot of people have helped make this specification possible. The author wishes to thank Claus Assmann, Laura Atkins, Alex Brotman, Richard Clayton, Dave Crocker, Viktor Dukhovni, Arnt Gulbrandsen, Jeremy Harris, Todd Herr, Mike Hillyer, Matthias Leisi, John Klensin, Valdis Klētnieks, John Levine, Alexey Melnikov, Keith Moore, Michael Peddemors, Hector Santos, George Schlossnagle, Rolf E. Sonneveld, and Alessandro Vesely for their contributions and reviews.