摘要

  • RFC 2368 把 mailto: 从单一地址扩展为可携带多个收件人、邮件头和短纯文本正文的模板，但解析 URL 并不要求立即连接远端服务器。
  • 客户端可以拒绝危险字段，并应先向用户展示完整解码后的邮件再请求同意；链接、点击和已填草稿都不是发送、投递或收件人行动的回执。

普通网页链接会让人预期一次远端访问。mailto: 的结果却可能完全停留在本机：一个编辑窗口打开了，地址和正文已经填好，网络上仍没有一封邮件。

RFC 1738 的形式主要是地址。RFC 2368 在 ? 后加入名称和值，用 & 分隔多个字段，并用特殊名称 body 表示第一段 text/plain 正文。网页因此可以准备订阅命令、资料请求、归档回复或抄送对象，减少手工复制。

减少输入不等于合并责任。网页作者拥有原始 URL，解析器负责把转义字节变成字段，邮件客户端执行本地安全策略，用户决定是否认可，提交服务器、传输系统和远端邮箱分别掌握后续事实。上一层状态不能替下一层出具回执。

编码规则正是控制面的一部分。?、=、& 既是结构符号，也可能是地址或内容数据；作为数据时必须百分号转义。空格写成 %20，正文换行写成 %0D%0A，字面百分号写成 %25。嵌入 HTML 时，分隔符 & 又要写成 &。页面源码、浏览器得到的链接和用户看到的邮件不是同一串字符，错误的解码顺序可能改变收件人或生成意外字段。

文本还暴露了当时的国际化限制：未经编码的八位字符被禁止；邮件头可以使用 MIME 编码词，body 却不能。它也没有变量替换，静态链接无法可靠插入点击者地址，更不能生成依赖本地密钥或上下文的签名。它是有限模板，不是脚本。

语法能容纳一个邮件头，并不代表客户端必须采用它。RFC 2368 允许客户端因危险字段而拒绝创建邮件，或只保留安全子集。Subject、Keywords 与 Body 被视为较安全有用；From、Bcc、路由和若干 MIME 字段尤其可疑。外部文档只能提出字段，本地软件仍掌握解释权。

真正的权力边界位于发送之前。规范要求客户端展示完整、已解码的消息，包括 URL 带来的所有邮件头，明确告知用户即将发送电子邮件，并请求批准。因为隐藏模板可能向不受欢迎的第三方暴露身份、产生费用、构成违法信息，或触发可归责于发送者的破坏性操作。

因此，发现 mailto: 只能证明发布者提供过模板；点击记录至多证明界面被激活；编辑器截图证明部分字段进入草稿。用户是否按下发送、提交服务器是否接受、远端是否投递、收件人是否阅读、自动服务是否执行命令，都要寻找各自证据。

2010 年的 RFC 6068 用 UTF-8 后再百分号编码的方式改善非 ASCII 数据，澄清重复字段与转义，也调整了 Bcc 规则。它没有消除核心停顿：URI 仍是消息模板。字符正确显示，不会自动变成同意，更不会变成送达。

RFC 2368 留下的历史价值，是一种克制的自动化：网络可以替人预写，但不能仅凭预写夺走人的最终决定。

来源