摘要

  • RFC 5259 要求邮件存储中的原始数据保持不变；服务器返回的是客户端指定或服务器选择的派生结果，能正常显示不等于字节一致、签名有效或原件被替换。
  • 最终 OK 可以与部分项目失败并存；默认转换还可能删减细节或替换无法表示的字符，因此必须逐项保存结果与来源，不能只保存绿色状态。

审批者看到签名图样，却已经看不到签名所覆盖的对象

手机打不开原始合同，服务器便转成另一种格式、缩小图片并返回清晰页面。页面底部仍有熟悉的签章外观，审批者于是按“已签文件”处理。

RFC 5259 对此没有含糊：服务器转换已签名正文后，客户端无法再用原签名验证转换内容的真实性。不信任服务器时，客户端应下载已签对象，先验证，再本地转换。

转换可能完全符合协议，也非常有用。错误在于把“可读”升级成“已认证”。签名覆盖的是特定对象与字节；视觉相似的派生版本不会自动继承它的权威。

存储对象与交付结果分属两层

转换只影响发给客户端的内容，存储中的原始数据不得改变。这样其他客户端仍能取回原件，回复和转发仍有源材料，原 BODYSTRUCTURE 得以保留，签名也仍可针对真正的源对象验证。

派生结果却可以改变 MIME 类型、结构、编码、尺寸、字符集和大小。它属于一次执行。把它存入档案不能证明服务器改写过原件；界面若只写“附件”，就抹掉了决定其证据含义的“转换”二字。

每个系统都应同时保留源身份与输出身份：源邮箱、UID、正文部分和哈希，以及请求、策略、参数、时间、转换器版本与输出哈希。

能力清单不是运行回执

支持服务器通告 CONVERT 与 BINARY。CONVERSIONS 可发现源/目标 MIME 组合与参数，AVAILABLECONVERSIONS 可列出某一正文部分的目标类型。

这些回答说明“可能做什么”，不说明后来确实做了什么。运行时可能资源不足、转换服务暂时离线、参数无效，或没有专有格式转换器。能力发布后，版本与政策也可能改变。

一条可用转换路径不是输出字节的哈希。能力发现与执行结果必须拥有不同时间戳和收据。

NIL 把“读者将看到什么”交给服务器

客户端可以指定目标类型，也可以用 NIL 请求默认转换。服务器可能依据设备特征、用户或管理员偏好、服务器配置及其对常见格式的判断选择结果；具体算法不由 RFC 完全规定。

除非参数另有要求，服务器还可以删除超出设备能力的细节，例如缩小图片。规范要求在信息不足时尽量减少质量损失，却没有承诺无损等价。

RFC 提醒客户端：若没有传达能力，服务器可能猜错。默认转换因此不是单纯的算力委托，而是把呈现选择交给服务器。回执必须说明最终目标及其选择依据。

成功结果也可能包含有意的信息丢失

文本转换需要目标字符集。源字符无法表示时，unknown-character-replacement 可指定替代文本。输出可以语法正确、转换成功，同时失去某个姓名、符号或金额差异。

邮件头编码词和 MIME 参数也可能被解码再编码。读者理解的文字或许相近，源字节却已不同。保真必须拆成字节、语义、版式、尺寸、细节与替换事件分别评估。

部分 CONVERT BINARY 的范围以转码且解码后的数据为坐标，而不是源文件偏移。用派生结果的第 N 个字节指向原件，是证据坐标错误。

命令级 OK 可以包住逐项失败

CONVERTED 响应可携带 TEMPFAIL、BADPARAMETERS 或 MISSINGPARAMETERS。一个命令也能请求多个正文部分或数据项。

只要至少一项成功，最终标记结果就必须是 OK；即使所有项目都失败，服务器仍可返回 OK 或 NO。所以绿色命令状态并非完成率。

客户端必须把每个请求项与返回值或错误逐一核对。可能一个部分有字节、另一个失败；也可能只得到结构。BODYPARTSTRUCTURE 通常可显示请求是否被精确满足，但也不一定包含全部原因。它是证据项，不是笼统成功章。

转换不等于已读，也不创造新正本

CONVERT 永远不会设置 \Seen。要标为已读必须另发 STORE。服务器产生转换字节，不能证明读者打开过它，也不能证明邮箱状态改变。

服务器可缓存转换结果，并应限制缓存数量以抵抗资源耗尽。缓存只是执行状态，不是长期的替代附件，也不保证将来相同请求返回相同字节。编解码器、字体、设备画像、政策和外部服务都会变化。

只要派生结果参与机构决策，就应保存当时真实输出和运行环境，而不是期待以后重新生成。

转换器本身是安全主体

攻击者可以先 APPEND 精心构造的文件，再用 CONVERT 触发脆弱解析器。极端缩放可能耗尽资源，危险转换可能生成可执行内容。RFC 建议拒绝高成本或危险转换、尽可能检查输出、记录认证身份，并把转换库与特权邮件存储隔离。

外部转换服务又增加一次保管交接。放在同一信任域可降低风险，却不会消除边界。必须记录哪个服务接收源数据、返回什么以及由何种隔离保护。

SASL/TLS 证明通道对端，并不让新字节获得旧签名的认证。

建立源到派生结果的双层回执

保存邮箱、UIDVALIDITY、UID、源正文部分、MIME 结构、大小与哈希；请求的源/目标类型和全部参数；显式或默认选择；设备能力、偏好、服务器政策和版本；转换器、时间与安全域。

再保存每个 CONVERTED 项、错误和最终状态，输出结构、大小和哈希，删减与字符替换，缓存处置，原签名验证和派生结果未继承该验证的事实，显示结果、\Seen 及后续动作。

“该服务器为这次请求返回了这些派生字节”可验证；“这是已签名附件”需要覆盖新字节的认证；“转换成功”必须逐项说明。

RFC 5259 为受限客户端提供了实用适配层。领导者要守住的，是让便利的表示服务于原件，而不是冒充原件。

来源