| 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
This document specifies an extension to a SMTP submission server that allows synchronous message delivery via use of a limited-privilege authentication token.
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 (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.
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 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.
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 [RFC8174] when, and only when, they appear in all capitals, as shown here.
"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
A brief overview of how submission tokens work is as follows:
The remaining sections describe the details of this process.
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).
The token format is not defined by this document and is server-dependent.
TODO: Should token format be standardized
Two categories of tokens are defined: temporary and permanent.
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
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.
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.
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.
GENSTOKEN ( "PERM" / "TEMP" ) remote-address [local-address]
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
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.
REVSTOKEN remote-address [local-address]
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.
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.
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?
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.
The Remote Client connects to the Token Server.
The Token Server for a recipient is discovered via the DNS SRV submission record.
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 record.
If Remote Client cannot determine the address for the Token Server, the message should be sent via normal mail submission 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. 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?
Once connected, and TLS is active, the client MUST send a LHLO command. This command indicates that the protocol used is LMTP. 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 command.
TODO: Need to define SASL method to do authentication. Idea: "AUTH STOKEN input", where input is a base64 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.
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?
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.
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.
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 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
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
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
Example 3: TODO - Error examples
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in ABNF. It includes definitions from SMTP.
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
Section 2.2.2 of SMTP 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.
Section 2.3 of RFC 5248 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.
TODO
| [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. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006. |
| [RFC5234] | Crocker, D. 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. |
| [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. |
| [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. and A. Melnikov, "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. |
The authors would like to thank the following people for their comments and contributions to this document: TODO.