The LIMITS SMTP Service Extension
draft-freed-smtp-limits-01

Document Type Active Internet-Draft (individual)
Author Ned Freed 
Last updated 2021-03-15
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           N. Freed
Internet-Draft                                                    Oracle
Intended status: Standards Track                          March 15, 2021
Expires: September 16, 2021

                   The LIMITS SMTP Service Extension
                       draft-freed-smtp-limits-01

Abstract

   This document defines a "Limits" extension for the Simple Mail
   Transfer Protocol (SMTP) and an associated limit registry.  This
   extension provides the means for an SMTP server to inform the SMTP
   client of limits the server intends to apply to the protocol during
   the current SMTP session.  The client is then able adapt its behavior
   in order to conform to those limits.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on September 16, 2021.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Freed                  Expires September 16, 2021               [Page 1]
Internet-Draft              LIMITS Extension                  March 2021

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   The Simple Mail Transfer Protocol [SMTP] provides the ability to
   transfer multiple email messages from one host to another, each with
   multiple recipients, using a single or multiple connections.

   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.

   SMTP servers have always been able to announce a limit, in a reply,
   which means that the client first needed to issue a command.  The
   mechanism specified here avoids the overhead of that interactions, by
   announcing limits prior to any substantive interaction.

   The "Limits" extension provides the means for a server to inform a
   client about specific limits in effect for a particular SMTP session.
   This information, combined with the inherent flexibility of SMTP,
   makes it possible for clients to avoid server errors and the problems
   they cause.

   Limits are registered with the IANA.  Each registration includes the
   limit name, value syntax, and a description of its semantics.

2.  Terminology

   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
   [KEYWORDS].

   This specification uses the Augmented Backus-Naur Form [ABNF]
   notation and its core rules to define the formal syntax of the
   "Limits" extension.

Freed                  Expires September 16, 2021               [Page 2]
Internet-Draft              LIMITS Extension                  March 2021

   This specification makes extensive use of the terminology specified
   and used in [SMTP].

3.  The "Limits" SMTP Extension

   Extensions to SMTP are defined in Section 2.2 of [SMTP].

   The name of the extension is "Limits".  Servers implementing this
   extension advertise an additional "LIMITS" EHLO 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
Show full document text