Summary

  • Original SMTP could reveal a size or storage failure only after the sender transmitted the complete DATA object and the receiver discarded it.
  • RFC 1870 let a server advertise a fixed maximum with EHLO and a client declare an estimated octet count on MAIL FROM. Permanent policy could return 552; temporary scarcity could return 452.
  • The number was intentionally weak evidence. It did not terminate DATA, reserve all later storage, authenticate content or make a successful MAIL reply a guarantee of relay or delivery.

When rejection came after the expense

RFC 821 made mail transfer a sequence. The sender opened with MAIL, named one or more recipients with RCPT, then requested DATA. After a 354 reply, it transmitted the message and its terminating line. Only then did the receiver issue the decisive response to the completed object.

That sequence protected transactional clarity, but it located some resource knowledge late. A server might know that it never accepted objects beyond a fixed size. It might simply run short of space while buffering a particular message. Under unextended SMTP, the client could learn either fact only after sending every octet. The server then discarded the object, and a relay or user paid for a transfer that had no possible successful ending.

As multimedia mail grew, the waste became more than an edge case. The question was not how to give a remote sender control of a server's disk. It was how to disclose enough local evidence for both sides to avoid obviously futile work.

Two declarations, not one promise

The extension appeared first in RFC 1427 in 1993, was revised by RFC 1653, and reached its 1995 Standards Track form in RFC 1870. Its economy lies in using two different declarations.

A receiver that supports the extension lists SIZE in its EHLO response. It may append a decimal number describing the largest message it is ever willing to accept. That is a fixed ceiling, chosen by implementation or administration. A zero parameter means that no fixed maximum is in force. If the server says SIZE with no number, it has revealed support but no information about a fixed maximum. Silence about a limit is uncertainty, not infinity.

The sender may then add a SIZE parameter to MAIL FROM. This second number is not the server's rule; it is the client's estimate of the particular message it intends to transmit. Ideally the estimate equals reality. When exact calculation is impractical, RFC 1870 permits a heuristic and recommends biasing it high. The shared value is useful precisely because each side retains ownership of a different fact.

Counting the transmitted object

Interoperation required agreement on what the estimate counted. RFC 1870 defines message size as the octets sent after the 354 reply: header, body and the CR-LF pairs between lines. It excludes the period-only DATA terminator and the extra periods inserted solely for SMTP dot transparency.

That boundary matters historically. The nearby SMTP framing problem asks where the content ends. SIZE does not answer it. The receiver must not use the declared number to terminate DATA. A mistaken estimate can affect acceptance, but it cannot shift the parser into treating content as commands. The old DATA terminator keeps authority over framing.

The design therefore made a claim measurable without making it structural. Operators could compare declared and observed size. Implementations could tolerate an underestimate or refuse it. Neither side had to pretend that an estimate was an exact byte-counted transport envelope.

Permanent policy and temporary scarcity

Once a server sees the extended MAIL command, it can decide early. If the declaration exceeds its fixed maximum, it can return 552: retrying the same message later against the same policy will not help. If the server currently lacks resources but might accept the message later, it can return 452: the client should reset or quit and requeue the attempt.

The distinction encodes more than error vocabulary. It allocates future work. A permanent refusal should travel back toward the sender instead of consuming repeated relay attempts. A temporary refusal leaves time as a legitimate recovery path. Confusing them either creates useless retries or destroys a delivery that might have succeeded.

Size can also be recipient-specific. A server may accept the transaction for one RCPT and return 452 or 552 for another based on the declared message size. One transmitted object can therefore meet different local mailbox or channel policies. The shared estimate does not flatten recipient autonomy.

Early permission was still provisional

RFC 1870 carefully refuses to make 250 at MAIL an absolute guarantee. Storage may change. A later command may fail. The actual DATA object may exceed the declaration. Relay and final delivery remain beyond the early decision.

A server may accept an object larger than declared, but need not. If it agreed to the declared size, it should not issue a post-DATA 552 merely because of its normal fixed limit unless the actual message exceeded the declaration. That creates useful reliance without inventing a universal reservation. A parameterless SIZE advertisement has a stronger local rule: before positively accepting a declared MAIL command, the server must check sufficient resources and should reserve storage if possible.

This restraint is the mechanism's central achievement. The extension moved one verdict earlier while leaving all later verdicts visible. It reduced wasted bytes without collapsing capacity, policy, framing, storage and delivery into a single response code.

A thin contract for unequal machines

RFC 5321 later required servers to accept at least 64K octets and advised systems that must impose restrictions to implement SIZE. It did not establish a global acceptable attachment size. Mail crosses relays with different disks, queues, recipients and policies; the useful common rule was a way to express one boundary at the point that owned it.

An older SMTP peer could continue without the extension and receive late failures. A supporting client could use only the advertised ceiling without declaring its own estimate. A fuller implementation could expose temporary capacity and per-recipient limits at MAIL or RCPT. Adoption could deepen locally rather than requiring a network-wide cutover.

That flexibility also preserves accountability. The sender owns the estimate. The receiving server owns its advertised ceiling and current resources. Each recipient path owns its acceptance. The protocol owns only the syntax and the difference between retryable and final refusal.

Sources and limits

The original transaction and late DATA response come from RFC 821. The extension lineage is RFC 1427, RFC 1653 and RFC 1870. RFC 1870 supplies the present counting rule, EHLO ceiling, MAIL estimate, 452/552 distinction, per-recipient handling and warning that early success is not a guarantee. RFC 5321 records the later baseline and recommendation.

These specifications do not measure current deployment or document any provider's limit. They do not prove that an advertised ceiling equals available mailbox quota, that a 250 response reserves every downstream resource, or that SIZE validates the message. They support a narrower history: a declared measurement let independently operated relays avoid some doomed transfers while keeping final authority local and revisable.