摘要

  • 原始 SMTP 可能直到完整接收 DATA 并丢弃内容以后，才报告大小限制或存储不足。
  • RFC 1870 允许服务器通过 EHLO 公布固定上限，也允许客户端在 MAIL FROM 中声明本封邮件的估算字节数。永久越限用 552，暂时短缺用 452。
  • 这个数字只是有限证据：它不划定 DATA 边界，不预留整条投递链的存储，也不把 MAIL 阶段的成功答复变成最终交付保证。

判决来得比成本晚

RFC 821规定的事务顺序很清楚：MAIL 开始，若干 RCPT 指定收件人，随后进入 DATA。服务器回复 354 后，发送方交出邮件头、正文与终止行；接收方看完完整对象，才给出决定性答复。

这种顺序维护了事务边界，却把某些已知事实放得太晚。服务器也许从一开始就有绝不突破的大小政策，也许只是当下没有足够空间。没有扩展时，客户端必须先发送每一个字节，接收方再丢弃整封邮件。多媒体邮件增长后，这种失败白白占用线路、缓冲区与排队时间。

两个数字，各有主人

方案在 1993 年的 RFC 1427中出现，经 RFC 1653 修订，最终形成 1995 年的 RFC 1870。支持者在 EHLO 回复里列出 SIZE，还可以附上自己始终愿意接受的最大邮件字节数。

参数为零表示没有固定最大值；完全不附数字，只表示服务器没有透露固定上限，不能被解释为容量无限。客户端则可在 MAIL FROM 上附带另一项 SIZE，估算这一次准备发送的对象。精确计算不可行时可以使用启发式估算，并应偏向略高。

服务器声明的是自己的政策，发送方描述的是自己的对象。共享语法让两个事实相遇，却不把磁盘、队列或邮件内容的控制权交给对方。

计数不等于分帧

大小包括 354 之后传输的邮件头、正文以及行间 CR-LF，排除 DATA 的单点终止行，也排除点透明机制临时增加的转义点。这个定义让双方有可比的观测口径。

但 RFC 1870 明令接收方不得用 SIZE 判断内容结束。错误估算可以影响是否接受，却不能把邮件数据错认成下一条命令。DATA 的终止符继续掌握边界权。SIZE 解决资源判断，点透明与 BDAT 解决内容分界；两件事相邻而不相同。

452 留下时间，552 关闭重试

声明值超过固定上限时，服务器可以返回 552。同一对象稍后再撞一次同一政策仍不会成功。当前资源不足但未来可能恢复时，452 让客户端重置或退出，并把邮件重新排队。

二者分配的是未来工作。把永久政策误当暂时故障，会制造无意义重试；把短暂紧张误作永久禁令，会毁掉本来可完成的投递。服务器还可按收件人判断：同一个声明大小，对一个 RCPT 接受，对另一个暂缓，对第三个永久拒绝。共同测量没有抹平本地邮箱与通道政策。

早期的 250 不是收据

MAIL 得到 250 并不保证后续成功。真实 DATA 可能大于声明，资源会变化，下游中继或最终邮箱仍可拒绝。服务器可以宽容低估，却没有义务宽容。

RFC 1870 同时给早期同意设下一点有用的信赖：服务器接受了声明大小以后，只要实际对象没有超过声明，就不应在 DATA 结束后仅凭普通固定上限返回 552。这不是全球存储预约，而是让一项早期决定不至于毫无意义。

后来的 RFC 5321要求服务器至少能接受 64K 字节，并建议必须设限的系统实现 SIZE。它没有规定全网统一的附件大小。磁盘、队列与收件人仍由各自系统掌握，标准只让限制能在适当时刻说清。

来源与边界

RFC 821 提供原始事务；RFC 1427、RFC 1653 与 RFC 1870 记录扩展演进；RFC 5321 给出后续基线。它们不统计今天的部署率，也不证明任何服务商的具体限制。SIZE 不认证内容，不证明配额，不预约每一跳，也不是投递收据。它支持的是更窄的历史结论：有限的容量证据足以避免一部分注定失败的搬运，而无需集中最终决定权。