摘要

  • RFC 1153 在 1990 年记录了忙碌邮件列表早已采用的摘要格式：一封常规外层邮件包住前言、至少一封内层邮件和结尾，节约重复投递与邮件头流量。
  • 内层邮件保留 Date、From、Subject、Message-ID 等指定头部，却丢弃其他头部，特别是 Received。外层摘要仍有自己的传输记录；投稿原先的逐站路径不再随内层副本完整转发。

邮局买了一个大信封

RFC 1153 回顾说，高流量的大型邮件列表在 1970 年代中期开始出现。版主们想出一个朴素办法：把几封投稿合成一封邮件，再发给订阅者。少开几轮投递，邮递程序的工作量随装入的信件数减少；内层信件删去重复头部，也省下网络带宽。Frank Wancho 在 1990 年写下的不是刚出炉的新发明，而是已经形成惯例的摘要格式。先有忙碌的邮局，后有装订说明书。

摘要外面仍是一封普通邮件，有自己的邮件头。正文则分成前言、至少一封内层邮件和结尾。前言通常按内层邮件的主题列出目录，也可以放通知。随后是一整行 70 个连字符，加一个空行。内层邮件之间用另一种路标：空行、恰好 30 个连字符、再一个空行。结尾写明摘要到此结束，下一行以星号作下划线。这些看似古怪的栅栏，让程序能够重新拆出各封信。一个讨论区的当天来稿，被装订成了有目录的小刊物。

每封内层信仍留着认人的名片。原邮件若带有 Date、From、To、Cc、Subject、Message-ID 和 Keywords，摘要副本必须保留，并按 RFC 指定的顺序重排；Summary 可选。读者因此能看出是谁在什么题目下发言，拆分程序也有线索。但下一刀切得更深：其他内层头部应当丢弃，文档特别点名 Received。原邮件经过各站时攒下的路径纸条，没有被装进摘要里的那份副本。

摘要送达时，这个区别容易被忽略。大信封自己有邮件头，也有自己的投递路径；收件人可以查它从摘要发布点走到自己邮箱的过程。某封内层投稿在进入摘要以前经过哪些站点，那串原始 Received 记录却已按格式被修剪。两组路径描述的是两趟不同的旅程。把几封邮件合成一封，省下了工作，也重新划定了哪些传输痕迹会成为读者手里的记录。

正文也并非逐字封存。RFC 1153 允许去掉内层正文开头和末尾的空行。倘若正文里恰好有一整行 30 个连字符，与分隔符撞了脸，制作者可以把那一行的第一个字符改成空白，免得拆分程序把正文误认作另一封信的边界。人眼或许不在意，逐字节比较的程序会在意。这个格式服务于兼容的装订和拆分，保留下来的是整理后的来信。

版主的权力也被写在格式之外。决定丢弃投稿、改正标点、加上评论或重新分段，都属于版主的编辑动作；RFC 1153 只规定接受后的邮件如何排列、哪些头部留下、分隔符放在哪儿。摘要是一期由人组织的刊物，版主并不只负责把原稿塞进同一个袋子。

文档说典型摘要大约有 15,000 个字符，同时明确没有固定大小，途中网关还可能施加限制。它也说明自己与 RFC 934 的关系：后者描述一般性的邮件封装，而邮件列表摘要的特定习惯出现得更早，继续供版主使用。这份 RFC 给现成的做法立下共同语法，并未要求所有封装邮件都长成摘要。

旧式摘要同时是一笔运输账和一份编辑决定。目录让读者能翻阅，一层外壳替邮递程序省力，挑选出的头部保留发言者的身份，丢弃的 Received 行则让单封投稿的原始来路从副本里退场。大信封减轻了邮件列表的负担，也替未来读者选择了会留下哪些证据。