The LIMITS SMTP Service Extension
Extracted elements (22)
RCPTMAX is defined as a limit on total RCPT TO commands rather than successful ones because counting total commands is simple, whereas counting only successful ones requires stalling the pipeline to check intermediate responses.
The LIMITS extension announces server limits in the EHLO response rather than waiting for a command to fail, avoiding the overhead and delays caused by servers issuing error responses after clients have already exceeded a limit.
The LIMITS extension does not attempt to handle in-session limit changes. Limits are announced once at EHLO and servers may vary limits only between sessions, not as a session progresses.
There is no requirement that limits advertised by the LIMITS extension comply with SMTP-mandated minimums (e.g., RFC 5321's minimum of 100 RCPT TO commands), because servers routinely impose smaller limits and it is especially important for clients to be aware of this.
When pipelining is in use, a client cannot check intermediate command responses without stalling the pipeline, so it cannot count successful versus failed responses to adjust behavior. Limit designers must account for this; for example, RCPTMAX counts total RCPT TO commands rather than only successful ones.
A future specification that defines interrelated limits MUST specify how a syntax error in one limit's value affects the other related limits.
All limits MUST be registered with the IANA in order to achieve consistent behavior.
Clients MAY cache limit settings from a prior session for use in subsequent sessions to the same server. However, clients MUST be able to accommodate any limit changes that occur between sessions, since servers may adjust limits at any time.
Limit names MUST be comprehensible. When a limit is associated with a particular command, its name SHOULD begin with the name of that command, and SHOULD end with one or more terms describing the type of limit.
Servers MAY return updated limits any time the protocol requires clients to reissue the EHLO command (e.g., after AUTH or STARTTLS). Clients MUST discard any previous limits in favor of those from the most recent EHLO, including the case where the new EHLO provides no limits at all.
Syntax errors in the overall LIMITS parameter value should cause the client to ignore the value entirely and SHOULD proceed as if the LIMITS extension had not been used. Syntax or other errors in an individual limit's value MUST cause the client to proceed as if that specific limit had not been specified.
MAILMAX specifies the maximum number of MAIL FROM transactions the server will accept in a single session. The count includes all MAIL FROM commands regardless of success or failure. Value syntax is a non-zero integer up to six digits.
RCPTDOMAINMAX specifies the maximum number of different domains that can appear in recipient addresses within a single session. This accommodates servers that bind to a specific internal delivery mechanism on receipt of the first RCPT TO. Value syntax is a non-zero integer up to six digits.
RCPTMAX specifies the maximum number of RCPT TO commands the server will accept in a single transaction (not the actual number of recipients delivered to). Value syntax is a non-zero integer up to six digits.
The LIMITS SMTP extension is announced in the EHLO (or LHLO for LMTP) response as a keyword with an associated parameter. The parameter communicates one or more named limits, each with an optional value, to the client at session start.
A new "SMTP Server Limits" registry has been created under the MAIL Parameters group with policy "Specification Required". Each entry must include: limit name, value syntax, semantic description, usage restrictions, and security considerations. Initial registrations are MAILMAX, RCPTMAX, and RCPTDOMAINMAX.
The IANA SMTP Service Extensions registry has been updated to add the "LIMITS" keyword with description "Server limits" referencing RFC 9422, with a note pointing to the new SMTP Server Limits registry.
A malicious client can use server-advertised limits to optimize delivery of unwanted messages (spam), precisely tuning message volume to avoid triggering rejections.
A malicious server can advertise overly restrictive limits to constrain client behavior and cause excessive consumption of client resources.
A man-in-the-middle attack on an unprotected SMTP connection can manipulate the LIMITS advertisement, causing clients to misbehave in ways that result in delivery delays, failures, or reputational damage.
When a server provides client-specific limit values rather than general server-wide limits, it unavoidably leaks reputation information to the sender. Malicious senders can exploit this to build reputation before switching to abusive behavior.
The LIMITS EHLO parameter syntax is: limits-param = limit-name-value 0*[SP limit-name-value]; limit-name-value = limit-name ["=" limit-value]; limit-name = 1*(ALPHA / DIGIT / "-" / "_"); limit-value = 1*(%x21-3A / %x3C-7E). Limit values are ASCII VCHARs excluding semicolons.