邮件系统等级测评里，哪些不符合项出现频率最高？怎么整改？

GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》 在安全区域边界明确要求对垃圾邮件进行检测防护并维护机制的升级更新。高频问题是：设备在跑，但拿不出规则库/特征库更新的时间序列证据。

整改：把规则库版本与更新时间纳入监控告警，而非依赖人工巡检；保留可展示的升级历史。

网关到内部 MTA、MTA 到存储之间常以「都在内网」为由明文传输。但等保对通信传输的要求不区分内外网。RFC 8314《Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access》 的立场明确：邮件提交与访问应使用 TLS，明文应视为过时。

整改：对这些内部链路同样启用加密；对服务器间链路叠加 MTA-STS 与 TLS-RPT，确保加密真正生效、且失败可观测。

Web 端上了双因素，IMAP/POP/SMTP 客户端却仍用纯口令，攻击者可换用客户端协议绕过。这是第三级身份鉴别要求的典型失分点。

整改：用令牌化认证（如基于授权框架的令牌）替代长期口令；对无法改造的旧客户端签发应用专用凭据并限制来源与范围，同时纳入重点审计；关闭允许明文认证的端口。

系统管理员、安全管理员、审计管理员三权未分离，或审计员与系统管理员为同一人，使审计体系可信性丧失。这是明确的不符合。

整改：哪怕只是把审计读取权限从系统管理员身上剥离给另一人，性质上的改变也是根本性的；管理员越权读取行为必须被审计员可见。

日志散在各组件、留存期过短、缺少 Message-ID 关联键，导致事件无法追溯。这是跨层面的综合失分。

整改：用统一日志出口汇聚各组件日志，统一时间基准，保留 Message-ID 关联键，实时外送至独立系统防篡改，留存期覆盖典型发现延迟。

入站做了 SPF/DKIM/DMARC 校验，本域却不发布 DMARC 策略，等于放任冒用；出站策略全放行、管理端口暴露公网，属高频边界问题。

整改顺序建议：先可观测（收报告、看清现状）→ 补可见缺口（合法源纳入、内部加密、留存期调整）→ 再收紧（DMARC 收敛、MTA-STS 强制、边界收窄）。切忌一步到位式收紧，以免业务中断。

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