摘要

  • RFC 3458 定义了可选的 Message-Context 字段，描述用户与整封消息的预期交互方式；它不重新定义 MIME 正文，也不保证某种媒体仍然存在。
  • 错误、未知或过时的上下文可以辅助本地界面，但不得使传输失败，也不得让消息比没有该字段时更难以被有意义地呈现。

同一种内容类型可以属于不同的使用情境

2003 年的互联网邮件已经不只是文字信件。一个统一收件环境可以接收普通邮件、寻呼提示、传真、录制语音以及由多种媒体组成的对象。两封都含文字的消息，可能分别是传统来信、短信或电话录音的转写。若为了选择图标或查看器而扫描整份大型多媒体正文，代价也可能很高。

RFC 3458 因而在消息顶层定义一个最多出现一次的字段。最初登记的类别包括 voice-message、fax-message、pager-message、multimedia-message、text-message 与 none，名称不区分大小写；没有字段等同于 none。纯文本、RFC Editor 记录、Datatracker 档案、历史、引用资料、后续引用与勘误检索界定了可核验的标准记录。

接收端可以据此选择查看器或图标、分组与排序收件箱、在受限连接上少取一部分内容，或建议回复方式。这些便利都不证明正文中真的有音频、传真图像或可执行程序。上下文回答的是“这封消息原本希望怎样互动”，而媒体类型回答的是“当前正文由什么组成”。

网关转换使标头与正文不一致成为正常状态

标准中最清楚的例子是一封经过网关的语音消息。网关可以删除音频，只留下文字转写。从来历看，它仍属于语音消息情境；从接收端的现实看，已经没有声音可以播放。反过来，若标为语音的邮件只剩传真内容，客户端也必须显示手中真实存在的传真部分，不能因为预期媒体缺失而放弃呈现。

RFC 2822规定消息语法；RFC 2183处理正文部分的呈现方式；RFC 2387与RFC 2557处理复合结构；RFC 2423提供 VPIM 情境。这些相邻机制各自回答不同问题，Message-Context 没有权力覆盖它们。

因此，无效或错误的分类不得成为拒绝传输的理由，也不得造成空白界面。接收端至少要达到没有该字段时同样有意义的显示效果。规范没有解决除简单保留之外的转发语义，这意味着被一路携带的旧值可能已经失真；它是应当监测的观测，不是必须执行的真理。

提示不能越过信任边界

安全章节特别警告：不能仅凭类似应用程序的上下文，就自动执行邮件中的程序。恶意发送者可以借错误分类消耗资源、诱导路由或争夺注意力。这个字段不认证发送者，不认证正文，不授予权限，不证明投递，也不证明紧急程度或收件人已经阅读。

RFC 3459另行处理 MIME 正文部分的关键内容参数，那不是对 RFC 3458 的加强解释，而是另一处控制面。RFC 3938后来更新登记政策，RFC 3864给出消息标头登记框架。今天的IANA 消息标头登记表证明名称得到分配，却不能证明某个客户端遵循、忽略或改写了它。

从后来的分析语言看，Heng Lu 关于现实层次的讨论提醒我们：声明的情境与收到的正文是不同种类的事实。运行代码优先要求观察真实 MIME 树、网关转换与兜底呈现，而不是只看标签。最小初始规范解释了一个小型可选字段为何能协作，却不吞并 MIME、投递或安全策略。这些是后来的编辑分析，不是对 RFC 作者私人意图的推断。

RFC 3458 的力量来自克制。标头可以帮助系统提前准备，却永远不能免除接收端阅读实际到达内容的责任。

来源