摘要

  • RFC 1524 让多个邮件阅读器共用 mailcap：邮件提供 MIME Content-Type，本地文件的搜索顺序、匹配项和环境测试才决定查看、撰写、编辑或打印动作。
  • 在其 UNIX 语义下，选中的规则会变成 Bourne shell 命令，插入媒体参数或临时文件名。匹配成功、测试返回零或进程正常退出，都不能证明内容真实、安全、符合用户意愿或已被正确理解。

邮件带来名称，没有带来程序

1993 年的互联网邮件正在摆脱纯文本。MIME 能描述图像、音频和多段正文，也能把字节编码成旧邮件系统可承载的形式。但同一种媒体，在不同站点可能由完全不同的软件处理；有的机器甚至没有显示环境或音频设备。

RFC 1524 没有要求所有邮件阅读器内置所有格式。它建议阅读器在遇到陌生的非文本类型时查询外部配置。站点安装一个程序，再增加一条规则，就可以让多个相互独立的阅读器获得新能力。

真正共享的是一份很薄的约定：哪种本地动作处理哪个声明类型。发送者无需知道收件人的操作系统，收件人也无需采用发送者偏爱的应用。格式名跨网，执行权留在本地。

有效政策是完整的搜索次序

实际配置由多个 mailcap 文件“虚拟拼接”而成。候选规则必须匹配 Content-Type，包含当前操作所需字段，并通过可选的 test=。第一条满足全部条件的规则胜出。

因此，文件顺序本身就是行为。RFC 的 UNIX 附录把用户自己的文件放在若干站点文件之前；MAILCAPS 环境变量还能替换默认搜索路径。管理员可以给出共同默认值，用户则可以补充或覆盖。两名用户收到完全相同的邮件，也可能因为有效规则链不同而启动不同程序。

一条规则必须包含类型模式和查看命令；撰写、带类型撰写、编辑、打印与测试分别有自己的字段。needsterminal 表示动作需要交互终端，copiousoutput 提醒阅读器为长输出提供翻页或滚动。“支持这种格式”不是单一布尔值：能查看不等于能编辑，能编辑也不等于能安全打印。

test= 可以运行任意复杂的本地程序，检查窗口系统、机器架构或音频设备。返回零只说明这条规则适用于当前环境。它没有读取并判定邮件正文的安全性。

配置文本进入了 shell

RFC 1524 为 UNIX 规定：动作字段是面向 Bourne shell 的完整命令行，相当于前置 /bin/sh -c。模板可用 %t 插入媒体类型，用 %{参数名} 插入 Content-Type 参数，用 %n 插入多段数量，用 %F 插入交替排列的类型和文件名；%s 代表保存正文的文件。

这条链不只是“查应用”。阅读器要解析头字段、选择规则、处理转义、替换值、形成参数，再把可执行文本交给操作系统。每一步都可能和前一步的含义发生偏差。一个语法正确的参数未必适合作为命令参数；进程成功启动也未必读取了正确对象。

%s 还改变了数据通道。没有它时，查看和编辑程序从标准输入读取正文；出现它时，阅读器可能需要创建临时文件并插入路径。RFC 特别说明，命令退出后不能假定该文件继续存在；希望转入后台的程序应先保存自己仍需的数据。

nametemplate 可以让临时文件带上查看器所需的后缀，例如 .gif。后缀解决的是文件名约束，不是证据问题。它不会检查内容字节，不会认证发送者，也不会证明打开操作无害。

撰写也有多次交接

compose 程序产生数据，调用它的邮件软件再按规则赋予媒体类型。composetyped 则可自行输出 Content-Type 和相关头字段。除非后者明确声明编码，运输所需的 Content-Transfer-Encoding 仍由调用方负责。

所以，本地产生的附件也要经过规则选择、生成程序、输出字节、类型声明、运输编码和最终邮件等不同记录。编辑器完成，不能替其余环节签字。

可扩展性没有自动获得信任

RFC 1524 的安全章节很短，却明确警告：这种机制更容易让实现落入 MIME 已讨论的安全问题，选择自动执行程序时必须谨慎。它没有记录某个真实攻击，也没有证明所有部署都危险。它留下的可靠结论更窄：远端描述只有经过某人负责的本地政策，才会获得启动程序的力量。

后来的 RFC 2045、2046 和 2048 修订 MIME，RFC 6838 又更新媒体类型注册制度。注册能让名称和文档公开一致，却不会替收件人安装程序、证明哪条规则生效，更不会授予执行许可。

调查“附件被打开”时，应分别保留原始字节与声明类型、有效 mailcap 文件及次序、请求动作、选中规则与测试、展开后的命令、标准输入或临时文件、进程身份和结果、可见输出以及用户决定。若把这些压成一句成功日志，最关键的授权转折反而消失了。

来源