13518219792
前端时间处理过一个生产环境中的一个问题，该问题不是很复杂，但是如果不能理清思路是比较难找到方向的。下面我将问题处理过程大致分享一下。
为河南等地区用户提供了全套网页设计制作服务，及河南网站建设行业解决方案。主营业务为网站建设、成都做网站、河南网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！一、环境情况
1、WIndows 2012 R2+Exchange 2016 CU2。
2、邮件流：Internet<——>邮件网关【Symantec SMG】<——>Exchange server。
二、问题现象
Exchange通讯组设置了发送邮件需要验证【也就是说RequireSenderAuthenticationEnabled被设置为True】，但是第三方邮箱【例如：163或QQ】仍然能够给Exchange通讯组发送邮件，并且通讯组中的组成员还会收到邮件。
三、问题处理过程
刚接到这个问题，第一反应就是，首先检查一下通讯组的权限设置是否是开启了RequireSenderAuthenticationEnabled，然后再判断这种情况是个别通讯组还是全部通讯组均是这种情况。
1、首先检查了所有通讯组的设置，均开启了RequireSenderAuthenticationEnabled。并且测试了好几个通讯组均是这种情况。
2、Exchange邮件传输都是通过传输代理Agent来实现的，使用命令Get-TransportAgent查看是否有Agent工作不正常，或者是有什么其他Agent搞鬼。通过获取结果看到，TransportAgent没有任何问题。
3、接下来，有通过命令查看了发件人筛选，均没有问题。
4、尝试手动创建一个传输规则，规则内容是阻止任何外部用户给特定通讯组发送邮件。通过测试结果仍然是外部用户能够给通讯组发送邮件。各种尝试后，到这来开始怀疑是不是服务器问题或者传输服务出现问题。默认情况下，传输服务器在Exchange服务器上缓存时间是4个小时。接下来，重启了传输服务，问题依然存在。
5、查看了服务器运行时间为570天，也就是说服务器长时间未重启，怀疑是不是安装了补丁没有重启。于是将数据库副本切换到备用节点，然后逐一重启服务器。重启完成后测试，问题依然存在。
6、没有办法了，这个问题肯定是哪里遗留掉了，或者说是产品Bug。通过查看Exchange 2016 CU3-CU11修复的问题列表中，根本没有关于这个问题的描述。那么就不应该是产品Bug。
7、最后没有办法了，只能看传输日志了。之前对Exchange的传输过程研究过，正常情况下，当一封通讯组邮件发送到Exchange服务器时，Exchange服务器会进行一个Expand通讯组成员展开动作。如下：
而通过发送测试邮件，使用外部邮箱给通讯组发送测试邮件，然后使用命令查看邮件投递记录，发现在Exchange服务器上并没有执行Expand组地址展开动作，而是直接将邮件投递到了对应邮箱中。这说明什么问题呢，大胆猜测通讯组邮件在到达Exchange服务器之前就将组成员展开了，这种情况下就会是发送给通讯组的邮件直接投递到了组成员邮箱，从而绕过了通讯组验证机制。
8、为了验证我的猜测，目前大致方向能够定位在是邮件网关上替Exchange干了一个通讯组成员Expand的事情。于是接下来查看SMG的配置。在SMG的活动目录集成里面看到了SMG上启用了“Enable Distribution Expansion”【启用分发列表扩展】功能。
9、将SMG的启用分发列表扩展功能，关闭后，然后测试给通讯组发送邮件，一切恢复正常。然后通过命令查看传输日志也能够正常捕获到Expand动作。
四、建议
1、在使用邮件网关时，一定要注意关于通讯组方面的设置，设置不当会议导致垃圾邮件。
2、此案例反过来，可以作为一种解决让Exchange通讯组接收外部邮件的一个解决方法。
另外有需要云服务器可以了解下创新互联scvps.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。
