Network Working Group T. Sirainen Internet-Draft Open-Xchange Oy Intended status: Standards Track M. Slusarz Expires: September 25, 2019 Open-Xchange Inc. March 24, 2019 SMTP: Submission Token Extension draft-slusarz-extra-smtp-submission-token-00 Abstract This document specifies an extension to a SMTP submission server that allows synchronous message delivery via use of a limited-privilege authentication token. 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 September 25, 2019. Copyright Notice Copyright (c) 2019 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. Sirainen & Slusarz Expires September 25, 2019 [Page 1] Internet-Draft SMTP: Submission Token March 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 3. The Submission Token Service Extension . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.3. Types . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3.1. Temporary . . . . . . . . . . . . . . . . . . . . . . 6 5.3.2. Permanent . . . . . . . . . . . . . . . . . . . . . . 6 5.4. Management . . . . . . . . . . . . . . . . . . . . . . . 7 5.4.1. GENSTOKEN (Generate Submission Token) Command . . . . 7 5.4.1.1. Enhanced Status Code on Successful Token generation . . . . . . . . . . . . . . . . . . . 7 5.4.1.2. Examples . . . . . . . . . . . . . . . . . . . . 8 5.4.2. REVSTOKEN (Revoke Submission Token) Command . . . . . 8 5.4.2.1. Examples . . . . . . . . . . . . . . . . . . . . 8 6. Distribution . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Email Header Distribution . . . . . . . . . . . . . . . . 9 7. Message Delivery Using Submission Token . . . . . . . . . . . 9 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Connection . . . . . . . . . . . . . . . . . . . . . . . 9 7.3. Authentication . . . . . . . . . . . . . . . . . . . . . 10 7.3.1. SASL Extension (TODO) . . . . . . . . . . . . . . . . 10 7.3.1.1. Examples . . . . . . . . . . . . . . . . . . . . 11 7.4. Delivery . . . . . . . . . . . . . . . . . . . . . . . . 11 7.4.1. Enhanced Status Codes on Successful Delivery . . . . 11 7.4.1.1. Successful Delivery with Delivery ID . . . . . . 11 7.4.1.2. Successful Delivery with Delivery ID and Permanent Token Exchange . . . . . . . . . . . . 12 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10.1. SMTP Extension Registration . . . . . . . . . . . . . . 14 10.2. Enhanced Status Code Registration . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Change History (To be removed by RFC Editor before publication) . . . . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Sirainen & Slusarz Expires September 25, 2019 [Page 2] Internet-Draft SMTP: Submission Token March 2019 1. Introduction Electronic mail is a widely-used messaging system that allows any user to join the network if they conform to the open standards defining the federation. This open federation is one of the strengths of the design, and is responsible for much of the medium's popularity. This open federation ensures that no one organization controls the platform. However, this lack of centralization has required substantial network engineering improvements over time to ensure that mails can be routed and delivered, as there is no guarantee that delivery paths will remain stable and reliable over time. This patchwork of systems, layered on top of legacy SMTP [RFC5321] has done a remarkable job in practice of ensuring reliable mail delivery. However, an artifact of these systems is that latency of mail message delivery is highly variable, as routings designed to handle all potential use cases may result in very convoluted delivery paths for a subset of messages. Since email was first created, new messaging paradigms have arisen that allow for an improved real-time message delivery experience. In order to keep email relevant with current user expectations, it is desirable to improve delivery speeds to match these new technologies. This extension provides a solution to allow more real-time message delivery capabilities to email through minimal backward-compatible changes to the legacy SMTP paradigm. This allows for a messaging experience that can be incrementally rolled out to the system - falling back to the existing, reliable email delivery network if not available - and has no visible effect on an end user other than decreased delivery times for the portion of their email traffic using the new standard. Secondarily, this extension also improves security of mail transfer by requiring encrypted network connections, leveraging existing standards, to transfer mail messages. This aligns with the general trend in messaging systems of encrypting in-transit data as much as possible. 2. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Sirainen & Slusarz Expires September 25, 2019 [Page 3] Internet-Draft SMTP: Submission Token March 2019 "User" is used to refer to a human user, whereas "client" refers to the software being run by the user. "Token Server" refers to the submission server where authentication occurs and messages are delivered. "Remote Client" is the software that possesses a token, generated by the Token Server, and authenticates to the Token Server with that token to deliver a message. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange. TODO: note on case insensitivity of protocol examples 3. The Submission Token Service Extension 1. The name of this SMTP [RFC5321] service extension is "Submission Token". 2. The EHLO keyword value associated with this extension is "STOKEN". 3. Two new SMTP [RFC5321] verbs are defined: "GENSTOKEN" and "REVSTOKEN" 4. Two optional parameters, using the keywords "STOKEN" and "MYSTOKEN", are added to the RCPT TO command. 5. This extension is appropriate, and exclusive to, the submission protocol [RFC6409]. 6. This extension is appropriate, and exclusive to, Local Mail Transfer Protocol (LMTP) [RFC2033]. 7. When this extension is used, the trace field MUST use the WITH keyword LMTPSA [RFC3848]. 8. When this extension is used, the DNS Submission SRV [RFC6186] record MUST be specified. 9. When this extension is used, the ENHANCEDSTATUSCODES [RFC2034] service extension MUST be available. Sirainen & Slusarz Expires September 25, 2019 [Page 4] Internet-Draft SMTP: Submission Token March 2019 4. Overview A brief overview of how submission tokens work is as follows: 1. A temporary token is generated on the Token Server (See Section 5) 2. The token is distributed to the remote recipient(s) (See Section 6) 3. The remote recipient, via a Remote Client, connects to the Token Server, via the submission protocol, and authenticates using the token. Once authenticated, the Remote Client uses LMTP to deliver the message. * During delivery, a temporary token is replaced with a new permanent token issued by the Token Server. * (Optional) The Remote Client provides its permanent token to the Token Server (if it can handle incoming submission connections) to allow the reverse delivery flow to use token authentication. The remaining sections describe the details of this process. 5. Token 5.1. Description Tokens are a variable-length string, dynamically generated by a Token Server, that are used to allow a specific remote recipient to authenticate to the Token Server for the limited purpose of delivering a message to the owner of the token. All tokens MUST be tied to a specific pair of recipients (remote and local). All tokens SHOULD be time limited; the duration is dictated by the token type (see below). 5.2. Format The token format is not defined by this document and is server- dependent. TODO: Should token format be standardized Sirainen & Slusarz Expires September 25, 2019 [Page 5] Internet-Draft SMTP: Submission Token March 2019 5.3. Types Two categories of tokens are defined: temporary and permanent. 5.3.1. Temporary A temporary token is designed to be created by the Token Server for an initial engagement with a remote recipient. Temporary tokens are expected to be distributed through possible non- secure channels. Therefore, sessions authenticated via a temporary token MAY be treated as less trusted. Temporary tokens SHOULD be time-limited to a valid duration of one week. The token MAY be used multiple times, as a remote recipient may use multiple Token Clients. Thus, temporary token validity SHOULD be tied to time limitations, not use limitations. Temporary tokens can be generated in a manner whereby the token isn't stored by the Token Server. Instead, these tokens can be created such that a Token Server can verify whether the token is valid based solely on the contents of the token string. This allows generation of large numbers of temporary tokens, some that may never be used, without imposing a storage burden on the Token Server. TODO: Provide example of self-verifying token 5.3.2. Permanent A permanent token is generated when a Remote Client successfully delivers a message using a temporary token. This delivery (along with TLS verification required as part of the delivery process) provides a measure of trust verification regarding the recipient to recipient delivery chain, such that future use of a permanent token to deliver messages SHOULD be treated as a more trusted delivery than non-permanent token deliveries. The permanent token is intended to be only transferred over a secure channel, unlike a temporary token. Since trust in a permanent token is higher than a temporary token, the expiration date of the token can be significantly longer. A permanent token SHOULD be time-limited to a valid duration of one year. Sirainen & Slusarz Expires September 25, 2019 [Page 6] Internet-Draft SMTP: Submission Token March 2019 In order to maintain the trusted relationship, once established, a server MAY refresh or extend a permanent token during any successful delivery. It is server-dependent when this occurs. A Remote Client MUST expect and handle a token regeneration if a server provides a new permanent token. 5.4. Management Token generation MAY be transparently handled by a Token Server. However, token management must also be accessible to a connecting client. This subsection defines two SMTP commands that allow this management. 5.4.1. GENSTOKEN (Generate Submission Token) Command GENSTOKEN ( "PERM" / "TEMP" ) remote-address [local-address] Generates a token for given local/remote address pair. If permanent token already exists, return that token. On success, return 250 reply code, with a 2.1.11 extended status code; the response contains the generated token. On error: If remote address is incorrect, return 501 reply code with a 5.1.3 extended status code. If local address is provided and is incorrect, return 501 reply code with a 5.1.7 extended status code. If token could not be generated for the remote/local address pair, return 451 reply code with a 4.5.0 extended status code. TODO: local-address optional TODO: If temporary token already exists, generate a new one? TODO: Does generation of already existing permanent token count as a refresh/renew, and a new one is generated? 5.4.1.1. Enhanced Status Code on Successful Token generation Code: X.1.11 Sample Text: Submission Token Successfully Created Associated basic status code: 250 Description: This status code is returned when a submission token is successfully generated with the GENSTOKEN command. The humantext associated with this code has a defined format of: token humantext Sirainen & Slusarz Expires September 25, 2019 [Page 7] Internet-Draft SMTP: Submission Token March 2019 5.4.1.2. Examples Example: Creating a temporary token using GENSTOKEN C: GENSTOKEN TEMP user@example.com localuser@foo.com S: 250 2.1.11 17yUEeUu8M Temporary token generated. Example: GENSTOKEN Error (incorrect remote address) C: GENSTOKEN TEMP remoteuser..@example.com S: 501 5.1.3 Incorrect remote address. 5.4.2. REVSTOKEN (Revoke Submission Token) Command REVSTOKEN remote-address [local-address] Revokes all tokens for a given local/remote address pair. On success, return 250 reply code, with a 2.1.0 extended status code. If no tokens exist for a local/remote address pair, this should be treated as a successful command completion. On error: If remote address is incorrect, return 501 reply code with a 5.1.3 extended status code. If local address is provided and is incorrect, return 501 reply code with a 5.1.7 extended status code. If token could not be revoked for the remote/local address pair, return 451 reply code with a 4.5.0 extended status code. TODO: local-address optional TODO: Is success returned even if token does not exist? 5.4.2.1. Examples Example: Revoking tokens using REVSTOKEN C: REVSTOKEN user@example.com localuser@foo.com S: 250 2.1.0 All tokens successfully revoked. Example: REVSTOKEN Error (incorrect remote address) C: REVSTOKEN remoteuser..@example.com S: 501 5.1.3 Incorrect remote address. Sirainen & Slusarz Expires September 25, 2019 [Page 8] Internet-Draft SMTP: Submission Token March 2019 6. Distribution 6.1. Description Temporary token distribution to an external recipient can be accomplished in any manner deemed appropriate by an implementer. This document defines a method that temporary tokens can be distributed to a recipient via email headers. 6.2. Email Header Distribution Temporary tokens can be distributed by use of a newly-defined Submission-Token email header. Submission server can automatically generate tokens for outgoing messages Submission-Token: There can be multiple Submission-Token headers, as each contact can have multiple aliases. TODO: Add submission host hint? TODO: RFC mail header definition requirements? TODO: Define token format? 7. Message Delivery Using Submission Token 7.1. Summary This section summarizes the process for a Remote Client to deliver a message by connecting to the Token Server with a submission token valid for the sending user and the message recipient. If the Remove Client possesses a valid token for the sender/recipient pair, it can attempt to use submission token routing to deliver the message. Otherwise, the Remote Client can fallback to sending the message through basic submission deliver behavior. 7.2. Connection The Remote Client connects to the Token Server. The Token Server for a recipient is discovered via the DNS SRV [RFC6186] submission record. Sirainen & Slusarz Expires September 25, 2019 [Page 9] Internet-Draft SMTP: Submission Token March 2019 TODO: Use full domain, then fallback to base domain? If the DNS SRV submission record doesn't exist, or the host cannot be contacted, a Remote Client MAY fallback to using the server address provided by the DNS MX [RFC5321] record. If Remote Client cannot determine the address for the Token Server, the message should be sent via normal mail submission [RFC6409] channels. Once the Token Server address is determined, and a connection can be established to that address, this connection MUST be protected by TLS. The mechanism and port used to enable this secure connection is described in RFC 8314 [RFC8314]. Continuing discussion here assumes a TLS layer has been established based on the requirements contained in RFC 8314. STOKEN MUST NOT be listed as a service extension on the Token Server until TLS is active. TODO: TLS domain/certificate check a MUST? 7.3. Authentication Once connected, and TLS is active, the client MUST send a LHLO command. This command indicates that the protocol used is LMTP [RFC2033]. LMTP is used because submission token-based delivery requires guaranteed synchronous message delivery where the message MUST NOT be queued. The service extension identifier STOKEN must be output as part of the return from the LHLO command. STOKEN must not be announced as a return from the HELO or EHLO commands. If STOKEN is not listed, the Remote Client should immediately terminate the submission sessions and proceed to delivering the message through basic submission delivery. Authentication to access the Token Server with a submission token is accomplished via the AUTH [RFC4954] command. 7.3.1. SASL Extension (TODO) TODO: Need to define SASL [RFC4422] method to do authentication. Idea: "AUTH STOKEN input", where input is a base64 [RFC4648] encoded string of "recipient\0stoken". Recipient is used as a simple DoS prevention, requiring that a submission token alone is not enough to access the server. Sirainen & Slusarz Expires September 25, 2019 [Page 10] Internet-Draft SMTP: Submission Token March 2019 If multiple recipients exist on the Token Server, and Remote Client possesses multiple submission tokens, any single token valid for a recipient/token pair that the Token Server can service will suffice to pass the authentication check. See https://tools.ietf.org/html/rfc4422#section-5 for requirements in defining new SASL mechanism. See https://tools.ietf.org/html/rfc4505#section-2 for example SASL mechanism definition "normalization"? is foo@server.example.com the same as foo@example.com? 7.3.1.1. Examples Example: SASL STOKEN Auth C: AUTH STOKEN dXNlckBmb28uY29tXDBzNnhXMTVoOURo S: 235 2.7.0 OK Example: SASL STOKEN Auth Error C: AUTH STOKEN abcdefg S: 535 5.7.8 Could not authenticate. 7.4. Delivery Delivery is restricted to users for which the Remote Client has a valid submission token and the message can be synchronously delivered. The token for a given recipient is specified via the STOKEN parameter to the RCPT TO command. If the Remote Client supports submission token delivery, the Remote Client can provide a permanent token to the Token Server via the MYSTOKEN parameter to the RCPT TO command. This allows the Token Server recipient to be able to connect back to the Remote Client submission server to deliver messages in the future. 7.4.1. Enhanced Status Codes on Successful Delivery 7.4.1.1. Successful Delivery with Delivery ID It can be useful for a client to record a delivery tracking ID provided by the submission server after a successful delivery. Many submission servers add this information to the humantext that follows the status code and optional enhanced status code. However, there is Sirainen & Slusarz Expires September 25, 2019 [Page 11] Internet-Draft SMTP: Submission Token March 2019 no current standard that exists regarding the formatting of this info across disparate submission implementations. This extension adds an enhanced status code that defines the format of the humantext after a successful delivery to allow for reliable machine-automated extraction of this delivery ID. Code: X.1.12 Sample Text: Message successfully delivered Associated basic status code: 250 Description: This status code is returned when a message is successfully delivered, and a unique delivery ID has been generated and is being provided to the sender. The humantext associated with this code has a defined format of: delivery-id humantext 7.4.1.2. Successful Delivery with Delivery ID and Permanent Token Exchange In addition to a delivery ID, upon a successfully delivery a Token Server may either need to 1) replace a temporary token with a permanent token, or 2) replace an existing permanent token with a new permanent token. This information is broadcast to the Remote Client by means of structured data presented in the 250 success response to the DATA command. This extension adds an enhanced status code that defines the format of the humantext after a successful delivery to allow for reliable machine-automated extraction of both the delivery ID code and the permanent token. Code: X.1.13 Sample Text: Message successfully delivered and permanent submission token generated Associated basic status code: 250 Description: This status code is returned when a message is successfully delivered and a unique delivery ID has been generated and is being provided to the sender. The humantext associated with this code has a defined format of: token delivery-id humantext Sirainen & Slusarz Expires September 25, 2019 [Page 12] Internet-Draft SMTP: Submission Token March 2019 8. Examples Example 1: Remote Client using a temporary token to deliver a message via a Token Server [...TLS layer negotiated...] C: LHLO sender.example.com S: 250-foo.com S: 250-ENHANCEDSTATUSCODES S: 250 STOKEN C: AUTH STOKEN dXNlckBmb28uY29tXDBzNnhXMTVoOURo S: 235 2.7.0 OK C: MAIL FROM: S: 250 2.1.0 OK C: RCPT TO: STOKEN=s6xW15h9Dh MYSTOKEN=Enm3HX76Mb S: 250 2.1.5 OK C: RCPT TO: STOKEN=mfpWamXp5L MYSTOKEN=H4tGNfh6Us S: 250 2.1.5 OK C: DATA S: 354 OK C: [...message data...] C: . S: 250 2.1.13 etLBdTj1iG NRaaVe83QN Saved S: 250 2.1.13 bS6zMW8Hrk VddCEQDVyp Saved Example 2: Remote Client using permanent token to deliver a message via a Token Server C: LHLO sender.example.com S: 250-foo.com S: 250-ENHANCEDSTATUSCODES S: 250 STOKEN C: AUTH STOKEN dXNlckBmb28uY29tXDB6NEpIbVVOSks0 S: 235 2.7.0 OK C: MAIL FROM: S: 250 2.1.0 OK C: RCPT TO: STOKEN=z4JHmUNJK4 MYSTOKEN=YlcDrrLZEC S: 250 2.1.5 OK C: RCPT TO: STOKEN=m6Cn9lIKjU MYSTOKEN=kAT0G96njA S: 250 2.1.5 OK C: DATA S: 354 OK C: [...message data...] C: . S: 250 2.1.12 imXtPChKDO Saved S: 250 2.1.13 CXJSmLdbeh 2WXuXmKG15 Saved and new token returned Sirainen & Slusarz Expires September 25, 2019 [Page 13] Internet-Draft SMTP: Submission Token March 2019 Example 3: TODO - Error examples 9. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in ABNF [RFC5234]. It includes definitions from SMTP [RFC5321]. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. esmtp-keyword /= "STOKEN" / "MYSTOKEN" token = string ; TODO delivery-id = string ; TODO 10. IANA Considerations 10.1. SMTP Extension Registration Section 2.2.2 of SMTP [RFC5321] defines the the procedure for registering a new SMTP extension. It is requested that IANA registers the new SMTP extension STOKEN using the details provided in Section 3 of this document. 10.2. Enhanced Status Code Registration Section 2.3 of RFC 5248 [RFC5248] defines the procedure for registering a new enumerated status code in the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry". It is requested that IANA registers the new enhanced status codes using the details provided in Section 5.4.1.1 and Section 7.4.1 of this document. 11. Security Considerations TODO SPF/DKIM Remote authentication Storage of tokens Interception of temporary token. Sirainen & Slusarz Expires September 25, 2019 [Page 14] Internet-Draft SMTP: Submission Token March 2019 DoS. SPAM - still need to scan! Token use increases trust, but does not guarantee it. 12. References 12.1. Normative References [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, DOI 10.17487/RFC2033, October 1996, . [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, DOI 10.17487/RFC2034, October 1996, . [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types Registration", RFC 3848, DOI 10.17487/RFC3848, July 2004, . [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC6186] Daboo, C., "Use of SRV Records for Locating Email Submission/Access Services", RFC 6186, DOI 10.17487/RFC6186, March 2011, . [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, . Sirainen & Slusarz Expires September 25, 2019 [Page 15] Internet-Draft SMTP: Submission Token March 2019 [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, . 12.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, DOI 10.17487/RFC4954, July 2007, . [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, DOI 10.17487/RFC5248, June 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Appendix A. Change History (To be removed by RFC Editor before publication) Acknowledgments The authors would like to thank the following people for their comments and contributions to this document: TODO. Authors' Addresses Timo Sirainen Open-Xchange Oy Lars Sonckin kaari 12 Espoo 02600 FI Email: timo.sirainen@open-xchange.com Sirainen & Slusarz Expires September 25, 2019 [Page 16] Internet-Draft SMTP: Submission Token March 2019 Michael M. Slusarz Open-Xchange Inc. 530 Lytton Avenue Palo Alto, California 94301 US Email: michael.slusarz@open-xchange.com Sirainen & Slusarz Expires September 25, 2019 [Page 17]