摘要

  • SMTP 的 DATA 阶段以单独一行句点结束，因此正文里的同样一行必须通过可逆规则获得透明传输。
  • 发送方在每个行首句点前再加一个；接收方识别孤立终止行，并从其他受影响行删掉一个句点。
  • CHUNKING 后来用精确八位字节数和显式最后分块界定正文，把权威从内容扫描转移到计数。

同一条信道必须切换角色

RFC 821 的 SMTP 对话按命令、回复依次推进。DATA 暂时把同一有序字节流改成邮件正文。协议必须明确知道正文何时结束，命令对话何时恢复。

只有一个句点的行既直观又易于实现，却占用了用户文本的一种合法形式。普通内容与控制信号在同一命名空间里发生了碰撞。

透明是一份双边承诺

发送方逐行检查：行首若是句点，就再插入一个。接收方遇到孤立句点行时结束 DATA；若句点后还有字符，则删掉第一个句点。

线上形式因此不同于最终交付内容，但转换必须可逆。RFC 821 特别强调中继所做的变换也要能够还原。一方保护歧义，另一方负责解释和恢复；任何一方漏做，邮件都会提前结束或多出字符。

一个小例外进入所有行处理器

RFC 5321 数十年后仍保留这套透明规则，并规定为透明性额外复制的句点不计入 1000 八位字节的文本行上限。缓存、日志、中继和测试都必须分清自己看到的是存储正文、规范 SMTP 文本，还是填充后的线上形式。

字节计数移除了禁用序列

RFC 3030 的 CHUNKING 扩展以 BDAT 取代 DATA。每条 BDAT 命令声明随后数据的精确八位字节数，LAST 表示最后一块。接收方不再扫描正文寻找终止行，孤立句点在块内也就没有控制意义。

它没有普遍替代 DATA。服务器先通过 EHLO 公告 CHUNKING，客户端确认能力后才能使用 BDAT，而服务器仍必须支持 DATA。新能力通过协商加入，没有重定义旧对端能理解的输入。

摆脱哨兵后，计数成为权威

长度框定改变了故障方式。声明过多或过少都会移动边界：后续材料可能被吞进块中，也可能暴露给命令解析器。BINARYMIME 因而依赖 CHUNKING，任意八位字节不能安全依赖 DATA 的逐行哨兵。

信任没有消失，只是从内容变换转移到精确算术和事先能力协商。

来源与边界

依据为 RFC 821、RFC 5321 与 RFC 3030。它们不提供部署率。支持 CHUNKING 的服务器仍须接受 DATA；句点透明也不是加密、认证或完整性保护。