RFC 1653

RFC 1653: SMTP Service Extension for Message Size Declaration 💌

okay bestie, this is RFC 1653 🎀 It's a Standards Track doc dated July 1994, from the Network Working Group. The authors are J. Klensin (WG Chair at MCI), N. Freed (Editor at Innosoft), and K. Moore (University of Tennessee) ✨ It obsoletes RFC 1427, so 1427 is the old version this one replaces 💀

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 "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🦋

Abstract

So here's the tea 🍵 This memo defines an SMTP service extension where a client and a server can chat, which gives the server a chance to turn down a message (maybe just for now) based on the client's estimate of how big it is 🙈

1. Introduction ✨

MIME opened the door to all kinds of data that Internet mail couldn't carry before 🌈 That means SMTP is gonna be carrying a way wider range of message sizes, and that hits how much stuff a server needs, like disk space 💾

This memo uses the mechanism defined in [5] to extend SMTP. A client ("sender-SMTP") can declare the size of a message to a server ("receiver-SMTP"), and then the server can tell the client whether it's willing to accept that message based on the declared size. The server can also declare the maximum message size it's willing to accept to the client 👑

2. Framework for the Size Declaration Extension 🧚

Here's the extension we're defining, bestie:

1. The name of the SMTP service extension is "Message Size Declaration" 💖
2. The EHLO keyword value for this extension is SIZE 🍓
3. One optional parameter is allowed with that EHLO keyword value. It's a decimal number for the fixed maximum message size in bytes that the server will accept. The syntax of the parameter, in the augmented BNF notation of [2], is:

size-param ::= [1*DIGIT]

A parameter value of 0 (zero) means no fixed maximum message size is in force. If the parameter is omitted, no information is conveyed about the server's fixed maximum message size 🌸

4. One optional parameter using the keyword "SIZE" is added to the MAIL FROM command. The value is a decimal number for the size of the message that's about to be transmitted. The syntax of the value, in the augmented BNF notation of [2], is:

size-value ::= 1*DIGIT

5. No additional SMTP verbs are defined by this extension 🫶

The rest of this memo explains how support for the extension changes what an SMTP client and server do 💅

3. The Message Size Declaration service extension 🦋

An SMTP server can have a fixed upper limit on message size. Any attempt to transfer a message bigger than that limit will fail. On top of that, a server usually has limited space for incoming messages, so a transfer can also fail because there's no storage left. The good news is that one might succeed later 🥹

A client using the unextended SMTP protocol defined in [1] can only find out about these failures after sending the entire message, and then the server throws that whole message away 😭 But if both the client and server support the Message Size Declaration service extension, these conditions can be caught before any transfer is attempted. Iconic 🔥

A client that wants to relay a large content sends the EHLO command to start an SMTP session, so it can check whether the server supports any of the service extensions. If the server replies with 250 to EHLO and the response includes the EHLO keyword value SIZE, then the Message Size Declaration extension is supported ✨

If a numeric parameter follows the SIZE keyword value in the EHLO response, it tells you the size of the largest message the server is willing to accept. Any attempt to transfer a message larger than that limit will be rejected with a permanent failure (552) reply code 💀

A server that supports the Message Size Declaration extension will accept the extended version of the MAIL command, which is described below. When the server supports it, a client can use the extended MAIL command (instead of the MAIL command defined in [1]) to declare an estimate of the size of the message it wants to transfer. The server can then return an appropriate error code if it figures out that transferring a message of that size would fail 🧠

4. Definitions 📚

The message size is the number of octets, including CR-LF pairs, but not the SMTP DATA command's terminating dot or doubled quoting dots, that the SMTP client is going to transmit after it gets reply code 354 to the DATA command 💖

The fixed maximum message size is the message size of the largest message a server is ever willing to accept. An attempt to transfer any message larger than the fixed maximum message size will always fail 😤 It might be an implementation artifact of the SMTP server, or the server's administrator might choose it 👑

