本文出自Simmy的个人blog：西米在线 http://simmyonline.com/archives/549.html
这个故障弄了一下午，联合HK IT NAT team， Email team，SZ IT, DG Vendor合众之力才能完成。简单的原因是因为exchange服务器的IP，DNS等信息改了，导致与公司内部的mail gateway连接中断，邮件无法转发出去。
事件回放：S公司是LF新收购的一间英国公司，目前有自己的邮件系统，合并后，旧的邮件系统仍然存在，不过会将其旧有的邮件系统收到的邮件转到我们的新的邮件系统，也就是说，S公司目前的邮件系统的唯一功能只是转发而已。这样的话，我们需要将其邮件服务器的IP地址添加到我们的mail gateway中，并授权为外部internet服务器。
上周五，也就是8月7日，我们对S公司进行了个Network Integraion，替换了其旧有的×××设备，用我们的check point代替，重新建了×××隧道，并将其并入我们的内部网络。过程一直挺顺利的，只是在建×××到UK时有点小case，到HK及SZ都很快KO了，tracert了Applications也正常。
周一开始收到UK那边的消息说，发到S公司就邮件系统的邮件被弹回了，said：无法找到收件人地址。UK那边的Boss问回DG的同事，抄送给了HK，HK那边立即给了HKIT的big manager Eliza，然后Eliza当然首先叫Email team检查，他们检查的结果是，无法tracert或telnet到S公司邮件服务器，显示是服务器出问题或网络连接故障。然后big M就给SZ这边mail了，叫负责网络的同事查，同事知道我上周去了，于是扔回给我，我们赶紧联系DG当地的Vendor，一问，Vendor拍心口说exchange没问题，叫我们检查我们的check point是否map了POP3，110 port的地址到server，由于刚做完这个project就出事，所以我们也怀疑是这里出了问题，我立即联系上次一起负责此事的NAT同事Jackal一起检查，查了一轮后，首先发现，外部IP给Check Point ×××占了，讨论了下，虽然可以用map的方式，把IP转给exchange server，但是这样不符合公司的IT policy,于是尝试从free IP地址中，找了个给mail server，叫vendor在ISP DNS处update了到mail server的IP，再试，结果还是不行，发到旧邮件系统的邮件还是不会转发，叫vendor检查exchange，先停掉forward的功能，发现邮件都收到了，而且发到外部邮件系统如163等，是正常的，只是无法发到我们的邮件系统。Vendor技术能力有限，检查不出接下来为何转发不出去的原因。这下到HK Email Team的同事上场了，telnet, tracert,nslookup一轮，总算找到了原因，原来是与我们这边的邮件服务器连接出故障了，没办法建立连接，当然也就无法转发到用户的新邮箱了。于是，首先改DNS，将其中一个internal的DNS也改成外部的，也就是两个都是电信的DNS，然后在我们这边的mail gateway上添加S公司mail server的IP，这样连接通了，转发也就KO了。
现在回忆起自己整件事的处理过程，有点思路不清。看看Alex的处理方式，他首先是叫Vendor检查，不转发，那停掉转发的功能，自己内部收发，看能否成功，OK，好，那新邮件系统呢，相互间发送也是没问题的。这么说就是两者间的联系有问题了，那好办，邮件系统，自然是找回Email team处理。而自己一开始就完全相信Vendor说是我们这边的地址映射问题，找NAT的同事查，结果老半天也没找出原因，虽然无意中完善了一些设置，但是问题没有解决。最后检查exchange的收发记录才发现邮件都挤在队列里，无法发送出去，Email Team的同事一下就知道原因了，然后顺藤摸瓜，很快就把问题解决了。
在这个过程中，我发现Alex做事很小心谨慎，慢慢的做testing，我在一边看时还觉得这样费时，很慢呢，现在想想这不无道理。技术问题都是有逻辑性的，搞明了相关联系，就自然能找出原因。
从这件事中，我也偷师到了不少东西，技术上又有长进了，呵呵。找个机会总结下才行。
此致。虽然目前问题搞定了，但是执行人是我自己，当初改服务器IP时，没有考虑到邮件服务器方面的问题，确实是个非常大的失误，这估计给Boss的印象也不好，以后不知还有没有project跟，anyway，吃一堑，长一智，不在错误中学习，就在错误中倒下。
