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]
