RFC 2034

RFC 2034: SMTP Service Extension for Returning Enhanced Error Codes 🎀✨

Okay bestie, let's get into this one 💅. It's an RFC by Ned Freed of Innosoft 🦋, dated October 1996, and it's on the Standards Track 👑. It doesn't obsolete or update any other documents, so it's a fresh standalone extension 🌸. It's giving "new feature unlocked" energy 😭.

---

Status of This Memo 🌈

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 💜

1. Abstract 🧚

Okay so this memo adds an extension to the SMTP service [RFC-821, RFC-1869] 📬. The SMTP server basically glams up its responses with the enhanced mail system status codes from RFC 1893 💖. Those codes give way more informative explanations of error conditions, especially inside the delivery status notifications from RFC 1894 🔥. It's iconic, no cap.

2. Introduction 🌸

SMTP is widely and robustly deployed, but people in the Internet community have asked for extra stuff on top of it 🫶. The big one is that the modern, international, multilingual Internet needs error conditions that can be translated into different languages 🌍. RFC 1893 already defines a set of status codes for this, and RFC 1894 defines how to send that coded material to users ✨. The tricky part is that a lot of the time, the agent making the RFC 1894 delivery status notification is doing it because of errors it got from a remote SMTP server 😭.

So remote servers need a way to embed enhanced status codes in their responses, plus a way to tell the client when they're actually doing that 💅. This memo uses the SMTP extension mechanism from RFC 1869 to make that happen 🦋.

3. Framework for the Enhanced Error Statuses Extension 💖

The enhanced error statuses transport extension is laid out like this 🎀:

1. The name of the SMTP service extension defined here is Enhanced-Status-Codes.
2. The EHLO keyword value for the extension is ENHANCEDSTATUSCODES.
3. No parameter is used with the ENHANCEDSTATUSCODES EHLO keyword.
4. The text part of all 2xx, 4xx, and 5xx SMTP responses, other than the initial greeting and any response to HELO or EHLO, is prefaced with a status code as defined in RFC 1893. This status code is always followed by one or more spaces. ✨
5. No additional SMTP verbs are defined by this extension. 🌈
6. The next section specifies how support for the extension affects the behavior of a server and client SMTP. 🫶

4. The Enhanced-Status-Codes Service Extension 👑

Okay this is the main part 🔥. Servers supporting the Enhanced-Status-Codes extension MUST preface the text part of almost all response lines with a status code 💅. As in RFC 1893, the syntax of these status codes is given by this ABNF 🧚:

status-code ::= class "." subject "." detail
class       ::= "2" / "4" / "5"
subject     ::= 1*3digit
detail      ::= 1*3digit

These codes MUST appear in all 2xx, 4xx, and 5xx response lines other than the initial greeting and any response to HELO or EHLO. Note that 3xx responses are NOT included in this list 🙈.

All status codes returned by the server MUST agree with the primary response code. So a 2xx response MUST incorporate a 2.X.X code, a 4xx response MUST incorporate a 4.X.X code, and a 5xx response MUST incorporate a 5.X.X code 💖.

When responses continue across multiple lines, the same status code MUST appear at the beginning of the text in each line of the response 🎀.

Servers supporting this extension MUST attach enhanced status codes to their responses regardless of whether or not the client uses EHLO 💜.

5. Status Codes and Negotiation 🦋

This specification doesn't give clients a way to ask for status codes to be returned, or to ask that they not be returned 🙅‍♀️. A compliant server includes these codes in its responses whether or not the client expects them 💅. This is kinda different from most other SMTP extensions, where a client usually has to make a specific request before the extended server acts any differently from a plain one 🌸. Leaving out client negotiation here was totally on purpose 🫶. SMTP server error code implementation has been pretty rough, so any step toward more comprehensible error codes is something every client, extended or not, should benefit from ✨.

IMPORTANT NOTE: The use of this approach in this extension SHOULD be seen as a very special case. It MUST NOT be taken as a license for future SMTP extensions to dramatically change the nature of SMTP client-server interaction without proper announcement from the server and a corresponding enabling command from the client. 🚨

Wait, I need to fix that. The original says "should be seen" in lowercase, so it's not a key word and I shouldn't capitalise it. Here's the correct line:

IMPORTANT NOTE: The use of this approach in this extension should be seen as a very special case. It MUST NOT be taken as a license for future SMTP extensions to dramatically change the nature of SMTP client-server interaction without proper announcement from the server and a corresponding enabling command from the client. 🚨

