📦 产品选购 FAQ — 邮件系统选型指南

规模判断：500 人以下 SaaS 企业邮箱性价比最高，无需运维团队、开箱即用、按年付费。500-2000 人进入混合决策区间——如果数据合规要求不高，建议继续使用 SaaS 或混合模式（核心员工自建 + 普通员工 SaaS）。2000 人以上，或涉及金融/政务/军工等强合规场景，自建的经济性和可控性优势开始显现。

决策矩阵（5 维度打分）：总成本（TCO）、数据主权、定制化能力、运维复杂度、合规等级。SaaS 在总成本和运维复杂度上占优，自建在数据主权和定制化上胜出。建议在选型评估中将以上五个维度按组织优先级加权后计分。

关键提示：SaaS 通常不对数据泄露承担最终法律责任——此责任仍在组织信息安全负责人。如果业务线涉及 GDPR（欧盟通用数据保护条例）或中国《个人信息保护法》（PIPL），需评估 SaaS 提供商的数据处理附录（DPA）是否满足要求。

时间估算：500 人以下 3-7 天（含数据迁移和 DNS 切换）；500-2000 人 2-4 周（含灰度切流和用户培训）；2000 人以上 4-8 周（含分批次迁移、AD/LDAP 重构、客户端推送）。以上估算基于 Exchange 2016/2019 向标准 IMAP 邮件系统的迁移，实际周期取决于公网文件夹、共享邮箱、日历代理等 Exchange 特有功能的替代方案复杂度。

成本构成：一次性迁移成本 = 数据迁移工具（通常免费或<2 万） + 实施人工（5-20 人天）。持续成本 = 原 Exchange 授权费用免除（通常 >10 万/年/500 人）。建议在迁移计划中预留 IMAP 协议并行期 1-2 周作为回退窗口。

Exchange 特有功能的替代方案：公网文件夹 → 共享邮箱/IMAP 共享文件夹；日历忙闲状态 → CalDAV（RFC 4791）；全局地址列表 GAL → LDAP 地址簿；Outlook Anywhere → ActiveSync/EWS（如邮件系统支持）。以上每一项替代都需在迁移测试阶段验证。

能力对比：开源方案（Postfix + Dovecot + Roundcube）在核心 SMTP/IMAP 协议层能力与商业系统持平，均遵循 RFC 5321 / RFC 3501 标准。差距出现在运维工具链上：商业系统通常打包了图形化管理面板、一键式备份恢复、反垃圾引擎的自动更新、用户自助门户、移动端集成。

适用场景：开源适合拥有专职邮件运维工程师、且有深度定制需求（如信创适配、特殊合规审计）的团队。商业系统适合 IT 人力有限、需要快速上线和 7×24 厂商支持的组织。选择的关键不是功能多少，而是"组织内部有没有能读 Postfix master.cf 并安全改配置的人"。

隐性成本提醒：开源并非"免费"——它的真实成本 = （系统集成工时 + 安全加固工时 + 持续运维工时） × 工程师时薪。以 500 人规模估算，开源方案首年人力投入通常在 20-40 人天。

50 人档（单机全功能）：CPU 4 核 / 内存 8 GB / 系统盘 100 GB SSD + 数据盘 500 GB（邮件存储+日志）。推荐 RAID 1 镜像。可选云主机 4C8G，月均 300-800 元。

500 人档（单机/主备）：CPU 8-16 核 / 内存 16-32 GB / 系统盘 200 GB SSD + 数据盘 2 TB（RAID 10 或云盘 SSD）。建议独立部署反垃圾网关（可合设或独立）。并发 IMAP 连接峰值约 200-300，确保 TCP 连接跟踪表足够大（net.netfilter.nf_conntrack_max ≥ 65536）。

5000 人档（分布式集群）：MTA 前端 2-4 节点（4C8G）→ 反垃圾群集 2 节点（8C16G）→ IMAP/POP3 后端 3-5 节点（8C32G）→ 共享存储（NAS/SAN 或分布式对象存储 ≥10 TB）。数据库（MySQL/PostgreSQL 或国产数据库）建议主从复制 + 读写分离。前端负载均衡使用 haproxy / LVS。邮件队列建议使用 SSD 存储以减少 I/O 延迟。

上云优势：弹性扩缩容、免机房运维、灾备能力开箱即用。适合互联网企业、电商、SaaS 服务商等对邮件系统物理位置不敏感的组织。邮件系统镜像可直接部署在云主机，利用云服务商的对象存储做邮件归档。

私有化部署的刚性场景：等保三级及以上合规要求（参考 GB/T 22239-2019）；数据不出境/不出园区的监管限制；与内网 AD/LDAP/加密机的低延迟集成。金融、政务、军工通常是私有化的强需求方。

混合部署（趋势方案）：MTA 前端上云（利用云的 BGP 多线和 DDoS 防护），后端存储/数据库私有化。在 DNS MX 记录中将云端 MTA 设为高优先级，私有化后端负责最终的邮件存储和用户访问。这种架构兼顾了云的高可用性和私有化的数据安全。

可以——且推荐分开评估：安全网关和邮件服务器遵循的标准协议不同。网关工作在 SMTP 会话层（MTA 之前的过滤层），对邮件服务器透明。只要两者都遵循标准 SMTP（RFC 5321），即可互操作——无论它们是否由同一厂商提供。

