idnits 2.17.1 draft-slusarz-extra-smtp-submission-token-00.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 (March 24, 2019) is 1857 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2033 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Sirainen 3 Internet-Draft Open-Xchange Oy 4 Intended status: Standards Track M. Slusarz 5 Expires: September 25, 2019 Open-Xchange Inc. 6 March 24, 2019 8 SMTP: Submission Token Extension 9 draft-slusarz-extra-smtp-submission-token-00 11 Abstract 13 This document specifies an extension to a SMTP submission server that 14 allows synchronous message delivery via use of a limited-privilege 15 authentication token. 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 September 25, 2019. 34 Copyright Notice 36 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 53 3. The Submission Token Service Extension . . . . . . . . . . . 4 54 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 5. Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 5 57 5.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5.3. Types . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5.3.1. Temporary . . . . . . . . . . . . . . . . . . . . . . 6 60 5.3.2. Permanent . . . . . . . . . . . . . . . . . . . . . . 6 61 5.4. Management . . . . . . . . . . . . . . . . . . . . . . . 7 62 5.4.1. GENSTOKEN (Generate Submission Token) Command . . . . 7 63 5.4.1.1. Enhanced Status Code on Successful Token 64 generation . . . . . . . . . . . . . . . . . . . 7 65 5.4.1.2. Examples . . . . . . . . . . . . . . . . . . . . 8 66 5.4.2. REVSTOKEN (Revoke Submission Token) Command . . . . . 8 67 5.4.2.1. Examples . . . . . . . . . . . . . . . . . . . . 8 68 6. Distribution . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 9 70 6.2. Email Header Distribution . . . . . . . . . . . . . . . . 9 71 7. Message Delivery Using Submission Token . . . . . . . . . . . 9 72 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7.2. Connection . . . . . . . . . . . . . . . . . . . . . . . 9 74 7.3. Authentication . . . . . . . . . . . . . . . . . . . . . 10 75 7.3.1. SASL Extension (TODO) . . . . . . . . . . . . . . . . 10 76 7.3.1.1. Examples . . . . . . . . . . . . . . . . . . . . 11 77 7.4. Delivery . . . . . . . . . . . . . . . . . . . . . . . . 11 78 7.4.1. Enhanced Status Codes on Successful Delivery . . . . 11 79 7.4.1.1. Successful Delivery with Delivery ID . . . . . . 11 80 7.4.1.2. Successful Delivery with Delivery ID and 81 Permanent Token Exchange . . . . . . . . . . . . 12 82 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 10.1. SMTP Extension Registration . . . . . . . . . . . . . . 14 86 10.2. Enhanced Status Code Registration . . . . . . . . . . . 14 87 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 90 12.2. Informative References . . . . . . . . . . . . . . . . . 16 91 Appendix A. Change History (To be removed by RFC Editor before 92 publication) . . . . . . . . . . . . . . . . . . . . 16 93 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 96 1. Introduction 98 Electronic mail is a widely-used messaging system that allows any 99 user to join the network if they conform to the open standards 100 defining the federation. 102 This open federation is one of the strengths of the design, and is 103 responsible for much of the medium's popularity. This open 104 federation ensures that no one organization controls the platform. 105 However, this lack of centralization has required substantial network 106 engineering improvements over time to ensure that mails can be routed 107 and delivered, as there is no guarantee that delivery paths will 108 remain stable and reliable over time. 110 This patchwork of systems, layered on top of legacy SMTP [RFC5321] 111 has done a remarkable job in practice of ensuring reliable mail 112 delivery. However, an artifact of these systems is that latency of 113 mail message delivery is highly variable, as routings designed to 114 handle all potential use cases may result in very convoluted delivery 115 paths for a subset of messages. 117 Since email was first created, new messaging paradigms have arisen 118 that allow for an improved real-time message delivery experience. In 119 order to keep email relevant with current user expectations, it is 120 desirable to improve delivery speeds to match these new technologies. 122 This extension provides a solution to allow more real-time message 123 delivery capabilities to email through minimal backward-compatible 124 changes to the legacy SMTP paradigm. This allows for a messaging 125 experience that can be incrementally rolled out to the system - 126 falling back to the existing, reliable email delivery network if not 127 available - and has no visible effect on an end user other than 128 decreased delivery times for the portion of their email traffic using 129 the new standard. 131 Secondarily, this extension also improves security of mail transfer 132 by requiring encrypted network connections, leveraging existing 133 standards, to transfer mail messages. This aligns with the general 134 trend in messaging systems of encrypting in-transit data as much as 135 possible. 137 2. Conventions Used In This Document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 "User" is used to refer to a human user, whereas "client" refers to 146 the software being run by the user. 148 "Token Server" refers to the submission server where authentication 149 occurs and messages are delivered. "Remote Client" is the software 150 that possesses a token, generated by the Token Server, and 151 authenticates to the Token Server with that token to deliver a 152 message. 154 In examples, "C:" and "S:" indicate lines sent by the client and 155 server respectively. If a single "C:" or "S:" label applies to 156 multiple lines, then the line breaks between those lines are for 157 editorial clarity only and are not part of the actual protocol 158 exchange. 160 TODO: note on case insensitivity of protocol examples 162 3. The Submission Token Service Extension 164 1. The name of this SMTP [RFC5321] service extension is "Submission 165 Token". 167 2. The EHLO keyword value associated with this extension is 168 "STOKEN". 170 3. Two new SMTP [RFC5321] verbs are defined: "GENSTOKEN" and 171 "REVSTOKEN" 173 4. Two optional parameters, using the keywords "STOKEN" and 174 "MYSTOKEN", are added to the RCPT TO command. 176 5. This extension is appropriate, and exclusive to, the submission 177 protocol [RFC6409]. 179 6. This extension is appropriate, and exclusive to, Local Mail 180 Transfer Protocol (LMTP) [RFC2033]. 182 7. When this extension is used, the trace field MUST use the WITH 183 keyword LMTPSA [RFC3848]. 185 8. When this extension is used, the DNS Submission SRV [RFC6186] 186 record MUST be specified. 188 9. When this extension is used, the ENHANCEDSTATUSCODES [RFC2034] 189 service extension MUST be available. 191 4. Overview 193 A brief overview of how submission tokens work is as follows: 195 1. A temporary token is generated on the Token Server (See 196 Section 5) 198 2. The token is distributed to the remote recipient(s) (See 199 Section 6) 201 3. The remote recipient, via a Remote Client, connects to the Token 202 Server, via the submission protocol, and authenticates using the 203 token. Once authenticated, the Remote Client uses LMTP to 204 deliver the message. 206 * During delivery, a temporary token is replaced with a new 207 permanent token issued by the Token Server. 209 * (Optional) The Remote Client provides its permanent token to 210 the Token Server (if it can handle incoming submission 211 connections) to allow the reverse delivery flow to use token 212 authentication. 214 The remaining sections describe the details of this process. 216 5. Token 218 5.1. Description 220 Tokens are a variable-length string, dynamically generated by a Token 221 Server, that are used to allow a specific remote recipient to 222 authenticate to the Token Server for the limited purpose of 223 delivering a message to the owner of the token. 225 All tokens MUST be tied to a specific pair of recipients (remote and 226 local). All tokens SHOULD be time limited; the duration is dictated 227 by the token type (see below). 229 5.2. Format 231 The token format is not defined by this document and is server- 232 dependent. 234 TODO: Should token format be standardized 236 5.3. Types 238 Two categories of tokens are defined: temporary and permanent. 240 5.3.1. Temporary 242 A temporary token is designed to be created by the Token Server for 243 an initial engagement with a remote recipient. 245 Temporary tokens are expected to be distributed through possible non- 246 secure channels. Therefore, sessions authenticated via a temporary 247 token MAY be treated as less trusted. 249 Temporary tokens SHOULD be time-limited to a valid duration of one 250 week. 252 The token MAY be used multiple times, as a remote recipient may use 253 multiple Token Clients. Thus, temporary token validity SHOULD be 254 tied to time limitations, not use limitations. 256 Temporary tokens can be generated in a manner whereby the token isn't 257 stored by the Token Server. Instead, these tokens can be created 258 such that a Token Server can verify whether the token is valid based 259 solely on the contents of the token string. This allows generation 260 of large numbers of temporary tokens, some that may never be used, 261 without imposing a storage burden on the Token Server. 263 TODO: Provide example of self-verifying token 265 5.3.2. Permanent 267 A permanent token is generated when a Remote Client successfully 268 delivers a message using a temporary token. This delivery (along 269 with TLS verification required as part of the delivery process) 270 provides a measure of trust verification regarding the recipient to 271 recipient delivery chain, such that future use of a permanent token 272 to deliver messages SHOULD be treated as a more trusted delivery than 273 non-permanent token deliveries. 275 The permanent token is intended to be only transferred over a secure 276 channel, unlike a temporary token. 278 Since trust in a permanent token is higher than a temporary token, 279 the expiration date of the token can be significantly longer. A 280 permanent token SHOULD be time-limited to a valid duration of one 281 year. 283 In order to maintain the trusted relationship, once established, a 284 server MAY refresh or extend a permanent token during any successful 285 delivery. It is server-dependent when this occurs. A Remote Client 286 MUST expect and handle a token regeneration if a server provides a 287 new permanent token. 289 5.4. Management 291 Token generation MAY be transparently handled by a Token Server. 292 However, token management must also be accessible to a connecting 293 client. This subsection defines two SMTP commands that allow this 294 management. 296 5.4.1. GENSTOKEN (Generate Submission Token) Command 298 GENSTOKEN ( "PERM" / "TEMP" ) remote-address [local-address] 300 Generates a token for given local/remote address pair. 302 If permanent token already exists, return that token. 304 On success, return 250 reply code, with a 2.1.11 extended status 305 code; the response contains the generated token. 307 On error: If remote address is incorrect, return 501 reply code 308 with a 5.1.3 extended status code. If local address is provided 309 and is incorrect, return 501 reply code with a 5.1.7 extended 310 status code. If token could not be generated for the remote/local 311 address pair, return 451 reply code with a 4.5.0 extended status 312 code. 314 TODO: local-address optional 316 TODO: If temporary token already exists, generate a new one? 318 TODO: Does generation of already existing permanent token count as 319 a refresh/renew, and a new one is generated? 321 5.4.1.1. Enhanced Status Code on Successful Token generation 323 Code: X.1.11 324 Sample Text: Submission Token Successfully Created 325 Associated basic status code: 250 326 Description: This status code is returned when a submission 327 token is successfully generated with the 328 GENSTOKEN command. The humantext associated 329 with this code has a defined format of: 330 token humantext 332 5.4.1.2. Examples 334 Example: Creating a temporary token using GENSTOKEN 336 C: GENSTOKEN TEMP user@example.com localuser@foo.com 337 S: 250 2.1.11 17yUEeUu8M Temporary token generated. 339 Example: GENSTOKEN Error (incorrect remote address) 341 C: GENSTOKEN TEMP remoteuser..@example.com 342 S: 501 5.1.3 Incorrect remote address. 344 5.4.2. REVSTOKEN (Revoke Submission Token) Command 346 REVSTOKEN remote-address [local-address] 348 Revokes all tokens for a given local/remote address pair. 350 On success, return 250 reply code, with a 2.1.0 extended status 351 code. If no tokens exist for a local/remote address pair, this 352 should be treated as a successful command completion. 354 On error: If remote address is incorrect, return 501 reply code 355 with a 5.1.3 extended status code. If local address is provided 356 and is incorrect, return 501 reply code with a 5.1.7 extended 357 status code. If token could not be revoked for the remote/local 358 address pair, return 451 reply code with a 4.5.0 extended status 359 code. 361 TODO: local-address optional 363 TODO: Is success returned even if token does not exist? 365 5.4.2.1. Examples 367 Example: Revoking tokens using REVSTOKEN 369 C: REVSTOKEN user@example.com localuser@foo.com 370 S: 250 2.1.0 All tokens successfully revoked. 372 Example: REVSTOKEN Error (incorrect remote address) 374 C: REVSTOKEN remoteuser..@example.com 375 S: 501 5.1.3 Incorrect remote address. 377 6. Distribution 379 6.1. Description 381 Temporary token distribution to an external recipient can be 382 accomplished in any manner deemed appropriate by an implementer. 384 This document defines a method that temporary tokens can be 385 distributed to a recipient via email headers. 387 6.2. Email Header Distribution 389 Temporary tokens can be distributed by use of a newly-defined 390 Submission-Token email header. 392 Submission server can automatically generate tokens for outgoing 393 messages 395 Submission-Token: 397 There can be multiple Submission-Token headers, as each contact can 398 have multiple aliases. 400 TODO: Add submission host hint? 402 TODO: RFC mail header definition requirements? 404 TODO: Define token format? 406 7. Message Delivery Using Submission Token 408 7.1. Summary 410 This section summarizes the process for a Remote Client to deliver a 411 message by connecting to the Token Server with a submission token 412 valid for the sending user and the message recipient. 414 If the Remove Client possesses a valid token for the sender/recipient 415 pair, it can attempt to use submission token routing to deliver the 416 message. Otherwise, the Remote Client can fallback to sending the 417 message through basic submission deliver behavior. 419 7.2. Connection 421 The Remote Client connects to the Token Server. 423 The Token Server for a recipient is discovered via the DNS SRV 424 [RFC6186] submission record. 426 TODO: Use full domain, then fallback to base domain? 428 If the DNS SRV submission record doesn't exist, or the host cannot be 429 contacted, a Remote Client MAY fallback to using the server address 430 provided by the DNS MX [RFC5321] record. 432 If Remote Client cannot determine the address for the Token Server, 433 the message should be sent via normal mail submission [RFC6409] 434 channels. 436 Once the Token Server address is determined, and a connection can be 437 established to that address, this connection MUST be protected by 438 TLS. The mechanism and port used to enable this secure connection is 439 described in RFC 8314 [RFC8314]. Continuing discussion here assumes 440 a TLS layer has been established based on the requirements contained 441 in RFC 8314. 443 STOKEN MUST NOT be listed as a service extension on the Token Server 444 until TLS is active. 446 TODO: TLS domain/certificate check a MUST? 448 7.3. Authentication 450 Once connected, and TLS is active, the client MUST send a LHLO 451 command. This command indicates that the protocol used is LMTP 452 [RFC2033]. LMTP is used because submission token-based delivery 453 requires guaranteed synchronous message delivery where the message 454 MUST NOT be queued. 456 The service extension identifier STOKEN must be output as part of the 457 return from the LHLO command. STOKEN must not be announced as a 458 return from the HELO or EHLO commands. If STOKEN is not listed, the 459 Remote Client should immediately terminate the submission sessions 460 and proceed to delivering the message through basic submission 461 delivery. 463 Authentication to access the Token Server with a submission token is 464 accomplished via the AUTH [RFC4954] command. 466 7.3.1. SASL Extension (TODO) 468 TODO: Need to define SASL [RFC4422] method to do authentication. 469 Idea: "AUTH STOKEN input", where input is a base64 [RFC4648] encoded 470 string of "recipient\0stoken". Recipient is used as a simple DoS 471 prevention, requiring that a submission token alone is not enough to 472 access the server. 474 If multiple recipients exist on the Token Server, and Remote Client 475 possesses multiple submission tokens, any single token valid for a 476 recipient/token pair that the Token Server can service will suffice 477 to pass the authentication check. 479 See https://tools.ietf.org/html/rfc4422#section-5 for requirements in 480 defining new SASL mechanism. 482 See https://tools.ietf.org/html/rfc4505#section-2 for example SASL 483 mechanism definition 485 "normalization"? is foo@server.example.com the same as 486 foo@example.com? 488 7.3.1.1. Examples 490 Example: SASL STOKEN Auth 492 C: AUTH STOKEN dXNlckBmb28uY29tXDBzNnhXMTVoOURo 493 S: 235 2.7.0 OK 495 Example: SASL STOKEN Auth Error 497 C: AUTH STOKEN abcdefg 498 S: 535 5.7.8 Could not authenticate. 500 7.4. Delivery 502 Delivery is restricted to users for which the Remote Client has a 503 valid submission token and the message can be synchronously 504 delivered. The token for a given recipient is specified via the 505 STOKEN parameter to the RCPT TO command. 507 If the Remote Client supports submission token delivery, the Remote 508 Client can provide a permanent token to the Token Server via the 509 MYSTOKEN parameter to the RCPT TO command. This allows the Token 510 Server recipient to be able to connect back to the Remote Client 511 submission server to deliver messages in the future. 513 7.4.1. Enhanced Status Codes on Successful Delivery 515 7.4.1.1. Successful Delivery with Delivery ID 517 It can be useful for a client to record a delivery tracking ID 518 provided by the submission server after a successful delivery. Many 519 submission servers add this information to the humantext that follows 520 the status code and optional enhanced status code. However, there is 521 no current standard that exists regarding the formatting of this info 522 across disparate submission implementations. 524 This extension adds an enhanced status code that defines the format 525 of the humantext after a successful delivery to allow for reliable 526 machine-automated extraction of this delivery ID. 528 Code: X.1.12 529 Sample Text: Message successfully delivered 530 Associated basic status code: 250 531 Description: This status code is returned when a message is 532 successfully delivered, and a unique delivery 533 ID has been generated and is being provided to 534 the sender. The humantext associated with this 535 code has a defined format of: 536 delivery-id humantext 538 7.4.1.2. Successful Delivery with Delivery ID and Permanent Token 539 Exchange 541 In addition to a delivery ID, upon a successfully delivery a Token 542 Server may either need to 1) replace a temporary token with a 543 permanent token, or 2) replace an existing permanent token with a new 544 permanent token. This information is broadcast to the Remote Client 545 by means of structured data presented in the 250 success response to 546 the DATA command. 548 This extension adds an enhanced status code that defines the format 549 of the humantext after a successful delivery to allow for reliable 550 machine-automated extraction of both the delivery ID code and the 551 permanent token. 553 Code: X.1.13 554 Sample Text: Message successfully delivered and permanent 555 submission token generated 556 Associated basic status code: 250 557 Description: This status code is returned when a message is 558 successfully delivered and a unique delivery 559 ID has been generated and is being provided to 560 the sender. The humantext associated with this 561 code has a defined format of: 562 token delivery-id 563 humantext 565 8. Examples 567 Example 1: Remote Client using a temporary token to deliver a message 568 via a Token Server 570 [...TLS layer negotiated...] 571 C: LHLO sender.example.com 572 S: 250-foo.com 573 S: 250-ENHANCEDSTATUSCODES 574 S: 250 STOKEN 575 C: AUTH STOKEN dXNlckBmb28uY29tXDBzNnhXMTVoOURo 576 S: 235 2.7.0 OK 577 C: MAIL FROM: 578 S: 250 2.1.0 OK 579 C: RCPT TO: STOKEN=s6xW15h9Dh MYSTOKEN=Enm3HX76Mb 580 S: 250 2.1.5 OK 581 C: RCPT TO: STOKEN=mfpWamXp5L MYSTOKEN=H4tGNfh6Us 582 S: 250 2.1.5 OK 583 C: DATA 584 S: 354 OK 585 C: [...message data...] 586 C: . 587 S: 250 2.1.13 etLBdTj1iG NRaaVe83QN Saved 588 S: 250 2.1.13 bS6zMW8Hrk VddCEQDVyp Saved 590 Example 2: Remote Client using permanent token to deliver a message 591 via a Token Server 593 C: LHLO sender.example.com 594 S: 250-foo.com 595 S: 250-ENHANCEDSTATUSCODES 596 S: 250 STOKEN 597 C: AUTH STOKEN dXNlckBmb28uY29tXDB6NEpIbVVOSks0 598 S: 235 2.7.0 OK 599 C: MAIL FROM: 600 S: 250 2.1.0 OK 601 C: RCPT TO: STOKEN=z4JHmUNJK4 MYSTOKEN=YlcDrrLZEC 602 S: 250 2.1.5 OK 603 C: RCPT TO: STOKEN=m6Cn9lIKjU MYSTOKEN=kAT0G96njA 604 S: 250 2.1.5 OK 605 C: DATA 606 S: 354 OK 607 C: [...message data...] 608 C: . 609 S: 250 2.1.12 imXtPChKDO Saved 610 S: 250 2.1.13 CXJSmLdbeh 2WXuXmKG15 Saved 611 and new token returned 613 Example 3: TODO - Error examples 615 9. Formal Syntax 617 The following syntax specification uses the augmented Backus-Naur 618 Form (BNF) as described in ABNF [RFC5234]. It includes definitions 619 from SMTP [RFC5321]. 621 Except as noted otherwise, all alphabetic characters are case- 622 insensitive. The use of upper or lower case characters to define 623 token strings is for editorial clarity only. Implementations MUST 624 accept these strings in a case-insensitive fashion. 626 esmtp-keyword /= "STOKEN" / "MYSTOKEN" 628 token = string ; TODO 630 delivery-id = string ; TODO 632 10. IANA Considerations 634 10.1. SMTP Extension Registration 636 Section 2.2.2 of SMTP [RFC5321] defines the the procedure for 637 registering a new SMTP extension. It is requested that IANA 638 registers the new SMTP extension STOKEN using the details provided in 639 Section 3 of this document. 641 10.2. Enhanced Status Code Registration 643 Section 2.3 of RFC 5248 [RFC5248] defines the procedure for 644 registering a new enumerated status code in the "Simple Mail Transfer 645 Protocol (SMTP) Enhanced Status Codes Registry". It is requested 646 that IANA registers the new enhanced status codes using the details 647 provided in Section 5.4.1.1 and Section 7.4.1 of this document. 649 11. Security Considerations 651 TODO 653 SPF/DKIM 655 Remote authentication 657 Storage of tokens 659 Interception of temporary token. 661 DoS. 663 SPAM - still need to scan! 665 Token use increases trust, but does not guarantee it. 667 12. References 669 12.1. Normative References 671 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 672 DOI 10.17487/RFC2033, October 1996, 673 . 675 [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced 676 Error Codes", RFC 2034, DOI 10.17487/RFC2034, October 677 1996, . 679 [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types 680 Registration", RFC 3848, DOI 10.17487/RFC3848, July 2004, 681 . 683 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 684 Authentication and Security Layer (SASL)", RFC 4422, 685 DOI 10.17487/RFC4422, June 2006, 686 . 688 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 689 Specifications: ABNF", STD 68, RFC 5234, 690 DOI 10.17487/RFC5234, January 2008, 691 . 693 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 694 DOI 10.17487/RFC5321, October 2008, 695 . 697 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 698 Submission/Access Services", RFC 6186, 699 DOI 10.17487/RFC6186, March 2011, 700 . 702 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 703 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 704 . 706 [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: 707 Use of Transport Layer Security (TLS) for Email Submission 708 and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, 709 . 711 12.2. Informative References 713 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 714 Requirement Levels", BCP 14, RFC 2119, 715 DOI 10.17487/RFC2119, March 1997, 716 . 718 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 719 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 720 . 722 [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service 723 Extension for Authentication", RFC 4954, 724 DOI 10.17487/RFC4954, July 2007, 725 . 727 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 728 Mail System Status Codes", BCP 138, RFC 5248, 729 DOI 10.17487/RFC5248, June 2008, 730 . 732 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 733 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 734 May 2017, . 736 Appendix A. Change History (To be removed by RFC Editor before 737 publication) 739 Acknowledgments 741 The authors would like to thank the following people for their 742 comments and contributions to this document: TODO. 744 Authors' Addresses 746 Timo Sirainen 747 Open-Xchange Oy 748 Lars Sonckin kaari 12 749 Espoo 02600 750 FI 752 Email: timo.sirainen@open-xchange.com 753 Michael M. Slusarz 754 Open-Xchange Inc. 755 530 Lytton Avenue 756 Palo Alto, California 94301 757 US 759 Email: michael.slusarz@open-xchange.com