Exchange 接收连接器怎么加固？匿名与认证连接器如何分离？

Exchange 的接收连接器按「本地 IP 与端口绑定 + 远程 IP 范围 + 权限组 + 身份验证机制」四要素匹配入站连接。加固的第一原则是按用途拆分，不要用一个连接器同时承担公网收信、客户端提交和内部应用中继。

推荐的划分是三类：面向公网 MX 的匿名接收（25 端口）、面向用户的认证提交（587 端口，符合 RFC 6409）、面向内部应用的中继（独立端口或严格限定的远程 IP 范围）。三类的权限与限额要求完全不同，混在一起必然出现权限过宽。

当多个连接器的绑定重叠时，Exchange 会选择远程 IP 范围最具体的那一个。这条规则是加固的关键：如果内部中继连接器把远程 IP 范围写得过宽（例如整个内网段），那么该网段内任何主机的连接都会匹配到这个高权限连接器，而不是受限的公网连接器。

因此内部中继连接器的远程 IP 范围必须逐台列出具体地址，而不是网段。每新增一台应用服务器就显式添加一条，这点运维成本换来的是权限边界清晰。

面向公网的连接器需要允许匿名用户，否则收不到外部邮件。风险不在于「允许匿名」本身，而在于是否额外授予了中继权限。

验证方法与通用开放中继自检一致：从外部主机连上 25 端口，不认证的情况下尝试把邮件投递到一个与本组织无关的外部域，必须在 RCPT 阶段被拒。任何返回 250 的情况都要立即回查该连接器的权限组配置。

同时应限制匿名连接器上的会话参数：最大消息大小、单连接最大收件人数、每源 IP 的并发连接数与连接速率、以及会话超时。这些是抵御目录收割与资源耗尽的直接手段。

587 端口的连接器应要求 TLS 且要求认证。RFC 4954 第 4 节要求服务端在未加密信道上不应宣告明文认证机制，RFC 6409 则明确提交端口需做认证——两者结合的配置结果是：先 STARTTLS，再 AUTH，未加密时不提供明文机制。

此外要对已认证会话施加限额：单账号的消息与收件人速率上限，防止账号被盗后大量外发。仅靠认证不设限额，是盗号事件损失被放大的主要原因。

其一，远程 IP 范围写成网段（见上文匹配规则），使范围内任意主机获得中继能力。其二，为图省事授予了过宽的权限组，使匿名连接也能中继。其三，允许应用以任意发件人身份发信，导致内部系统可冒用任意内部地址——这会让内部钓鱼变得极其容易，且难以追溯。

针对第三点的缓解是：为每个应用分配独立的服务账号与专用发件地址，在连接器上限定其可用的发件人地址范围，并在日志中保留提交账号与源 IP 的对应关系。

变更管理上，接收连接器配置应纳入定期审计：导出全部连接器的绑定、远程 IP 范围、权限组与身份验证设置，与登记的用途清单逐条比对，清理无主条目。绝大多数中继事故源于历史遗留的、已无人认领的连接器。