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

Abstract

PIPE_CONNECT is an SMTP extension supporting the pipelining of banner, EHLO and one folling command 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 7, 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.

Table of Contents

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

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.

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

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. Information MUST be invalidated upon any error (4xx or 5xx) response from the server for an smtp transaction using this extension. It is RECOMMENDED that information also be invalidated after a limited time.

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.

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]

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 detect have less coverage. Operators may prefer to only advertise snd operate support for the extension to known-good clients.

6. References

6.1. Normative References

6.2. Informative References

Author's Address