邮件日志的审计留存周期怎么定？哪些日志必须留、留多久？

NIST SP 800-92 把日志管理拆为生成、传输、存储、分析与处置若干环节，并指出组织应当先建立日志管理策略，明确哪些系统需要记录、记录哪些事件、保留多长时间。邮件系统的日志通常至少分三类：投递日志（连接、收发地址、投递结果与退信原因）、认证与访问日志（登录成功与失败、来源地址、认证方式）、以及安全事件日志（策略拦截、认证校验结果、反垃圾判定）。三类的价值密度与敏感度不同，应分别设定周期。

SP 800-92 强调留存周期应基于组织自身的需要来确定，需要综合考虑的因素包括适用的法律法规要求、日志数据对事件调查与审计的价值、以及可用的存储资源与处理能力。实践中的推导顺序是：先取外部要求给出的最短年限作为下限，再叠加事件调查所需的回溯深度——这一点常被低估，因为许多入侵在发生数月后才被发现，回溯窗口过短会直接导致调查无法开展。最后用存储成本与存储限制原则收敛出上限。

为兼顾查询效率与成本，通常按访问频率分层：近期日志保留在可快速检索的在线存储中，用于日常排障与告警关联；中期日志转入成本更低的存储，仍可检索但延迟较高；长期日志压缩归档，仅在审计或调查时调取。分层的关键是每一层都要明确到期后的下一步动作——是转下一层还是删除，而不是任其在某一层无限堆积。

确定周期后需要验证存储是否撑得住。实用做法是先采样：在典型业务日统计各类日志的实际日增字节数，再乘以计划保留天数，并为增长与突发流量预留余量。如果估算结果超出可用容量，正确的处理是回头调整记录的事件范围或详细程度，而不是悄悄缩短留存周期——后者会在需要调查时才暴露问题。

SP 800-53 Rev.5 的审计与问责（AU）控制族对审计记录的生成、存储容量、以及审计信息的保护提出了要求。落到配置上，核心是两点：日志应尽快离开产生它的主机、集中存放到独立的日志系统，避免主机被攻陷后日志一并被清除；以及对日志的访问与删除本身要受控并留痕。本地日志文件的删除权限如果与业务运维权限混同，日志的证据价值会大打折扣。

第一个是轮转策略与留存策略互相矛盾——策略写着保留若干个月，而轮转配置按大小滚动覆盖，实际只留了几周。两者必须对齐，且应以实际磁盘上最早一条记录的时间来验证，而不是看配置文件。第二个是日志中混入了不必要的敏感内容，例如把邮件主题或正文片段写入投递日志，这会使日志本身成为需要按内容标准保护的数据，反而抬高了留存的合规成本。