Internet DRAFT - draft-harris-early-pipe

draft-harris-early-pipe







Network Working Group                                     J. Harris, Ed.
Internet-Draft                                                      None
Intended status: Experimental                         September 13, 2018
Expires: March 17, 2019


              SMTP Service Extension for Early Pipelining
                       draft-harris-early-pipe-01

Abstract

   PIPE_CONNECT is an SMTP extension supporting the pipelining of
   banner, EHLO and one following command or traditionally-pipelined
   sequence in an SMTP conversation.  It permits a reduction in delivery
   latency by eliminating a nunmber of network round-trips.

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 March 17, 2019.

Copyright Notice

   Copyright (c) 2018 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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Harris                   Expires March 17, 2019                 [Page 1]

Internet-Draft            SMTP Early Pipelining           September 2018


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  Framework for the Early Pipelining extension  . . . . . . . .   2
     2.1.  Simple List . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  The Early Pipelining Service Extension  . . . . . . . . . . .   3
     3.1.  Client use of Early Pipelining  . . . . . . . . . . . . .   3
       3.1.1.  Service Acquisition . . . . . . . . . . . . . . . . .   3
       3.1.2.  Service use . . . . . . . . . . . . . . . . . . . . .   3
         3.1.2.1.  Service use in cleatext . . . . . . . . . . . . .   3
         3.1.2.2.  Service use after STARTTLS  . . . . . . . . . . .   4
         3.1.2.3.  Service use in encrypted non-STARTTLS connections   4
       3.1.3.  Cache invalidation  . . . . . . . . . . . . . . . . .   4
     3.2.  Server use of Early Pipelining  . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The SMTP protocol [RFC5321] specifies an interlocked sequence of
   commands and responses for the start of the conversation between
   client and server.  Later portions of the conversation can use non-
   interlocked commands when the PIPELINING extession [RFC2920] is used.
   This memo specifies a way to perform non-interlocked operations early
   in the SMTP conversation.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Framework for the Early Pipelining extension

   The Early Pipielining extension is defined as follows:

2.1.  Simple List

   1.  the name of the SMTP service extension is Early Pipielining;

   2.  the EHLO keyword value associated with the extension is
       PIPE_CONNECT;




Harris                   Expires March 17, 2019                 [Page 2]

Internet-Draft            SMTP Early Pipelining           September 2018


   3.  no parameter is used with the PIPE_CONNECT EHLO keyword;

   4.  no additional parameters are added to either the MAIL FROM or
       RCPT TO commands;

   5.  no additional SMTP verbs are defined by this extension; and,

   6.  the next section specifies how support for the extension affects
       the behavior of a server and client SMTP.

3.  The Early Pipelining Service Extension

   When a client SMTP wishes to employ early pipelining, it first issues
   the EHLO command to the server SMTP.  If the server SMTP responds
   with code 250 to the EHLO command, and the response includes the EHLO
   keyword value PIPE_CONNECT, then the server SMTP has indicated that
   it can accommodate SMTP early pipelining.

3.1.  Client use of Early Pipelining

3.1.1.  Service Acquisition

   Once the client SMTP has confirmed that support exists for the early
   pipielinng extension, it MAY cache this information for later
   connections to the same IP address.  The cached information:

      MUST include the IP address of the server;

      MUST include the TLS status (cleartext vs. encrypted) in which the
      EHLO command was used.

3.1.2.  Service use

3.1.2.1.  Service use in cleatext

   A client having valid cached information for cleartext use may use
   that information on subsequent connections to that IP.  If such
   cached information includes this extension:

      the client MAY send an EHLO command without waiting for receipt of
      a banner from the server, and MAY send a following STARTTLS or
      AUTH command (if permitted by cached information of those
      extensions) without waiting for either banner or ehlo-response.

      the client MAY send an EHLO command followed by any sequence of
      MAIL, RCPT and DATA (or BDAT) commands permitted by cached
      information of other SMTP extensions, all before waiting for any
      responses.



Harris                   Expires March 17, 2019                 [Page 3]

Internet-Draft            SMTP Early Pipelining           September 2018


