Mail Token Exchange Protocol

Initially written starting the 7th of October, 2022 a.d., at 04:25 AM UTC, by Amelia Bjornsdottir (she, they).

I will speak very plainly and curtly here. I am tired and currently slacking from Valgrinding mxf-remote.

IETF RFC 2119 applies

To the extent that this document proposes a protocol or a requirement, the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in IETF RFC 2119 and IETF RFC 8174.

Background

Tor does not give you a source identity for connections you receive. The best that you get is that they’re from Tor. This makes email impractical - right? Wrong.

The SMTP exchange requires nothing special within Tor, except for one thing - a step to contact the putative envelope sender and check that they approve of the blame for the message falling on them. In the clearnet, this is usually considered optional due to realtime blocklists and is done by contacting the Sender Policy Framework, which is in the DNS. In Tor, and in other darknets, there is no such thing.

Within, I propose an ESMTP extension which a server can challenge you to use after a MAIL FROM command, a protocol and two means of connecting to its server - via a second ESMTP extension (useful if you are using i2p, rather than Tor, as most i2p clients do not support port numbers - i2p does support source identity, but it is irretrievable to a mailserver and in any case is not useful even if it was retrievable), and directly via a TCP port inside of Tor only (the yet-unassigned port 6211).

The Mail Token Exchange Protocol

After receiving a MAIL FROM: request from the X-MTEP-capable sender-ESMTP, challenging said sender-ESMTP and receiving a token in response, the recipient-ESMTP connects to this server on the onion or other address of the right-hand side of the putative sender (so for a MAIL FROM: of <a@xxx.onion> it tries to connect to the MTEP server at xxx.onion), and sends a netstring of the following elements:

• A netstring of a command name, to indicate the type of the request to the MTEP server. The only commands we register are “?”, meaning “do you know this token?”, and taking one argument, and “Q”, meaning “I’m done”, and taking one argument. Both are case sensitive. Any other command MUST cause the server to respond with a permanent error with a text portion beginning “5.5.1” - referencing the ESMTP Enhanced Status Code 5.5.1. For instance, a server could respond with a netstring encapsulating the text “D5.5.1 Command not understood. I only understand ?, and Q.”
• A netstring of an opaque token as supplied by the sender-ESMTP.

The response of an MTEP server MUST be a single netstring whose first character is one of:

• K, morally equivalent to an ESMTP 2xx 2.x.x (i.e. previous transaction succeeded)
• I, morally equivalent to an SMTP 3xx (i.e. previous transaction succeeded, waiting for more information)
• Z, morally equivalent to an ESMTP 4xx 4.x.x (i.e. previous transaction failed for temporary causes)
• D, morally equivalent to an ESMTP 5xx 5.x.x (i.e. previous transaction failed for persistent causes)

The response of an MTEP server SHOULD, and in cases of errors MUST, then immediately contain an SMTP Enhanced Status Code relevant to the sense of the response. The first numeral of the ESC MAY be omitted as it is redundant; examples will be shown with the first numeral.

We document an example exchange between a recipient (client - MTEPC, SMTPS) and a sender (server - MTEPS, SMTPC). Note that the MTEP token supplied by the sender was not recognised by the server they claimed to be sending on the authority of.

SMTPS: 220 xxx.onion mxf-smtpd ESMTP
SMTPC: EHLO yyy.onion
SMTPS: 250-xxx.onion mxf-smtpd
SMTPS: 250-X-MTEP
SMTPS: 250-PIPELINING
SMTPS: 250-ENHANCEDSTATUSCODES
SMTPS: 250-SIZE 4000000
SMTPS: 250 8BITMIME
SMTPC: MAIL FROM:a@yyy.onion
SMTPS: 354 3.7.0 MTEP is required - please supply an MTEP token.
SMTPC: MTEP unvanquished
SMTPS: 354 3.7.0 Verifying…
// SMTPS then connects to MTEPS on yyy.onion, first trying the dedicated MTEP port, then trying MTEP over ESMTP. It is assumed that the connection succeeds.
MTEPC: 22:1:?,12:unvanquished,,
MTEPS: 109:D5.7.8 Nobody here has registered that token within my expiry time for tokens - probably refuse that message.,
MTEPC: 4:1:Q,,
MTEPS: 30:K2.3.0 CYA Thanks for playing!,
// MTEPS terminates the connection after receipt of a Q command.
// The SMTPS can pretend to accept the message until the end of DATA and then provide this response, but it’s better to fail fast.
SMTPS: 550 5.7.25 MTEP validation failed - we won’t be accepting this message from you as written. Get a token from your MTEP server, and call me back.
// 5.7.25 is the SMTP ESC for a reverse DNS validation failure. It is also valid to respond with 5.7.1, meaning unauthorized, message refused.
// SMTPS may disconnect immediately, or it may wait for SMTPC to obtain a valid token and try the message again.


