RFC 1985

RFC 1985: SMTP Service Extension for Remote Message Queue Starting 💌 (Part 1 of 2)

Okay bestie, this is RFC 1985 🦋 It came out of the Network Working Group, written by J. De Winter from Wildbear Consulting, Inc., and dated August 1996. It's a Standards Track doc, so it's a real protocol spec and not just vibes. The header doesn't list any Obsoletes or Updates line, so it isn't replacing or patching another RFC 💅

---

Status of This Memo ✨

This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone 🌈

Abstract 🌸

This memo defines an extension to the SMTP service where an SMTP client and server can talk to each other, so the server gets a chance to start processing its queues for messages headed to a given host. It's meant for startup conditions, and also for mail nodes that only have transient connections to their service providers 💌

1. Introduction 💖

Okay so, the TURN command was a real attempt at the problem of having to start mail queue processing on a remote machine. BUT it has a huge security loophole 😭 There's no verification of the remote host name, so a rogue system could use TURN to download mail meant for some other site. Not it 💀

So this memo introduces the ETRN command 🎀 It uses the mechanism defined in [4] to extend the SMTP service. A client ("sender-SMTP") can ask the server ("receiver-SMTP") to start processing its mail queues for messages that are waiting at the server for the client machine. If there are any messages at the server for the client, the server should create a new SMTP session and send them right then ✨

2. Framework for the ETRN Extension 🧚

Here's the extension that's getting defined:

1. The name of the SMTP service extension is "Remote Queue Processing Declaration".
2. The EHLO keyword value for this extension is ETRN, with no associated parameters.
3. One additional verb, ETRN, with a single parameter that specifies the name of the client(s) to start processing for.
4. No additional SMTP verbs are defined by this extension.

The rest of the memo covers how supporting this extension changes what an SMTP client and server do 👑

3. The Remote Queue Processing Declaration service extension 🍓

So, small companies want to save money, which means they only keep transient connections to their service providers 💸 Some client sites also need their mail to arrive fast, so forcing the queues on their provider's server can be way better than waiting for the retry timeout to happen 🏃‍♀️

Both of these could already be solved with the TURN command from [1]... if it weren't for that big security loophole. Here's the tea: TURN reverses the direction of the SMTP connection and just assumes the remote host is being honest about its name. There's no documented stipulation for checking the authenticity of the remote host name given in HELO or EHLO 🙈 So most SMTP and ESMTP implementations skip TURN entirely to dodge it. Not a vibe.

ETRN is the fix 🦋 It's the extended turn command, designed with those two situations in mind while also paying attention to the problems TURN has. The loophole is avoided by asking the server to start a new connection aimed at the specified client. That way, the server has a lot more certainty that it's actually talking to the correct SMTP client ✅

You can see ETRN as a more immediate version of the retry queues that show up in most SMTP implementations 💜 Also, since the command takes a single parameter (the name of the remote host(s) to start the queues for), the server gets to decide whether to honour the request or deny it for local administrative reasons. Boundaries, babe 🫶

4. Definitions 📚

Remote queue processing means that, using an SMTP or ESMTP connection, the client can ask the server to start processing parts of its messaging queue. This processing uses the existing SMTP infrastructure and will happen at some point after it's initiated 🔥

• Server host: the node that's responding to the ETRN command.
• Client host: the node that's initiating the ETRN command.

The remote host name is a plain-text field that names the remote host(s). It may also include an alias for the specified remote host, or special commands to identify other types of queues 🧩

5. The extended ETRN command 💅

The extended ETRN command is what the client host sends when it wants to start SMTP queue processing for a given server host 💌 The syntax goes like this:

ETRN [<option character>]<node name><CR><LF>

You can send this any time once a session is established, as long as there's no transaction happening. So it's illegal between a MAIL FROM: command and the end of the DATA commands and responses 🙅‍♀️

The node name must be a fully qualified domain name for the node, which may refer to a CNAME or MX pointer in the DNS. If an alias is used for the node, you might need multiple ETRN commands to start processing for it, since it may be listed at the remote site under multiple names. Section 5.3 covers an option that can help with this too 🧠

The option character normally isn't used 🤷‍♀️

5.1 Server action on receipt of the extended ETRN command 🖥️

When the server host gets the ETRN command, it should take a look at the node name in the command and make a local decision about whether it should honour the request. If not, the appropriate error codes should be sent back to the client 🙅‍♀️

