邮箱迁移：文件夹、标记与邮件历史核验

邮箱迁移看似简单，直到用户登录后发现历史不对：已发送不见了，未读暴增，十年的邮件像是今天才收到。迁移不只是复制消息，也要保留受支持的状态。完整操作可参考管理员 imapsync 指南。更换整个平台时，明确标准和测试也很重要。

只复制正文就宣布完成，无法满足用户需求。RFC 5322 内容到达还不够；用户需要已发送在预期位置、已读仍为已读，搜索有意义。这三方面出错，可能第一天就收到支持请求。

本指南说明常见故障、核验方法和 TrekMail 的可能作用。原文介绍 Starter 及以上方案有内置 IMAP 导入，按方案计费从每月 $3.50 起，而非按用户收费。迁一个邮箱或一百个，都要核实当前功能和限制。规划资料包括小企业的企业邮箱和多域名邮箱托管。

为什么 MX 切换后才出现迁移问题

邮件可能到了，邮箱状态却没保留。四个重要检查点是文件夹映射、已读标记、内部日期和 Gmail 标签。认真核验有助于降低风险，不保证所有迁移都无误。

修改 MX 后能收新信，不代表整体迁移完整。只有自己管理的域名更换接收服务时才改 MX，且要先准备目标地址、验证预复制。用户需要连续的工作方式，而非仅能连接服务器。

可把迁移看作数据库转移。每封邮件还有标记、文件夹位置和服务器日期。元数据缺失时，邮箱虽然能打开，行为却会不同。

例如，负责人打开新邮箱看到 8,000 封未读，以为提供商弄坏了收件箱。这个例子中正文到了，\Seen 状态没有复制。实际问题还应排查其他原因。

四种容易忽略的迁移故障

检查已发送映射、\Seen、INTERNALDATE，以及 Gmail All Mail 的重复视图。它们往往在用户操作后才显现，不能只看进度条。

1. 已发送文件夹映射错误

不同系统使用不同名字：Sent、Sent Items，cPanel 常见 INBOX.Sent，Gmail 是 [Gmail]/Sent Mail。

映射不对，历史已发送进入普通文件夹，客户端却把新信写入系统已发送。用户看到预期文件夹空了，就以为历史丢失，实际可能在别处。

RFC 6154 定义特殊用途邮箱，帮助客户端识别已发送、草稿、垃圾邮件和已删除。真正重要的是用途与客户端映射，不只是名称。

2. \Seen 标记问题

源端和工具支持时，应保留已读、未读。否则多年处理过的邮件可能重新变成未读，影响正常工作。

RFC 3501 描述系统标记，包括 \Seen。试点中要验证标记复制，形式上的任务完成不保证读状态正确。

\Recent 不同。在旧 IMAP 模型中它与会话有关，不能像已读状态一样迁移，现代实现也可能不再这样使用。旧邮件在目标会话可能看似新出现，应提前解释这种显示。

3. INTERNALDATE 被重置

Date 头部与服务器内部日期不同。客户端可能按内部日期排序，导入时重新设置会改变时间线，即便邮件本身完整。

RFC 3501 描述 APPEND 的可选日期时间：提供时按该规则建议用作内部日期，未提供则使用当前时间。这样十年的归档会看起来都属于今天。应传入源服务器实际提供的 INTERNALDATE、时区偏移及支持的精度；仅靠 Date 头部无法重建未知的原始服务器到达时间。

4. Gmail All Mail 产生多份副本

Gmail 以标签组织邮件，IMAP 将其呈现为文件夹。多个视图可能包含同一底层消息，工具因而复制多次。

把 [Gmail]/All Mail 与收件箱、已发送和标签一同导入，可能增加容量和搜索结果。不过，多文件夹副本也可能是有意保留标签的形式。先约定表示方式，确保没有其他导入标签的归档邮件也完整覆盖，才能考虑排除“所有邮件”。

迁移时如何正确映射文件夹

名称不同时需要匹配的映射。自动发现可以帮助，但必须验证。表中目标名只是示例，不是普遍标准，也不保证是 TrekMail 的实际默认值。

手动 imapsync 可使用经过测试的正则转换。下方保留的原始例子不能直接使用：部分转义规则不匹配通常源名称，转换在自动处理前缀和分隔符之后依次执行，后续规则作用于前一规则的结果。应在自己的工作副本中按实际目标路径纠正并测试。命令会实际复制，没有显式 TLS 或证书验证，密码还出现在参数中。需要受控目标、工具支持的真正模拟运行、安全凭据传递，以及加密、证书链和主机名检查：