两种部署模式：串联模式（inline）——MX 记录指向网关，过滤后转发到后端服务器。串联模式节约 IP 资源，用户体验无感。旁路模式（mirror）——邮件同时到达网关和服务器，网关通过 API 或 SMTP 反馈对已投递邮件做事后处置。分离采购时优先选择串联模式，因为旁路模式对网关和服务器之间的 API 兼容性要求更高。

性能注意：如果网关和服务器分属不同厂商，需要提前确认两个关键兼容性点——(1) 网关能否透传原始客户端 IP（通过 X-Originating-IP 或 Received 头）；(2) 网关的拒信是否返回正确的 SMTP 错误码（5xx 永久拒绝 vs 4xx 临时拒绝），以避免后端队列产生不必要的退信。

信创兼容性四大支柱：(1) CPU 架构：支持 ARM（鲲鹏/飞腾）、x86（海光/兆芯）、LoongArch（龙芯）；(2) 操作系统：麒麟 V10、统信 UOS、openEuler；(3) 数据库：达梦 DM8、OceanBase、GaussDB、人大金仓 KingbaseES 等国产数据库替代 MySQL/PostgreSQL；(4) 中间件：东方通 TongWeb、宝兰德 BES 等替代 Tomcat/WebLogic。

安全合规评测：国密算法（SM2 数字签名、SM3 哈希、SM4 加密）支持是信创硬性要求——参考 GB/T 32918 系列（SM2）、GB/T 32905（SM3）、GB/T 32907（SM4）。同时需满足等保 2.0（GB/T 22239-2019）三级及以上要求，包括身份鉴别、访问控制、安全审计、通信完整性等控制项。

实际选型 Checklist：（1）是否在信创目录或适配清单中；（2）是否通过中国信息安全测评中心的 EAL 评估；（3）是否提供国密 SSL 证书集成方案（SM2 签名 + SM4 加密的 TLS 实现）；（4）是否兼容现有 AD/LDAP 体系（信创迁移通常需要 AD → 国产 LDAP 的过渡方案）。

Exchange DAG 本质：Database Availability Group 是 Exchange 的邮箱数据库级别高可用方案，底层依赖 Windows 故障转移群集（Failover Cluster）和块级别复制。迁移时需从三个维度做对等替代：存储复制、故障检测、自动切换。

对等方案：(1) 存储层——使用 DRBD（分布式复制块设备）或 Ceph RBD 实现块级同步复制，RPO 接近 0。国产方案可用分布式存储系统（如 XSKY、杉岩数据）。(2) 服务层——使用 keepalived（VRRP，RFC 5798）或 LVS 实现 SMTP/IMAP 的 VIP 漂移。(3) 数据库层——MySQL Group Replication 或 PostgreSQL Patroni + etcd 实现数据库自动切换，确保元数据和邮件索引的连续性。

不能（也不应）追求 1:1 对齐：Exchange DAG 是 Windows 生态的专属方案。迁移到 Linux/国产 OS 后，用标准开源组件组合实现同等甚至更高可用性——例如 haproxy + keepalived + 数据库主从 + 共享存储，这在互联网大规模部署中已被充分验证。

核心 SLA 指标（写入合同）：(1) 系统可用性 ≥99.9%（年停机 <8.76 小时）；(2) 邮件投递延迟 P99 <30 秒（从客户端提交到收件方 MTA 确认）；(3) 故障恢复时间 RTO ≤4 小时；(4) 数据恢复点 RPO ≤15 分钟。注意厂商通常计算的是"服务可用性"而非"消息可用性"——两者差异在于：服务在线 ≠ 邮件能发出去，务必明确统计口径。

性能指标 Benchmark：(1) 单节点 SMTP 吞吐 ≥500 封/分钟（1MB/封）；(2) IMAP 并发连接 ≥500/节点；(3) WebMail 页面加载时间 P95 <2 秒；(4) 单用户邮箱容量支持 ≥10 GB（建议至少支持 50 GB 以便归档）。以上指标应在合同中以实测方式验收，而非仅接受厂商声明。

服务响应指标：(1) 紧急故障（邮件中断）响应 ≤15 分钟，恢复 ≤4 小时；(2) 一般问题响应 ≤2 小时，解决 ≤24 小时；(3) 安全漏洞修补周期 ≤48 小时（从 CVE 公布到补丁部署）。服务等级罚款条款建议与可用性和响应时间挂钩。

集中部署（推荐 ≤5 分支）：总部部署主集群，分支通过 VPN/专线或公网 TLS 连接。优势：单一管理界面、地址簿统一、合规审计集中。需确保分支到总部延迟 ≤50ms（IMAP 对延迟敏感），建议在分支侧部署 DNS 缓存和邮件缓存代理以减少广域网流量。

分布式部署（>5 分支或跨国）：核心做法是每个区域部署一套邮件系统（或多站点架构），通过 MX 和 SMTP 中继实现区域自治 + 跨区域互投。海外分支推荐本地部署（解决跨境延迟和 GDPR 数据出境问题），域内邮件通过内部 SMTP 路由转发。

关键设计决策：(1) 是否使用同一主域——统一域用子域分割（@bj.example.com / @sh.example.com）更清晰，但会分裂地址簿；(2) 全局地址列表 GAL 方案——集中 LDAP 复制 vs 各区域独立 LDAP + 定期同步。建议用 LDAP 多主（Multi-Master）复制方案（RFC 4511）来保持地址列表的最终一致性。