idnits 2.17.1 draft-harris-early-pipe-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 13, 2018) is 2046 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Harris, Ed. 3 Internet-Draft None 4 Intended status: Experimental September 13, 2018 5 Expires: March 17, 2019 7 SMTP Service Extension for Early Pipelining 8 draft-harris-early-pipe-01 10 Abstract 12 PIPE_CONNECT is an SMTP extension supporting the pipelining of 13 banner, EHLO and one following command or traditionally-pipelined 14 sequence in an SMTP conversation. It permits a reduction in delivery 15 latency by eliminating a nunmber of network round-trips. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 17, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 2. Framework for the Early Pipelining extension . . . . . . . . 2 54 2.1. Simple List . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. The Early Pipelining Service Extension . . . . . . . . . . . 3 56 3.1. Client use of Early Pipelining . . . . . . . . . . . . . 3 57 3.1.1. Service Acquisition . . . . . . . . . . . . . . . . . 3 58 3.1.2. Service use . . . . . . . . . . . . . . . . . . . . . 3 59 3.1.2.1. Service use in cleatext . . . . . . . . . . . . . 3 60 3.1.2.2. Service use after STARTTLS . . . . . . . . . . . 4 61 3.1.2.3. Service use in encrypted non-STARTTLS connections 4 62 3.1.3. Cache invalidation . . . . . . . . . . . . . . . . . 4 63 3.2. Server use of Early Pipelining . . . . . . . . . . . . . 5 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 6.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 The SMTP protocol [RFC5321] specifies an interlocked sequence of 74 commands and responses for the start of the conversation between 75 client and server. Later portions of the conversation can use non- 76 interlocked commands when the PIPELINING extession [RFC2920] is used. 77 This memo specifies a way to perform non-interlocked operations early 78 in the SMTP conversation. 80 1.1. Requirements Language 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 2. Framework for the Early Pipelining extension 88 The Early Pipielining extension is defined as follows: 90 2.1. Simple List 92 1. the name of the SMTP service extension is Early Pipielining; 94 2. the EHLO keyword value associated with the extension is 95 PIPE_CONNECT; 97 3. no parameter is used with the PIPE_CONNECT EHLO keyword; 99 4. no additional parameters are added to either the MAIL FROM or 100 RCPT TO commands; 102 5. no additional SMTP verbs are defined by this extension; and, 104 6. the next section specifies how support for the extension affects 105 the behavior of a server and client SMTP. 107 3. The Early Pipelining Service Extension 109 When a client SMTP wishes to employ early pipelining, it first issues 110 the EHLO command to the server SMTP. If the server SMTP responds 111 with code 250 to the EHLO command, and the response includes the EHLO 112 keyword value PIPE_CONNECT, then the server SMTP has indicated that 113 it can accommodate SMTP early pipelining. 115 3.1. Client use of Early Pipelining 117 3.1.1. Service Acquisition 119 Once the client SMTP has confirmed that support exists for the early 120 pipielinng extension, it MAY cache this information for later 121 connections to the same IP address. The cached information: 123 MUST include the IP address of the server; 125 MUST include the TLS status (cleartext vs. encrypted) in which the 126 EHLO command was used. 128 3.1.2. Service use 130 3.1.2.1. Service use in cleatext 132 A client having valid cached information for cleartext use may use 133 that information on subsequent connections to that IP. If such 134 cached information includes this extension: 136 the client MAY send an EHLO command without waiting for receipt of 137 a banner from the server, and MAY send a following STARTTLS or 138 AUTH command (if permitted by cached information of those 139 extensions) without waiting for either banner or ehlo-response. 141 the client MAY send an EHLO command followed by any sequence of 142 MAIL, RCPT and DATA (or BDAT) commands permitted by cached 143 information of other SMTP extensions, all before waiting for any 144 responses. 146 3.1.2.2. Service use after STARTTLS 148 After a successful STARTTLS negotiation and TLS startup, a client 149 having valid cached information for encrypted use may use that 150 information on connections to that IP. If such cached information 151 includes this extension: 153 the client MAY send an EHLO command followed by any sequence of 154 MAIL, RCPT and DATA (or BDAT) commands permitted by cached 155 information of other SMTP extensions, all before waiting for any 156 responses. 158 the client MAY send an EHLO command followed by an AUTH command, 159 if permitted by cached information of that extension, before 160 waiting for any responses. 162 3.1.2.3. Service use in encrypted non-STARTTLS connections 164 After a successful TLS startup not initiated by a STARTTLS command, a 165 client having valid cached information for encrypted use may use that 166 information on connections to that IP. If such cached information 167 includes this extension: 169 the client MAY send an EHLO command followed by any sequence of 170 MAIL, RCPT and DATA (or BDAT) commands permitted by cached 171 information of other SMTP extensions, all before waiting for a 172 banner or any responses. 174 the client MAY send an EHLO command followed by an AUTH command, 175 if permitted by cached information of that extension, before 176 waiting for an banner or any responses. 178 In all cases the traditional presence and sequencing of commands MUST 179 be used by the client and the checking of responses MUST be done by 180 the client. 182 3.1.3. Cache invalidation 184 The client MAY invalidate cached information at any time. The client 185 MUST compare EHLO response information with cached information and 186 invalidate the cache entry when there is a change for any extension 187 which it uses. It is RECOMMENDED that cache entries also be 188 invalidated after a limited time. 190 A client noting a change in EHLO response: 192 SHOULD NOT generate a DSN for the message being processed, and 193 SHOULD be prepared to retry the message in the event of a non- 194 message-specific SMTP error response from the server. 196 3.2. Server use of Early Pipelining 198 If a server SMTP offers this extension to a client at given IP 199 address, it: 201 must be prepared for commands as detailed above to be received 202 from that client in later SMTP connections, and unless its 203 configuration for the extension has changed SHOULD NOT return 204 error responses for synchronisation reasons; 206 MUST use the traditional presence and sequencing of responses to 207 received commands. 209 A server SHOULD NOT advertise this extension if it is one of many 210 accessed via a single IP address, and the several servers might have 211 different configurations. 213 Implementations SHOULD provide means for restricting this extension 214 to a limited subset of clients. Operators may wish to restrict its 215 use to more-trusted peers. 217 4. IANA Considerations 219 If published as an RFC, this draft requests the addition of the 220 following keyword to the SMTP Service Extensions Registry 221 [IANA-SMTP-Extensions] 223 +--------------------------+----------------------------------------+ 224 | Textual name: | Early Pipelining | 225 | EHLO keyword value: | PIPE_CONNECT | 226 | Syntax and parameters: | (no parameters) | 227 | Additional SMTP verbs: | none | 228 | MAIL and RCPT | none | 229 | parameters: | | 230 | Behavior: | Permits pipelining of early SMTP | 231 | | commands | 232 | Command length | n/a | 233 | increment: | | 234 +--------------------------+----------------------------------------+ 236 Table 1: Registry Entry 238 5. Security Considerations 240 Spammers are known for not respecting the command/response interlocks 241 required by the SMTP protocol, and detecting violations is a common 242 antispam technique. This extension makes such detection have less 243 coverage. Operators may prefer to only advertise and operate support 244 for the extension to known-good clients. 246 6. References 248 6.1. Normative References 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, 252 DOI 10.17487/RFC2119, March 1997, 253 . 255 [RFC2920] Freed, N., "SMTP Service Extension for Command 256 Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920, 257 September 2000, . 259 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 260 DOI 10.17487/RFC5321, October 2008, 261 . 263 6.2. Informative References 265 [IANA-SMTP-Extensions] 266 Internet Assigned Numbers Authoriity (IANA), "SMTP Service 267 Extensions", . 270 Author's Address 272 Jeremy Harris (editor) 273 None 274 20 Lodge Lane 275 Chalfont St.Giles, Bucks 276 UK 278 Email: j29280@wizmail.org