What this RFC defines
RFC 1870 defines the SIZE SMTP extension, which allows a sending MTA to declare the size of a message before transmitting it. The receiving server advertises its maximum accepted size in the EHLO response (250-SIZE 52428800 means 50 MB limit), and the sender includes SIZE=nnn in the MAIL FROM command.
Where you see it in practice
When you receive a bounce saying your message was rejected because it exceeded the recipient server’s size limit, the SIZE extension from RFC 1870 is what enables that early rejection at the SMTP envelope stage, before the message data is transmitted. Without it, a server would have to accept the entire message before discovering it was too large, wasting bandwidth on both sides.
How it connects to other RFCs
RFC 1870 builds on RFC 1869 (ESMTP framework) and is used within RFC 5321 (SMTP) transactions. It works alongside other SMTP extensions announced via EHLO. There is no direct successor; the SIZE extension remains the current mechanism for message size negotiation in SMTP.
Current status
RFC 1870 is a current standard, published November 1995. The SIZE SMTP extension it defines is universally supported by modern MTAs. It has not been superseded and remains the reference for message size declaration in SMTP.
What SIZE actually negotiates
RFC 1870 defined the SIZE extension for SMTP, allowing a receiving server to advertise the maximum message size it will accept and a sending client to declare the size of a message before transferring it. The negotiation happens in two places: the server includes “SIZE nnnn” in its EHLO response, and the client can append “SIZE=nnnn” to its MAIL FROM command. If the declared size exceeds the advertised limit, the server rejects the transaction immediately with a 552 or 452 reply, saving both parties the cost of transferring a message that would be discarded.
Common misuse
Two operational mistakes recur with SIZE. First, some MTAs advertise a SIZE value that is smaller than what they actually accept, resulting in false rejections when a legitimate client honors the limit. Second, some clients omit the SIZE parameter on MAIL FROM entirely, forcing the server to accept the entire DATA payload before checking the limit, which wastes bandwidth. Both mistakes are common in older or minimally-configured mail servers. Modern MTAs like Postfix and Exim configure SIZE correctly by default; the failures typically come from custom SMTP relays or appliance-based filters.
Practical impact on deliverability
SIZE limits are why large attachments fail with 552 errors before the payload even transfers. Gmail advertises a 25 MB SIZE limit; Outlook.com advertises about 35 MB; enterprise Exchange typically 25 MB by default. Third-party ESPs like SendGrid, Mailgun, and Amazon SES advertise their own limits (usually 30-50 MB depending on tier). If you send bulk email that includes generated PDFs, images, or reports, checking each recipient MX for its advertised SIZE limit before send avoids preventable rejections. Most sender software does this automatically; misconfigured or homegrown senders often skip the check. The current published figures for each provider, and how to read the SIZE value yourself, are in our guide to attachment size limits. The rejection itself is documented in the 552 message size exceeds fixed maximum reference.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