The declared message size is the client's estimate of the message size for one particular message 🎀

4. The extended MAIL command 💌

The extended MAIL command is sent by a client when it wants to tell a server how big the message is going to be. It's identical to the MAIL command defined in [1], except that a SIZE parameter shows up after the address 🌈

The complete syntax of this extended command is defined in [5]. The esmtp-keyword is "SIZE", and the syntax for esmtp-value is the syntax for size-value shown above 🧚

The value of the SIZE parameter is a decimal representation of the declared message size in octets. This number should include the message header, the body, and the CR-LF sequences between lines, but not the SMTP DATA command's terminating dot or doubled quoting dots. Only one SIZE parameter can be specified in a single MAIL command 🍓

Ideally, the declared message size is equal to the true message size. But since computing the exact message size can be infeasible, the client can use a heuristically-derived estimate. Those heuristics should be chosen so that the declared message size is usually larger than the actual message size. (This has the effect of making the counting or non-counting of SMTP DATA dots largely an academic point 🤓)

NOTE: Servers MUST NOT use the SIZE parameter to determine end of content in the DATA command. 🚫

5.1. Server action on receipt of the extended MAIL command 🛎️

When a server gets an extended MAIL command with a SIZE parameter, it should check whether the declared message size is bigger than its fixed maximum message size. If the declared message size is smaller than the fixed maximum message size, the server may also want to check whether it has enough resources to buffer a message of the declared size and keep it in stable storage until it can be delivered or relayed to each of its recipients 🫧

A server can respond to the extended MAIL command with any of the error codes defined in [1] for the MAIL command. On top of those, one of the following error codes can come back:

1. If the server doesn't currently have enough resources to accept a message of that size, but might be able to take it later, it responds with code "452 insufficient system storage" 🥺
2. If the indicated size is larger than the server's fixed maximum message size, the server responds with code "552 message size exceeds fixed maximium message size" 🙅‍♀️

A server is permitted, but not required, to accept a message that's actually larger than what was declared in the extended MAIL command. This could happen if the client used a size-estimation heuristic that was inaccurate 🤷‍♀️

5.2. Client action on receiving response to extended MAIL command 📬

When the client gets the server's response to the extended MAIL command, it does the following:

1. If the code "452 insufficient system storage" is returned, the client should next send either a RSET command (if it wants to try sending other messages) or a QUIT command. Then the client should repeat the attempt to send the message to the server at a later time ⏰
2. If the code "552 message exceeds fixed maximum message size" is received, the client should immediately send either a RSET command (if it wants to attempt to send additional messages) or a QUIT command. Then the client should declare the message undeliverable and return appropriate notification to the sender (if a sender address was present in the MAIL command) 🚨

A successful (250) reply code in response to the extended MAIL command is not an absolute guarantee that the message transfer will succeed 🥲 SMTP clients using the extended MAIL command must still be prepared to handle both temporary and permanent error reply codes (including 452 and 552), either right after issuing the DATA command or after the message has been transferred 💪

5.3. Messages larger than the declared size. 📏

Once a server has agreed (via the extended MAIL command) to accept a message of a particular size, it should not return a 552 reply code after the transfer phase of the DATA command, unless the actual size of the message transferred is greater than the declared message size. A server may also choose to accept a message that's a bit larger than the declared message size 🫶

A client is permitted to declare a message to be smaller than its actual size. But in that case, a successful (250) reply code is no assurance that the server will accept the message or has enough resources to do so. The server may reject that message after its DATA transfer 😬

5.4. Per-recipient rejection based on message size. 🎯

A server that implements this extension may return a 452 or 552 reply code in response to a RCPT command, based on its unwillingness to accept a message of the declared size for a particular recipient 🙅

1. If a 452 code is returned, the client may requeue the message for later delivery to the same recipient 🔁
2. If a 552 code is returned, the client may not requeue the message for later delivery to the same recipient 💀

