RFC 1870

RFC 1870, SMTP Service Extension for Message Size Declaration 🎀

Okay bestie, so this is RFC 1870, the SMTP Service Extension for Message Size Declaration 💖 It came out of the Network Working Group in November 1995 🦋 and it's on the Standards Track, so it's real protocol, not just vibes ✨ It's STD: 10, which means it's about SMTP, the mail protocol 👑 J. Klensin was the WG Chair at MCI 💅, N. Freed edited it at Innosoft International, Inc. 🧚, and K. Moore from the University of Tennessee is also on the author list 🌸 It obsoletes RFC 1653, so 1653 is officially retired 🫶

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 current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🌈

1. Abstract ✨

This memo adds an extension to SMTP where the client and server can chat about message size 💬 The server gets to decline a message (maybe just for now 🥺) based on the size the client estimates it to be 📏

2. Introduction 🦋

The MIME extensions let Internet mail carry all kinds of data that wasn't supported before, and that's a whole glow-up 💅 Because of that, SMTP is going to be carrying a much wider range of message sizes than it used to. That affects how many resources a server acting as a server needs, like disk space 💾

This memo uses the mechanism defined in [5] to define SMTP extensions where a client ("sender-SMTP") can declare the size of a particular message to a server ("receiver-SMTP"). The server can then say whether it is or isn't willing to accept the message based on that declared size 🙈 It also works the other way, so a server ("receiver-SMTP") can declare the maximum message size it's willing to accept to a client ("sender-SMTP") 🫶

3. Framework for the Size Declaration Extension 🧚

So here's the extension we're defining:

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 this EHLO keyword value. It's a decimal number for the fixed maximum message size in bytes that the server will accept. The syntax uses the augmented BNF notation of [2]:

size-param ::= [1*DIGIT]

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

4. One optional parameter using the keyword SIZE gets 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 uses the augmented BNF notation of [2]:

size-value ::= 1*20DIGIT

5. The maximum length of a MAIL FROM command line goes up by 26 characters, because of the possible addition of the SIZE keyword and value 📈
6. No additional SMTP verbs are defined by this extension 💅

The rest of this memo covers how support for the extension changes the behavior of an SMTP client and server 🦋

4. The Message Size Declaration service extension 🔥

An SMTP server might have a fixed upper limit on message size. Any client attempt to transfer a message bigger than that limit will fail 🙅‍♀️ On top of that, a server usually has limited space to store incoming messages. So a transfer can also fail because there's no storage space left, but it might work later on 🥺

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

An SMTP client that wants to relay large content can issue the EHLO command to start an SMTP session, to see whether the server supports any of several service extensions 👀 If the server responds to EHLO with code 250 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 client attempt to transfer a message bigger 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 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 a message it wants to transfer 📏 If the server figures out that transferring a message of that size would fail, it may return an appropriate error code 🫶

5. 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. It's what the SMTP client transmits after receiving 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. Any attempt to transfer a message larger than the fixed maximum message size will always fail 🙈 The fixed maximum message size might be an implementation artifact of the SMTP server, or the server's administrator might choose it 👑

The declared message size is a client's estimate of the message size for a particular message 🧚

6. The extended MAIL command 💌

The extended MAIL command is what a client uses when it wants to tell a server how big the message it's about to send is 🎀 It's identical to the MAIL command defined in [1], except that a SIZE parameter shows up after the address 💖

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

The value of the SIZE parameter is a decimal representation of the declared message size in octets. It should include the message header, 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 computing the exact message size can be infeasible, so the client may use a heuristically-derived estimate instead 🧠 Those heuristics should be picked so that the declared message size is usually larger than the actual message size. That makes counting or not counting the SMTP DATA dots kind of an academic point 🤓

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

6.1. Server action on receipt of the extended MAIL command 🧚

When a server receives 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 the message can be delivered or relayed to each of its recipients 💾

A server may 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 may come back 🫶

1. If the server currently doesn't have enough resources to accept a message of the indicated size, but might be able to accept 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 allowed, but not required, to accept a message that's actually larger than what was declared in the extended MAIL command 🌈 That could happen if the client used a size-estimation heuristic that was inaccurate 🤷‍♀️

6.2. Client action on receiving response to extended MAIL command 💅

Once the client gets the server's response to the extended MAIL command, it does the following 👑

1. If the code "452 insufficient system storage" comes back, 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 try sending the message to the server again later on ⏰
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 try sending additional messages) or a QUIT command. After that, the client should declare the message undeliverable and send an 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 isn't an absolute guarantee that the message transfer will succeed 😬 SMTP clients using the extended MAIL command still have to be ready to handle both temporary and permanent error reply codes (including codes 452 and 552). That can happen right after issuing the DATA command, or after the message has been transferred 🫶

6.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 message actually transferred is bigger 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 allowed to declare a message as smaller than its actual size. But in that case, a successful (250) reply code is no promise that the server will accept the message or has enough resources to do so 😅 The server may reject that kind of message after its DATA transfer 🙈

6.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 🚫

7. Minimal usage 🌸

Okay bestie, so a "minimal" client 🧚 can use this extension in a super chill way. It just compares its (maybe estimated) size of the message it wants to relay with the server's fixed maximum message size, which is the parameter to the SIZE keyword in the EHLO response. Boom, it knows whether the server will ever accept the message 🙈. A minimal client doesn't need to declare sizes with the extended MAIL command. ngl though, it also won't be able to find out about temporary limits caused by server resource limitations, or about per-recipient limits on message size 💀

A minimal server 💅 can just use the SIZE keyword value to tell the client the size of the biggest message it'll accept, or to say there's no fixed limit on message size at all. This server 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 it has one). It doesn't need to detect "temporary" limitations on message size though 🦋

The number after the SIZE keyword in the EHLO response is optional 🎀 If you leave the parameter off entirely, that means the server isn't advertising 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 containing a SIZE specification until it has checked that there are enough resources to transfer a message of the declared size and to hold 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 🍓

---

8. Example 🦋

This example shows size declaration in action, including a couple of permanent and temporary failures. Watch the vibes shift as the server responds 👀

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: 221 Goodbye

---

9. Security Considerations 🔐

⚠️ Serious bestie moment ahead, so read this carefully.

The size declaration extensions in this memo could conceivably be used to make crude service denial attacks easier to pull off. 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 involving trusted systems and possible release of information through the mechanisms described in this RFC 🙃

---

10. Acknowledgements 🫶

This document grew out of an earlier Working Group contribution that was still in progress. Huge thanks to Jim Conklin, Dave Crocker, Neil Katin, Eliot Lear, Marshall T. Rose, and Einar Stefferud, who gave extensive comments on earlier drafts of both this document and the previous memo 💜

---

11. 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", STD 11, RFC 1869, MCI, Innosoft International, Inc., Dover Beach Consulting, Inc., Network Management Associates, Inc., Brandenburg Consulting, November 1995.
• [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, BBN, January 1986.

---

12. Chair, Editor, and Author Addresses 🎀

Here are the lovely people behind the document, so you know exactly who to message 💖

John Klensin, WG Chair
MCI
2100 Reston Parkway
Reston, VA 22091

Phone: +1 703 715-7361
Fax: +1 703 715-7436
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