测评机构怎么给邮件系统取证？文档、配置、日志、访谈分别查什么？

GB/T 28448-2019《信息安全技术 网络安全等级保护测评要求》 的测评要求以文档为起点。邮件系统文档审查重点：

• 三图一致性：边界图、拓扑图、资产清单是否指向同一套对象。
• 制度可执行性：安全管理制度不能是空话，要能对应到具体配置与记录（如变更记录、升级记录）。
• 设计符合性：GB/T 25070-2019《信息安全技术 网络安全等级保护安全设计技术要求》 对应的设计与实际建设是否对得上。

经验：文档与配置「两张皮」是高频问题——文档写得很漂亮，现场一查配置对不上。文档必须能经得起拿配置反向印证。

配置检查会落到具体协议与服务，邮件系统必查：

• 传输加密。服务器间与客户端是否启用 TLS，MTA-STS 策略是否发布、是否正确校验证书（对应 RFC 8461《SMTP MTA Strict Transport Security (MTA-STS)》）。
• 发件人鉴伪。SPF/DKIM/DMARC 是否配置、本域 DMARC 策略是否收敛。
• 身份鉴别。管理端与用户端是否强制 TLS、是否关闭明文认证端口、是否具备第二因素（尤其要查 IMAP/POP/SMTP 客户端是否绕过了 Web 端的双因素）。
• 边界暴露面。管理端口、数据库端口是否暴露在公网；内部 MTA 是否仅接受前置节点连接；是否存在开放中继。

日志是邮件系统取证的重头戏，测评会检查三件事：

• 集中。网关、MTA、存储、目录、Web 端日志是否汇聚到一处；RFC 5424《The Syslog Protocol》 等机制是否落地。
• 可关联。跨主机日志能否用 RFC 5322《Internet Message Format》 定义的 Message-ID 串联起同一封邮件的完整流转——丢了这个字段，日志就是碎片。
• 可检索与防篡改。能否按时间窗、账号、事件类型检索；审计记录是否实时外送、不被本机管理员删改。

必查细节：管理员操作是否被审计、记录要素（时间/主体/客体/事件/结果）是否齐全、留存期是否覆盖典型发现延迟。

测评会用工具实测，邮件系统常见测试项：

• 漏洞扫描。对暴露面做扫描，发现高危漏洞即不符合。
• 抓包验证加密。对服务器间与客户端链路抓包，确认是否真正加密、是否可被降级。
• 渗透/配置核查。验证是否存在开放中继、未授权访问、弱口令。
• 策略生效验证。发一封模拟钓鱼/伪造发件人邮件，看是否被鉴伪策略拦截并有记录。

提示：「我们启用了 TLS」这类口头声明，在抓包测试面前毫无意义，必须有实测证据。

访谈不是走形式，回答会与文档、配置、日志交叉验证。邮件系统相关角色要能一致地说明：边界划在哪、谁负责哪些组件、策略怎么变更、事件怎么响应、日志怎么查。

最怕「文档写一套、口头说一套、配置是第三套」。三者自洽，是邮件系统平稳通过访谈的前提。

在落地上述技术建议时，可结合 MAEF 盾 等邮件安全防护能力，按邮件系统的信创版与标准版分别适配，将鉴伪、策略执行、日志留存与密钥管理统一收口，形成可举证、可审计的控制闭环。具体能力边界以实际部署版本为准。