背景
机房迁移事项中，需要将Exchange邮件系统迁移到新机房。 新机房部署完邮件服务器，将所有数据库做同步，再将入口切换到新机房。
现象
在灰度阶段，发现入向邮件流失败。 报错如下：
问题定位
报错很明显，是认证失败。 但是邮件系统接收其他SMTP流本身就是不认证，为什么会提示认证失败呢？
- 定位过程
-新服务器和老机房服务器配置基本保持一致，难道是前端HAProxy配置错误启用了SMTP认证？经核实，代理层并没有开启认证。
- 进一步检查邮件服务器，发现 ForwardSyncDaemon、ProvisioningRps两个组件没有启动。这两个组件和认证是没有关系的，先启用试试吧。
Set-ServerComponentState -Component ForwardSyncDaemon -Identity bj-rz-xxx -Requester HealthAPI -State Active
Set-ServerComponentState -Component ProvisioningRps -Identity bj-rz-xxx -Requester HealthAPI -State Active
启用后，测试入向邮件还是有问题。
- 通常情况下，一个单纯的邮件系统如果要接收外部组织的邮件，需要在CAS服务器的 "Defaut Frontend"接收连接器上开启匿名权限。 但是几乎所有场景下，最外部都会部署反垃圾邮件系统，CAS接收连接器并不会直接和外部通讯，而是匿名接收反垃圾邮件的SMTP入向流。 可以在"Defaut Frontend"接收连接器上启用匿名，也可以创建独立的匿名接收连接器。 如果创建了独立的匿名接受连接器，那"Defaut Frontend"就不需要勾选匿名权限了。 而我们的邮件系统就是这种配置。但是为什么还是出现认证失败的提示呢？理论上应该不认证的。
作为尝试，我们在"Defaut Frontend"勾选了匿名，发现入向邮件可以正常进入组织了。 去掉候选后，再次提示认证失败。如果只是为了让邮件进入组织，此时我们勾选匿名权限就可以了。但这种与理论不相符的现象，我们就永远解释不清了。
- 虽然在疑惑中，但是还是想进一步搞清楚这种不符合理论的现象问题出在哪？为什么老机房同样的配置一直都是正常的呢？
检查老机房的前端服务器配置，发现其中一台(CAS03)是勾选了匿名的，其他3台是没有勾选的。我们将cas03匿名去掉，入站邮件也卡是失败。基本确定，接收邮件网关的匿名接收连接器没有生效。但状态是启用的，配置也都是对的。 怎么会不生效呢？和朋友核实了下朋友公司的权限配置(场景一致)，朋友公司的接收连接器权限配置和我们的配置一样，他们却是正常的。
- 唯一的区别在于，我们的邮件系统里有两个匿名接收连接器。 一个接收连接器用于接收邮件网关的SMTP流(暂称RC1)，仅允许邮件网关的IP匿名发送。 另一个接收连接器用于接收IDC机房里需要调用邮件的接口(暂称RC2)，允许的是IDC的网段匿名发送。
也就是这两个匿名接收连机器干扰了，导致没有匹配到邮件网关的接收连接器RC1就终止了。但是问题又来了，为什么M6一直这么配置邮件流确正常呢？
原因揭晓
- 接收连接器有匹配顺序，场景中的的匹配顺序为: 先RC2后RC1。
- M6之所以入站正常，是因为邮件网关IP隶属于IDC匿名接收连接器允许的IDC网段。 邮件流能顺利入站是匹配到了RC2（IDC匿名连接器），RC1（邮件网关匿名连接器）就没用到。
- 润泽所以入站不正常，是因为润泽是新网段，因不再允许内部匿名发送，所以新段并没有加入到RC2(IDC匿名连接器)中，仅在RC1(邮件网关匿名连接器)中允许了。 但是因为匹配顺序的原因，匹配到RC2就已经拒绝了。