3.1.2.2.  Service use after STARTTLS

   After a successful STARTTLS negotiation and TLS startup, a client
   having valid cached information for encrypted use may use that
   information on connections to that IP.  If such cached information
   includes this extension:

      the client MAY send an EHLO command followed by any sequence of
      MAIL, RCPT and DATA (or BDAT) commands permitted by cached
      information of other SMTP extensions, all before waiting for any
      responses.

      the client MAY send an EHLO command followed by an AUTH command,
      if permitted by cached information of that extension, before
      waiting for any responses.

3.1.2.3.  Service use in encrypted non-STARTTLS connections

   After a successful TLS startup not initiated by a STARTTLS command, a
   client having valid cached information for encrypted use may use that
   information on connections to that IP.  If such cached information
   includes this extension:

      the client MAY send an EHLO command followed by any sequence of
      MAIL, RCPT and DATA (or BDAT) commands permitted by cached
      information of other SMTP extensions, all before waiting for a
      banner or any responses.

      the client MAY send an EHLO command followed by an AUTH command,
      if permitted by cached information of that extension, before
      waiting for an banner or any responses.

   In all cases the traditional presence and sequencing of commands MUST
   be used by the client and the checking of responses MUST be done by
   the client.

3.1.3.  Cache invalidation

   The client MAY invalidate cached information at any time.  The client
   MUST compare EHLO response information with cached information and
   invalidate the cache entry when there is a change for any extension
   which it uses.  It is RECOMMENDED that cache entries also be
   invalidated after a limited time.

   A client noting a change in EHLO response:

      SHOULD NOT generate a DSN for the message being processed, and




Harris                   Expires March 17, 2019                 [Page 4]

Internet-Draft            SMTP Early Pipelining           September 2018


      SHOULD be prepared to retry the message in the event of a non-
      message-specific SMTP error response from the server.

3.2.  Server use of Early Pipelining

   If a server SMTP offers this extension to a client at given IP
   address, it:

      must be prepared for commands as detailed above to be received
      from that client in later SMTP connections, and unless its
      configuration for the extension has changed SHOULD NOT return
      error responses for synchronisation reasons;

      MUST use the traditional presence and sequencing of responses to
      received commands.

   A server SHOULD NOT advertise this extension if it is one of many
   accessed via a single IP address, and the several servers might have
   different configurations.

   Implementations SHOULD provide means for restricting this extension
   to a limited subset of clients.  Operators may wish to restrict its
   use to more-trusted peers.

4.  IANA Considerations

   If published as an RFC, this draft requests the addition of the
   following keyword to the SMTP Service Extensions Registry
   [IANA-SMTP-Extensions]

   +--------------------------+----------------------------------------+
   | Textual name:            | Early Pipelining                       |
   | EHLO keyword value:      | PIPE_CONNECT                           |
   | Syntax and parameters:   | (no parameters)                        |
   | Additional SMTP verbs:   | none                                   |
   | MAIL and RCPT            | none                                   |
   | parameters:              |                                        |
   | Behavior:                | Permits pipelining of early SMTP       |
   |                          | commands                               |
   | Command length           | n/a                                    |
   | increment:               |                                        |
   +--------------------------+----------------------------------------+

                          Table 1: Registry Entry







Harris                   Expires March 17, 2019                 [Page 5]

Internet-Draft            SMTP Early Pipelining           September 2018


5.  Security Considerations

   Spammers are known for not respecting the command/response interlocks
   required by the SMTP protocol, and detecting violations is a common
   antispam technique.  This extension makes such detection have less
   coverage.  Operators may prefer to only advertise and operate support
   for the extension to known-good clients.

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2920]  Freed, N., "SMTP Service Extension for Command
              Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920,
              September 2000, <https://www.rfc-editor.org/info/rfc2920>.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <https://www.rfc-editor.org/info/rfc5321>.

6.2.  Informative References

   [IANA-SMTP-Extensions]
              Internet Assigned Numbers Authoriity (IANA), "SMTP Service
              Extensions", <https://www.iana.org/assignments/mail-
              parameters/mail-parameters.xhtml#mail-parameters-2>.

Author's Address

   Jeremy Harris (editor)
   None
   20 Lodge Lane
   Chalfont St.Giles, Bucks
   UK

   Email: j29280@wizmail.org










Harris                   Expires March 17, 2019                 [Page 6]