6. Usage Example 📬

The following dialogue shows how a server uses enhanced status codes 💖:

S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 dbc.mtview.ca.us SMTP service ready
C: EHLO ymir.claremont.edu
S: 250-dbc.mtview.ca.us says hello
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<ned@ymir.claremont.edu>
S: 250 2.1.0 Originator <ned@ymir.claremont.edu> ok
C: RCPT TO:<mrose@dbc.mtview.ca.us>
S: 250 2.1.5 Recipient <mrose@dbc.mtview.ca.us> ok
C: RCPT TO:<nosuchuser@dbc.mtview.ca.us>
S: 550 5.1.1 Mailbox "nosuchuser" does not exist
C: RCPT TO:<remoteuser@isi.edu>
S: 551-5.7.1 Forwarding to remote hosts disabled
S: 551 5.7.1 Select another host to act as your forwarder
C: DATA
S: 354 Send message, ending in CRLF.CRLF.
 ...
C: .
S: 250 2.6.0 Message accepted
C: QUIT
S: 221 2.0.0 Goodbye

The client that gets these responses might then send a nondelivery notification of the general form 🦋:

   Date: Mon, 11 Mar 1996 09:21:47 -0400
   From: Mail Delivery Subsystem <mailer-daemon@ymir.claremont.edu>
   Subject: Returned mail
   To: <ned@ymir.claremont.edu>
   MIME-Version: 1.0
   Content-Type: multipart/report; report-type=delivery-status;
         boundary="JAA13167.773673707/YMIR.CLAREMONT.EDU"

   --JAA13167.773673707/YMIR.CLAREMONT.EDU
   content-type: text/plain; charset=us-ascii

      ----- Mail was successfully relayed to
            the following addresses -----

   <mrose@dbc.mtview.ca.us>

      ----- The following addresses had delivery problems -----
   <nosuchuser@dbc.mtview.ca.us>
     (Mailbox "nosuchuser" does not exist)
   <remoteuser@isi.edu>
     (Forwarding to remote hosts disabled)

   --JAA13167.773673707/YMIR.CLAREMONT.EDU
   content-type: message/delivery-status

   Reporting-MTA: dns; ymir.claremont.edu

   Original-Recipient: rfc822;mrose@dbc.mtview.ca.us
   Final-Recipient: rfc822;mrose@dbc.mtview.ca.us
   Action: relayed
   Status: 2.1.5 (Destination address valid)
   Diagnostic-Code: smtp;
    250 Recipient <mrose@dbc.mtview.ca.us> ok
   Remote-MTA: dns; dbc.mtview.ca.us
   Original-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us
   Final-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us
   Action: failed
   Status: 5.1.1 (Bad destination mailbox address)
   Diagnostic-Code: smtp;
    550 Mailbox "nosuchuser" does not exist
   Remote-MTA: dns; dbc.mtview.ca.us

   Original-Recipient: rfc822;remoteuser@isi.edu
   Final-Recipient: rfc822;remoteuser@isi.edu
   Action: failed
   Status: 5.7.1 (Delivery not authorized, message refused)
   Diagnostic-Code: smtp;
     551 Forwarding to remote hosts disabled
     Select another host to act as your forwarder
   Remote-MTA: dns; dbc.mtview.ca.us

   --JAA13167.773673707/YMIR.CLAREMONT.EDU
   content-type: message/rfc822

   [original message goes here]
   --JAA13167.773673707/YMIR.CLAREMONT.EDU--

Note that to keep things tidy, the reporting MTA left enhanced status code information out of the diagnostic-code fields it generated 🧹.

7. Security Considerations 🔐

Okay, this one's serious, so listen up 🚨. Additional detail in server responses axiomatically provides additional information about the server. It is conceivable that additional information of this sort may be of assistance in circumventing server security. The advantages of provides additional information must always be weighed against the security implications of doing so. 💀

8. References 📚

[RFC-821] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August, 1982. (August, 1982).

[RFC-1869] Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed, N., "SMTP Service Extensions", RFC 1869, November, 1995.

[RFC-1893] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January, 1996.

[RFC-1894] Moore, K., Vaudreuil, G., "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January, 1996.

9. Author Address 🦋

Ned Freed Innosoft International, Inc. 1050 East Garvey Avenue South West Covina, CA 91790 USA tel: +1 818 919 3600 fax: +1 818 919 3614 email: ned@innosoft.com