十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
前端时间处理过一个生产环境中的一个问题,该问题不是很复杂,但是如果不能理清思路是比较难找到方向的。下面我将问题处理过程大致分享一下。
为河南等地区用户提供了全套网页设计制作服务,及河南网站建设行业解决方案。主营业务为网站建设、成都做网站、河南网站设计,以传统方式定制建设网站,并提供域名空间备案等一条龙服务,秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求,就会得到认可,从而选择与我们长期合作。这样,我们也可以走得更远!一、环境情况
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许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。