6. Minimal usage 🎀

Okay so a "minimal" client is giving chill 🧚. It can just take its (maybe estimated) size for the message it wants to relay and compare that to the server's fixed max message size, the number that comes with the SIZE keyword in the EHLO response. That tells it whether the server will ever accept the message 💅. A minimal client doesn't even have to declare sizes with the extended MAIL command. BUT ngl, it also won't be able to find out about temporary limits from server resource limitations, or about per-recipient limits on message size 💀.

A minimal server that uses this service extension can just use the SIZE keyword value to tell the client how big the largest message it'll accept is, or to say there's no fixed limit on message size at all 🌸. It must accept the extended MAIL command and return a 552 reply code if the client's declared size goes over its fixed size limit (if there is one). It doesn't have to detect "temporary" limitations on message size, though 🫶.

The numeric parameter to the EHLO SIZE keyword is optional ✨. If the parameter is left off entirely, that means the server doesn't advertise a fixed maximum message size 🦋. Now here's the tea 🍵: a server that returns the SIZE keyword with no parameter in response to EHLO may not give a positive (250) response to an extended MAIL command with a SIZE specification unless it first checks that there are enough resources to transfer a message of the declared size and to keep it in stable storage until it can be relayed or delivered to its recipients. If possible, the server should actually reserve enough storage space to transfer the message. Main character energy for sure 👑.

---

7. Example 💖

The following example shows size declaration in action, with some permanent and temporary failures 😭.

   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 SIZE 1000000
   C: MAIL FROM:<ned@thor.innosoft.com> SIZE=500000
   S: 250 Address Ok.
   C: RCPT TO:<ned@innosoft.com>
   S: 250 ned@innosoft.com OK; can accomodate 500000 byte message
   C: RCPT TO:<ned@ymir.claremont.edu>
   S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU
   C: RCPT TO:<ned@hmcvax.claremont.edu>
   S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU
   C: DATA
   S: 354 Send message, ending in CRLF.CRLF.
    ...
   C: .
   S: 250 Some recipients OK
   C: QUIT
   S: 250 Goodbye

---

8. Security Considerations 🔥

Okay, this section is serious bestie, so listen up 🙈. The size declaration extensions described in this memo could conceivably be used to facilitate crude service denial attacks 💀. Specifically, both the information in the SIZE parameter and the use of the extended MAIL command make it somewhat quicker and easier to come up with an efficacious service denial attack. However, unless implementations are very weak, these extensions don't create any vulnerability that hasn't always existed with SMTP 🛡️. Also, no issues are addressed about trusted systems and possible release of information through the mechanisms described in this RFC 🔒.

---

9. Acknowledgements 🫶

This document was derived from an earlier Working Group draft contribution. Jim Conklin, Dave Crocker, Neil Katin, Eliot Lear, Marshall T. Rose, and Einar Stefferud gave extensive comments on earlier drafts of both this and the previous memo. Iconic squad 👑🌈.

---

10. References 📚

[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982.

[2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982.

[3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions", RFC 1521, Bellcore, Innosoft, September 1993.

[4] Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC 1522, University of Tennessee, September 1993.

[5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach Consulting, Inc., Network Management Associates, Inc., Silicon Graphics, Inc., July 1994.

[6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, BBN, January 1986.

---

11. Chair, Editor, and Authors' Addresses 💌

John Klensin, WG Chair
MCI Data Services Division
2100 Reston Parkway, 6th floor
Reston, VA 22091
USA

Phone:: 1 703 715 7361
Fax: +1 703 715 7435
EMail: klensin@mci.net


Ned Freed, Editor
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA

Phone:: +1 818 919 3600
Fax: +1 818 919 3614
EMail: ned@innosoft.com


Keith Moore
Computer Science Dept.
University of Tennessee
107 Ayres Hall
Knoxville, TN 37996-1301
USA

EMail: moore@cs.utk.edu