The text after the ESC is insignificant - it is to be displayed to a putative user, if the matter is interactive. It is OPTIONAL; user interface programs SHOULD generate their own status text if absent. If it exists, it MUST NOT be mean, derogatory, insulting or prejudiced, and a mean, derogatory, insulting or prejudiced MTEP server is considered non-compliant with the protocol.

If a goodbye message is produced after a quit command, it MUST begin with a K, it SHOULD have an ESC of 2.3.0 indicating success related to a mail system status not otherwise specified, it MUST then have a space, the word CYA in all caps, then a space, then one of a rota of different goodbye messages that is implementation-defined and need not be in English. An MTEPC MUST consider a dry connection closure or an I, Z or D response to Q to be equivalent to a K2.3.0.

Some suggested farewells:

• “Thanks for playing!”
• “Hope you hear back from them soon!” - a farewell with a sense like this should only be used if there was a successful token validation, but is valid even without.
• “Nice talking with you!”
• “Contact the admin at a@yyy.onion if you have any problems with messages you’ve verified through me.”

Contrary to practice with QMTP and QMQP, MTEP servers should accept carriage returns and linefeeds after commas.

Please note that mxf-smtpd does not actually implement MTEP.

The ESMTP extension X-MTEP

The following extension to ESMTP is proposed:

• an EHLO keyword of “X-MTEP” is supplied by the (recipient) server
• that keyword does not have any parameters. If one is supplied, it must be ignored. It may be the word OPTIONAL, but this is meaningless as the presence of this keyword indicates that the performance of MTEP is required.
• an SMTP verb, MTEP, is defined, with one required argument which is up to 255 characters long.

This indicates that a recipient requires X-MTEP. A client that understands this and is not prepared to perform MTEP must instruct its caller to return a permanent failure delivery status notification with the SMTP ESC of 5.3.3, or a QMTP return beginning D5.3.3 or D.3.3.

D5.5.5, D5.7.0, D5.7.1, D5.7.23, D5.7.25, or D5.7.27 may be returned by recipient servers to indicate MTEP failing. Their senses should conform to the SMTP ESC senses of these codes, other than specific security policies should be replaced with MTEP (for 23 or 25).

The ESMTP extension X-STARTMTEP

The following extension to ESMTP is proposed:

• an EHLO keyword of “X-STARTMTEP” is supplied by the (recipient) server
• that keyword does not have any parameters. If one is supplied, it must be ignored.
• an SMTP verb, STARTMTEP, is defined, with zero required arguments.

Running STARTMTEP should produce a similar response to STARTTLS, except that instead of continuing the SMTP conversation in TLS ciphertext, it changes the SMTP conversation into an MTEP conversation, with the different encapsulation rules of MTEP, vi⁊. netstrings with optional interposed returns instead of CRLF between commands, until a quit command under MTEP is issued (a netstring of the ASCII character capital Latin letter Q), at which point the conversation becomes an SMTP conversation again. STARTMTEP MAY be used over a connection where STARTTLS has been issued and successfully negotiated, though this would be redundant since this protocol is only intended to be used on networks which are inherently encrypted. Servers implementing X-STARTMTEP and STARTTLS MUST accept STARTMTEP on connections where STARTTLS has been successfully negotiated.

X-STARTMTEP does not bear on whether a server accepts messages sent without using MTEP.