Otherwise, the server host should force its retry queues to start sending messages to that remote site, using another SMTP connection. At the moment, there's no requirement that a connection must occur, or that it must occur within a given time frame. This should be noted for the case where there are no messages for the client host at the server host, and only the 250 response is used 📝

Since processing the queues may take an indeterminate amount of time, this command should return immediately with a response to the client host. The valid return codes for this command are:

250 OK, queuing for node <x> started
251 OK, no messages waiting for node <x>
252 OK, pending messages for node <x> started
253 OK, <n> pending messages for node <x> started
458 Unable to queue messages for node <x>
459 Node <x> not allowed: <reason>
500 Syntax Error
501 Syntax Error in Parameters

The 250 response code doesn't mean messages will be sent to that system, just that the queue has started and some action will happen 🚀 If the server can support it, the 251, 252 or 253 response codes should be used to give the client side more info. Then, if there are messages waiting for the client side node, those response codes can be used as a signal for when there are no more pending messages in the queue for that node 👀

The 458 and 459 result codes should be used to tell the client host why the action wasn't performed. If the syntax of the request isn't correct, the 500 and 501 result codes should be used 💀

5.2 Client action on receiving response to extended ETRN command 📬

If one of the 500 level error codes (550 or 551) comes back, the client should assume that the protocol isn't supported at the remote host, or that it hasn't been implemented correctly on the client or server host. In that case, multiple ETRN commands (dealing with the system's aliases) should not be sent 🙃

If the 250 response comes back, the client host can assume the server host found its request satisfactory, and that it will send any queued messages. This might involve going through a very large retry queue, so it may take some time ⏳

If a 400 level response comes back, the client can assume the server supports the command, but that for some local reason it doesn't want to accept the ETRN command as is. Most of the time that means there's a list of nodes it will accept the command from, and the current client isn't on that list 📋 The 459 response code is there to give a more in-depth reason why the remote queuing can't be started.

---

Part 2 picks up with Section 5.3 next 👀🦋

7. Example ✨

okay so here's a walkthrough of remote queue processing with some permanent and temporary failures, so you can see it in action 💅

S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
C: EHLO ymir.claremont.edu
S: 250-sigurd.innosoft.com
S: 250-EXPN
S: 250-HELP
S: 250 ETRN
C: ETRN
S: 500 Syntax Error
C: ETRN localname
S: 501 Syntax Error in Parameters
C: ETRN uu.net
S: 458 Unable to queue messages for node uu.net
...

C: ETRN sigurd.innosoft.com
S: 250 OK, queuing for node sigurd.innosoft.com started
C: ETRN innosoft.com
S: 250 OK, queuing for node innosoft.com started

OR

C: ETRN sigurd.innosoft.com
S: 251 OK, no messages waiting for node sigurd.innosoft.com
C: ETRN innosoft.com
S: 252 OK, pending messages for node innosoft.com started
C: ETRN mysoft.com
S: 253 OK, 14 pending messages for node mysoft.com started

...
C: ETRN foo.bar
S: 459 Node foo.bar not allowed: Unable to resolve name.
...
C: QUIT
S: 250 Goodbye

the 458 on uu.net is a permanent no, and the 459 on foo.bar is the one that can't resolve 🙈 the rest is just the happy path with a few bumps 🌸

---

8. Security Considerations 🔥

okay this part is serious, bestie, so read it carefully 💀

ETRN doesn't break any security stuff from existing SMTP or ESMTP protocols 🫶 it just shortens how long a client has to wait before its messages get retried, and that's it.

Precautions should be taken so that any client server can only use the @ and # option characters for systems that make sense. if there's no sanity checking on the parameters, things could get congested 😭 the example to watch out for is someone asking to release @com, which would release mail for any address that ends with com. chaotic 💀

---

9. Acknowledgements 🎀

this document came together with so much love from the users of our products 💖 they gave input on the functionality they wanted to see in the software they bought, and honestly that's iconic of them 🦋

---

10. References 📚

[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.

[2] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United Nations University, Innosoft International, Inc., Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, February 1993.

---

11. Author's Address 🧚

the author is Jack De Winter, and you can find him here 💜

Jack De Winter
Wildbear Consulting, Inc.
17 Brock Street
Kitchener, Ontario, Canada
N2M 1X2

Phone: +1 519 576 3873
EMail: jack@wildbear.on.ca