imapsync \
  --host1 old.example.com --user1 user@old.example.com --password1 'oldpass' \
  --host2 new.example.com --user2 user@new.example.com --password2 'newpass' \
  --regextrans2 's/^Sent Messages$/Sent Items/' \
  --regextrans2 's/^INBOX\\.Sent$/Sent Items/' \
  --regextrans2 's/^INBOX\\.Trash$/Deleted Items/' \
  --exclude "\\[Gmail\\]/All Mail"

试点后从目标发送真实测试邮件，检查新发邮件和旧历史是否位于同一预期已发送文件夹。修正后再迁更多用户。

使用 TrekMail 可先看最新 IMAP 迁移概览。原文介绍 Gmail、Outlook、Yahoo、iCloud、其他 IMAP 模板、带数量的文件夹列表、后台运行和重复邮件识别。核实当前支持和结果，Message-ID 与 UID 不能作为内容完整性的保证。直接导入使用用户名密码，不是交互式 OAuth。应用专用密码取决于账户策略，强制 OAuth 时要用其他获准的 OAuth 连接方式。源端准备参考从 Gmail 迁移或从 cPanel 迁移。

通过实际数据核验迁移

比较邮件数、未读数、已发送和日期。MIME、索引及存储开销不同，GB 不能可靠证明完整性。数量一致也不够，要打开正文和附件，核对日志与映射。

绿色完成标记表示任务状态，不保证用户体验保留。应直接检查数据。

1. 按约定源、目标文件夹比较数量：收件箱、已发送、归档。
2. 比较未读。源端 50 封而目标 4,000 封，需要调查标记、范围、过滤和持续源端变化，不能仅凭差异认定一个原因。
3. 打开历史邮件，保留日期后 2019 仍应归在 2019。
4. 从新邮箱发送测试，确认它与迁移历史进入同一已发送文件夹。

损坏 MIME、排除项或非邮件对象可能带来小差异，但重要差异都要解释。容量不能替代消息、标记、附件和日期核验。

切换后用户还需正确客户端设置，最新参数见 TrekMail IMAP/SMTP 指南。原文描述 IMAP 不支持 POP3；删除旧配置前，应先备份本地与未同步邮件。核对当前 TLS 设置、证书链与主机名，并以完整邮箱地址和邮箱密码登录，不使用管理面板凭据。

补同步、重复与 UIDVALIDITY 陷阱

首轮之后通常至少还有一轮同步，切换后也需必要补同步。应包括旧日期迟到邮件、文件夹间移动和标记。为缓存与重试保留旧 SMTP 接收、管理员访问和回退；降低 TTL 不会立即清空旧缓存。

UIDVALIDITY 表示文件夹内 UID 的有效性。恢复、修复或重新索引可能改变它，但并非必然。工具可能失去旧映射，并依策略重新复制。UID 不是全局标识，也不证明内容完整。

因此周五看似正常，周一可能出现重复。迁移时延后非必要维护，必要修复则应协调：暂停、检查状态、重新验证恢复，而非一概禁止重要修复。

许多工具采取追加复制，源端后来删除不一定在目标删除。这可能保护目标邮箱的邮件，却仍需冲突计划。用户只在一个系统上工作；两端同时修改不是安全双向同步。

镜像删除只能在方向、时机、备份和测试另行确认后考虑。错误假设可能删除有效数据。

手动迁移与 TrekMail 管理方式

手动迁移可能涉及命令、正则和逐项审计。集中 IMAP 流程可能减少分散工作，是否比按用户收费合适，取决于实际需求和方案限制。

多邮箱时经济性与协议同样重要，还涉及创建和控制。相关指南有批量创建邮箱账户和客户邮箱管理。

TrekMail 不能代替核验。多域名面板、共享存储、IMAP 和自备或附带 SMTP 可能在方案支持范围内简化管理。新增用户、存储和功能仍受当前限制。

迁移前可比较 TrekMail 价格。原文描述 Nano 免费无需信用卡、付费方案每月 $3.50 起，以及付费方案免费试用 14 天需信用卡；请确认当前条件。

总结：成功迁移应该是什么样

目标是已发送在正确位置、未读数量合理、历史排序正确、Gmail 标签表示经过规划。应由实际邮件确认，而不只凭提示。

完整复制前映射文件夹，保留受支持标记，尤其 \Seen，并在 APPEND 传入源端可用 INTERNALDATE。只有确保整个归档覆盖后才排除 Gmail All Mail。比较数量、内容、附件、日期和日志，而不只是大小。

这些步骤能把复制变成受控切换并减少返工风险，不保证无损或零中断。别名、转发、日历、联系人与其他账户功能仍应单独恢复和核验。

协议参考是 IMAP 的 RFC 3501，以及特殊用途文件夹的 RFC 6154。