SMTP Service Extension for Early Pipelining
draft-harris-early-pipe-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Jeremy Harris | ||
| Last updated | 2018-09-03 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-harris-early-pipe-00
Network Working Group J. Harris, Ed.
Internet-Draft None
Intended status: Experimental September 3, 2018
Expires: March 7, 2019
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.
Harris Expires March 7, 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 . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 7, 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 7, 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.
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.
Harris Expires March 7, 2019 [Page 4]
Internet-Draft SMTP Early Pipelining September 2018
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]
+--------------------------+----------------------------------------+
| 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
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
Harris Expires March 7, 2019 [Page 5]
Internet-Draft SMTP Early Pipelining September 2018
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 7, 2019 [Page 6]