邮箱历史数据迁移到国产化平台，怎么保证不丢信、不乱序、可校验？

迁移最大的隐患是验收标准模糊——「用户说能看到邮件」不是标准。应事先约定四类对象的保真要求：

• 邮件本体：原始报文字节级保真，包括全部头字段、MIME 结构、附件编码。
• 组织结构：文件夹层级、名称（含非 ASCII 名称的编码）、嵌套关系。
• 状态标记：已读/未读、标记、草稿、已删除标记。
• 时间信息：邮件原始日期与「内部到达时间」——这两个是不同的值，混淆会导致排序全乱。

RFC 5322 Internet Message Format 定义的 Message-ID 在迁移中承担三重作用：去重依据、跨系统日志关联键、取证时的唯一定位标识。

迁移工具若重新生成 Message-ID，后果是：无法与旧系统日志对账、断点续传时无法识别已迁移项、历史邮件与既有日志之间的关联链彻底断裂。

判定条件：抽取任意样本邮件，其在新旧系统中的 Message-ID 必须完全一致。这一条应作为迁移工具的准入测试项，在正式迁移前验证。

若源平台提供标准 IMAP 访问，RFC 9051 Internet Message Access Protocol (IMAP) - Version 4rev2 定义的机制可支撑一次可校验的迁移：

• UIDVALIDITY + UID：在一个邮箱内唯一且单调，可用作断点续传的游标。注意 UID 在目标系统会重新分配，不要把它当作跨系统的身份标识（那是 Message-ID 的职责）。
• FLAGS：承载已读、标记、草稿、删除等状态，需显式迁移，否则用户会看到「全部未读」。
• INTERNALDATE：邮件到达服务器的时间，决定列表默认排序。不迁移它，所有历史邮件的时间会变成迁移当天——这是用户投诉最集中的问题。
• BODY.PEEK[]：取全文时应使用不改变已读状态的取法。

部分迁移工具会在搬运时「顺手规范化」邮件——重排头字段、重新编码正文、重新封装附件。这类重写会破坏原始报文的字节一致性，直接摧毁其取证价值，也会使内容级签名失效。

硬性要求：迁移应以原始报文为单位整体搬运，不做任何解析后重组。若源系统只能导出解析后的结构化数据，需在验收标准中明确记录「已丧失字节级保真」，并评估其对取证与签名的影响。

可执行的校验方法，两层都要做：

第一层——计数对齐（全量）：按「邮箱 × 文件夹」维度比对邮件条数。差异必须逐条查明原因，不允许以「误差可接受」结案。常见合理差异来源仅两类：源端在迁移期间的新增、以及事先约定排除的垃圾/已删除目录。

第二层——抽样哈希（抽样）：对每个邮箱按时间分层随机抽取样本，计算原始报文的哈希值并两端比对。抽样必须覆盖极端样本：最早的邮件、最大的附件、含非 ASCII 主题的邮件、多层嵌套 MIME 的邮件、含内容签名的邮件。这些是最容易出问题的地方，随机抽样往往抽不到。

校验结果应形成记录留存，它同时是等保与密评中「数据完整性」要求的证据。

归档库和备份介质不应与在线邮箱混在同一条迁移通道，原因有三：

• 归档数据的不可篡改要求更高，迁移过程需要额外的完整性证明链。
• 归档数据量通常远大于在线数据，混在一起会拖垮切换窗口。
• 归档的留存期计算基准不能因迁移而重置——必须保留原始归档时间，否则法定留存期的起算点被篡改。

日志与记录的管理要求可参考 NIST SP 800-92 Guide to Computer Security Log Management；本域法定留存义务见国家法律法规数据库中的相关条文。