Visual RFC.
ALL RFCs / RFC 1870
Read the RFC ↗
RFC 1870 / SMTP MESSAGE SIZE

Keep DATA framing separate from an estimate

04

The receiver still uses SMTP’s dot-line terminator to find the end of DATA, even when the declared size is wrong.

DIAGRAMRead RFC section 6 ↗
RFC 1870 · § 6EXAMPLE
4 / 4
Keep DATA framing separate from an estimateA deliberately underestimated ASCII fragment has declared20 but actual23 message octets. A schematic byte range crosses byte20 and continues to23; SIZE must not determine end of DATA. A dot-only line terminates DATA after dot transparency processing. Two separate post-transfer outcomes show permitted acceptance of excess content versus a552 rejection when actual exceeds declared. Temporary errors remain possible; after agreement a server should not issue post-transfer552 unless actual exceeds the estimate.An estimate is never DATA framingSMTP clientSMTP server552 rejected after DATAActual 23 > declared 20This late rejection is allowedTemporary failures remain possible tooWithout excess: should not return late 552
04
Handle a late rejection.

In the alternative outcome the server rejects after transfer. Actual size exceeds the estimate, so a 552 can occur; temporary errors can still occur too.

Source for this drawing: RFC 1870 · Read RFC section 6 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

RFC 5321 SMTP RFC 5322 Email message format RFC 2045 MIME message bodies

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

What changed
RFC 1870 § 6RFC 5321 § 4.5.2

Related current SMTP transparency rules double a leading dot and terminate DATA with a dot-only line. RFC 5321 supersedes the base SMTP RFC 821, not RFC 1870.

Read the updated RFC section ↗
KEY POINT

Servers MUST NOT use SIZE to determine the end of DATA content.

  • A server is permitted, not required, to accept content larger than its estimate; an underestimated message can instead be rejected after transfer.
  • After agreeing to the estimate, the server should not issue a post-transfer 552 unless actual size exceeds the declaration.
  • Clients must still be prepared for temporary and permanent errors at DATA or after transfer. SIZE is no storage or delivery guarantee.
DETAILS

The drawing uses the same 23-octet counting fragment with a deliberately inaccurate SIZE=20. An implementation must enforce its own resource limits.

Read the RFC section ↗

All chapters in RFC 1870

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