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: <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-address> 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:
<delivery-address> 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:<user@example.com>
S: 250 2.1.0 OK
C: RCPT TO:<user@foo.com> STOKEN=s6xW15h9Dh MYSTOKEN=Enm3HX76Mb
S: 250 2.1.5 OK
C: RCPT TO:<user2@foo.com> STOKEN=mfpWamXp5L MYSTOKEN=H4tGNfh6Us
S: 250 2.1.5 OK
C: DATA
S: 354 OK
C: [...message data...]
C: .
S: 250 2.1.13 <user@foo.com> etLBdTj1iG NRaaVe83QN Saved
S: 250 2.1.13 <user2@foo.com> 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:<user@example.com>
S: 250 2.1.0 OK
C: RCPT TO:<user@foo.com> STOKEN=z4JHmUNJK4 MYSTOKEN=YlcDrrLZEC
S: 250 2.1.5 OK
C: RCPT TO:<user2@foo.com> STOKEN=m6Cn9lIKjU MYSTOKEN=kAT0G96njA
S: 250 2.1.5 OK
C: DATA
S: 354 OK
C: [...message data...]
C: .
S: 250 2.1.12 <user@foo.com> imXtPChKDO Saved
S: 250 2.1.13 <user2@foo.com> 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,
<https://www.rfc-editor.org/info/rfc2033>.
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced
Error Codes", RFC 2034, DOI 10.17487/RFC2034, October
1996, <https://www.rfc-editor.org/info/rfc2034>.
[RFC3848] Newman, C., "ESMTP and LMTP Transmission Types
Registration", RFC 3848, DOI 10.17487/RFC3848, July 2004,
<https://www.rfc-editor.org/info/rfc3848>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422,
DOI 10.17487/RFC4422, June 2006,
<https://www.rfc-editor.org/info/rfc4422>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC6186] Daboo, C., "Use of SRV Records for Locating Email
Submission/Access Services", RFC 6186,
DOI 10.17487/RFC6186, March 2011,
<https://www.rfc-editor.org/info/rfc6186>.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
<https://www.rfc-editor.org/info/rfc6409>.
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,
<https://www.rfc-editor.org/info/rfc8314>.
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
Extension for Authentication", RFC 4954,
DOI 10.17487/RFC4954, July 2007,
<https://www.rfc-editor.org/info/rfc4954>.
[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,
<https://www.rfc-editor.org/info/rfc5248>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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]