看到keepwalking的Gmail事件：不是fan不fan的问题和Gmail与新浪、搜狐、网易：卡在哪里？两篇文章，我觉得这件事情不是我一个人的事情，它甚至关系到了整个中国网民的利益，而中国的网民有权利知道真相，所以我还是要把它贴出来。 收到自称是网易邮件工程师发来的邮件，他在邮件中解释了网易邮件系统无法收到Gmail邮件的原因。现把原文刊登出来。其中删除了与他本人身份相关的信息。
你好, 自我介绍一下，网易的某工作人员。看到你的blog文章，关于“三大门户封杀Gmail邮件”的问题想跟你交流交流。 最近收到网友传来的消息，说三大门户等等联合封杀gmail，开始甚是诧异。我对网易反垃圾系统再熟悉不过，知道系统上并无这样的设置。但根据我们观察的结果，网友反映的情况确实存在，也是有的邮件可以顺利收发，有的邮件超时较长，甚至无法到达。就我所了解的情况，导致这些现象的原因可能有两点： 1、Gmail和国内邮件服务商之间存在一种不知名的防火墙，这个设备的存在可能直接导致某类邮件的收发畅通问题（超时、退信、直接断开或者Discard） 2、也是这个设备的存在，会干扰Gmail与国内邮件服务商之间某些TCP连接的状态，也就是更改SMTP会话状态。这个tcp修改动作，会严重影响网易邮件系统MTA服务程序对连接状态的计数统计功能，相应也干扰了网易mta与gmai mta之间的连接，造成一些邮件延迟 对第二点，实际上我们周末已经观察到了系统的异常，火急修改mta程序防止计数器受到干扰，新的服务程序已经于昨日更新到网易邮件系统。 google相关工作人员也已经与我们进行过联系，对第二点，他们也表示理解，但对第一点，大家还找不到好的方法加以解决。不管怎样，网易邮件系统积累到今天的国内品牌地位，如果做这种下三滥的事情，岂不是自毁招牌？这一点，真心希望网友能够理解。 欢迎你跟我做一些技术性的探讨，也希望看到你这个blog文章的网友能够拨开迷雾看清本质
归类于： Src的公告 — Src @ 12:54 pm
好像有人分析过了
这么一个东西还在折腾
真是眼球经济
自己搜索一下 SMTP GFW 就知道了
并且这个也不能说是官方吧
你在搞笑吗
网易官方
收到自称是网易邮件工程师发来的邮件
FEEDSKY看来也不过如此~
评论 由 shengfang — 十一月 9, 2006 @ 1:32 pm
楼上请注意，本地只是我的个人blog，与任何公司组织无关，你可以认为我的说法不够恰当，但请不要联系其他无关的组织。我们有事说事，请不要强词夺理。
评论 由 Src — 十一月 9, 2006 @ 1:57 pm
找出GFW在Internet的位置
作者：刘宏光
邮件：iceblood_at_163.com
网址：http://www.nettf.net
日期：2006-9-26
看到这篇文章的标题，可能有人要问GFW到底是什么？虽然GFW在一部分人的眼睛里并不陌生了，但相对与大部分人来说还是非常陌生的，引用我在google里找到的一段话：
The Great Fire Wall of China的简写，意指“中国网络防火墙”(字面意为“中国防火长城”)，这是对“国家公共网络监控系统”的俗称，国内简称“防火长城”。
GFW是“金盾工程”的一个子功能。“金盾工程”是以公安信息网络为先导，以各项公安工作信息化为主要内容，建立统一指挥、快速反应、协同作战机制，在全国范围内开展公安信息化的工程，主要包括建设公安综合业务通信网、公安综合信息系统、全国公安指挥调度系统以及全国公共网络监控中心等。该项目2003年开始生效。一般所说的GFW，主要指公共网络监控系统，尤其是指对境外涉及敏感内容的网站、IP地址、关键词、网址等的过滤。
GFW的效果通常为，国内网络用户无法访问某些国外网站或者网页；或者国外网络用户无法访问国内的某些网站或者网页。这里的无法访问，有永久性的无法访问（比如色情网站），也有因为URL中含有敏感关键词或者网页上有敏感内容而暂时性的无法访问。
国家防火墙并非中国的专利。实际上，美国也有国家网络监控系统，对进出美国的每一封电子邮件进行内容扫描。不同的是，中国的国家防火墙会直接切断敏感连接，而美国的国家防火墙（考虑更名）则只是做数据监控记录。伊朗、巴基斯坦、乌兹别克斯坦、北非共和国、叙利亚、缅甸、马尔代夫、古巴、北韩、南韩、沙特阿拉伯、阿拉伯联合酋长国、也门使用与金盾类似的国家防火墙。
看了以上这段话相信大家都比较清楚GFW到底是什么了，但是一直有人说有GFW，但具体的位置在哪里呢？我们如何查出GFW到底在哪里呢？好象并没多少文章有介绍，所以我这里针对这点特别写了这篇文章。
GFW这个东西很早我就已经知道，并且为防止GFW的“骚扰”我已经想过了很多办法来避免了，但由于收到外界机制的影响，仍然不可能完全避过GFW，而最近我所在的公司发到国外的邮件总是受阻，严重影响了公司的正常业务，所以我必须给他们一个非常圆满的答复，才有了找到GFW的位置的想法。
最近我们公司总是有人反应发到日本的邮件会被退回来，我查看了一下退信内容，发现主要有如下内容：
:
xxx.xxx.xxx.xxx does not like recipient.
Remote host said: 551 User not local; please try
Giving up on xxx.xxx.xxx.xxx.
或者：
:
xxx.xxx.xxx.xxx does not like recipient.
Remote host said: 500 error
Giving up on xxx.xxx.xxx.xxx.
而在邮件服务器的日志上发现如下内容：
Sep 26 14:46:23 livedoor qmail: 1159253183.972578 delivery 118310: failure: xxx.xxx.xxx.xxx_does_not_like_recipient./Remote_host_said:_500_error/Giving_up_on_xxx.xxx.xxx.xxx./
由于总报这样的问题，所以我在公司的网关服务器上安装上snort这个入侵检测软件，当然我并没发挥入侵检测的功能，因为我只想要里面的sniff功能探测数据包，然后等待这种现象的再次来到。当邮件日志里再次出现上面的日志内容的时候，我进入网关服务器查找所有相关这个IP的记录，并且根据时间找到了：
-rw——- 1 root wheel 6941 Sep 26 14:44 TCP:60661-25
现在就请大家跟着我来分析这个文件：
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:52.643691 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0×800 len:0×4E
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0×0 ID:32988 IpLen:20 DgmLen:64 DF
******S* Seq: 0×2E68FF24 Ack: 0×0 Win: 0xFFFF TcpLen: 44
TCP Options (8) => MSS: 1460 NOP WS: 1 NOP NOP TS: 121485349 0
TCP Options => SackOK EOL
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
这是我们公司的邮件服务器10.4.1.4向对方发送SYN的请求包，TTL为127，虽然我们的邮件服务器是FreeBSD，但我还是把TTL修改为128了，而邮件服务器和网关服务器之间有一个路由，所以TTL会减1，就成为了127。
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:52.744474 0:14:22:1F:4A:49 -> 0:11:43:58:71:FF type:0×800 len:0×4A
203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:49 TOS:0×0 ID:0 IpLen:20 DgmLen:60 DF
***A**S* Seq: 0×1527A9A1 Ack: 0×2E68FF25 Win: 0×16A0 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 9713757 121485349 NOP
TCP Options => WS: 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
这里为对方服务器向我们公司的服务器回复SYN+ACK包。可以看到TTL为49，由于对方也是FreeBSD系统，而FreeBSD的默认TTL值为64，这样我们可以计算出我们的服务器到对方的服务器经过的路由数，64减49等于15，所以网关服务器到对方服务器经过了15个路由，使用traceroute命令追踪了一下结果，如下：
gw2# traceroute -n 203.131.198.80
traceroute to 203.131.198.80 (203.131.198.80), 64 hops max, 40 byte packets
1 210.83.214.161 0.722 ms 0.699 ms 0.612 ms
2 210.83.193.49 0.595 ms 0.486 ms 0.615 ms
3 210.52.131.6 16.979 ms 16.978 ms 16.975 ms
4 210.52.130.10 46.711 ms 45.836 ms 45.838 ms
5 210.52.132.230 50.208 ms 49.957 ms 50.085 ms
6 210.53.126.2 50.083 ms 49.955 ms 50.334 ms
7 202.147.16.125 50.583 ms 50.207 ms 50.587 ms
8 202.147.16.205 51.204 ms 50.081 ms 50.209 ms
9 202.147.16.214 103.055 ms 103.050 ms 103.179 ms
10 202.147.0.206 99.803 ms 99.677 ms 99.806 ms
11 203.192.131.250 103.802 ms 103.549 ms 103.430 ms
12 203.174.64.13 99.804 ms 100.053 ms 100.681 ms
13 203.174.64.146 100.056 ms 100.799 ms 102.075 ms
14 203.174.64.214 101.012 ms 99.676 ms 100.179 ms
15 203.131.198.80 100.805 ms 99.926 ms 99.929 ms
gw2#
这里可以很清楚的看到为15跳，充分证明了TTL没有任何问题，而对方的服务器也没有使用防火墙以及NAT来映射25号端口。
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:52.744633 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0×800 len:0×42
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0×0 ID:33011 IpLen:20 DgmLen:52 DF
***A**** Seq: 0×2E68FF25 Ack: 0×1527A9A2 Win: 0×8218 TcpLen: 32
TCP Options (3) => NOP NOP TS: 121485450 9713757
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
这里是我们公司返回一个ACK包，这样整个TCP连接的握手成功，接下来就要开始传输数据了。
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:52.845542 0:14:22:1F:4A:49 -> 0:11:43:58:71:FF type:0×800 len:0×93
203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:49 TOS:0×0 ID:37317 IpLen:20 DgmLen:133 DF
***AP*** Seq: 0×1527A9A2 Ack: 0×2E68FF25 Win: 0×16A0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 9713767 121485450
32 32 30 20 35 61 2D 70 30 37 2D 62 33 2E 64 61 220 5a-p07-b3.da
74 61 2D 68 6F 74 65 6C 2E 6E 65 74 20 46 2D 53 ta-hotel.net F-S
65 63 75 72 65 2F 76 69 72 75 73 67 77 5F 73 6D ecure/virusgw_sm
74 70 2F 32 32 30 2F 35 61 2D 70 30 37 2D 62 33 tp/220/5a-p07-b3
2E 64 61 74 61 2D 68 6F 74 65 6C 2E 6E 65 74 0D .data-hotel.net.
0A .
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
首先是对方服务器给了我们一个220的服务器信息。
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:52.845826 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0×800 len:0×54
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0×0 ID:33066 IpLen:20 DgmLen:70 DF
***AP*** Seq: 0×2E68FF25 Ack: 0×1527A9F3 Win: 0×8218 TcpLen: 32
TCP Options (3) => NOP NOP TS: 121485551 9713767
48 45 4C 4F 20 6C 69 76 65 64 6F 6F 72 2E 63 6E HELO livedoor.cn
0D 0A ..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
我们的服务器给对方发送了一个SMTP协议所需要的HELO信息。由于内容太多中间SMTP协议的握手我就不再详细介绍了，所以我这里直接跳到出问题的地方。
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:53.049710 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0×800 len:0×6B
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0×0 ID:33110 IpLen:20 DgmLen:93 DF
***AP*** Seq: 0×2E68FF56 Ack: 0×1527AA19 Win: 0×8218 TcpLen: 32
TCP Options (3) => NOP NOP TS: 121485755 9713787
52 43 50 54 20 54 4F 3A 3C 6A 69 6D 67 72 65 65 RCPT TO:..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
在这里，当我们的服务器发送RCPT To的信息到对方服务器以后，按照SMTP协议的原理，对方在有这个用户的情况下应该返回250 ok这个信息，但是这个时候问题出现了，我们的服务器马上收到一个如下的信息：
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:53.103763 0:14:22:1F:4A:49 -> 0:11:43:58:71:FF type:0×800 len:0×41
203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:57 TOS:0×0 ID:64 IpLen:20 DgmLen:51
***AP*** Seq: 0×1527AA19 Ack: 0×2E68FF7F Win: 0×0 TcpLen: 20
35 30 30 20 65 72 72 6F 72 0D 0A 500 error..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
500 error的信息，再看看TTL的值，57？对端服务器的TTL由49突然变成了57？理论上来说说不过去，再接着看后面的信息：
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:53.154738 0:14:22:1F:4A:49 -> 0:11:43:58:71:FF type:0×800 len:0×4A
203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:49 TOS:0×0 ID:37321 IpLen:20 DgmLen:60 DF
***AP*** Seq: 0×1527AA19 Ack: 0×2E68FF7F Win: 0×16A0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 9713798 121485755
32 35 30 20 4F 6B 0D 0A 250 Ok..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
这才是真是服务器发送过来的信息，而由于500 error的错误信息比250 Ok的正确信息先到达我们的服务器，所以我们的服务器这个时候就已经认为对方服务器错误，所以按照SMTP协议必须终止邮件的发送，所以这个时候我们的服务器发送：
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:53.155026 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0×800 len:0×48
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0×0 ID:33131 IpLen:20 DgmLen:58 DF
***AP**F Seq: 0×2E68FF7F Ack: 0×1527AA24 Win: 0×8218 TcpLen: 32
TCP Options (3) => NOP NOP TS: 121485860 9713787
51 55 49 54 0D 0A QUIT..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
QUIT退出……，就这样一封正常的邮件被活生生的截断了。
现在我们来开始看那个TTL为57的信息，根据我的经验对方的TTL默认值应该是64，所以64减57等于7，也就是说这个阻断我们信息的信号来自和第7个路由同网断或者就是第7个路由。现在再看看我最上面的traceroute的结果：
gw2# traceroute -n 203.131.198.80
traceroute to 203.131.198.80 (203.131.198.80), 64 hops max, 40 byte packets
1 210.83.214.161 0.722 ms 0.699 ms 0.612 ms
2 210.83.193.49 0.595 ms 0.486 ms 0.615 ms
3 210.52.131.6 16.979 ms 16.978 ms 16.975 ms
4 210.52.130.10 46.711 ms 45.836 ms 45.838 ms
5 210.52.132.230 50.208 ms 49.957 ms 50.085 ms
6 210.53.126.2 50.083 ms 49.955 ms 50.334 ms
7 202.147.16.125 50.583 ms 50.207 ms 50.587 ms
评论 由 F*ck GFW — 十一月 9, 2006 @ 3:06 pm
希望博主多写点有意思的东西，不要再重复这种垃圾信息了。
评论 由 tantan — 十一月 9, 2006 @ 3:12 pm
学习中。。
没关系， 发给谁的用谁的邮箱。
不过从可信度来说 谁会超过gmail 呢。
评论 由 学习中。。。 — 十一月 9, 2006 @ 4:26 pm
其实不喜欢说他什么，从有gmail以后，把163.com
126.com的邮箱的密码和密码提示改了乱七八糟的，自己也不知道是什么密码和密码提示
sina的邮箱的那个速度我这边是实在不敢恭维，gmail现在有时候比较慢但是相对sina来说是快le，
163和126的邮箱早就不用了，原因很简单，有次上邮箱他说我的邮箱被封了，问原因就说因为非法的原因被封，我实在想不起来，因为做论坛的需要，申请的邮箱两天不到就被封怎么可能有什么非法的原因呢，骂了一顿客服就不在用了。
sina是有时要去上面找点东西，才保留到现在。
评论 由 ronghai — 十一月 9, 2006 @ 6:07 pm
这个声明已经很底线了。
评论 由 nings — 十一月 9, 2006 @ 8:55 pm
[…] 网易官方澄清Gmail被封真相 (tags: gfw) […]
Pingback 由 网摘日日看 » links for 2006-11-09 — 十一月 10, 2006 @ 7:35 am
网易的说法（假设是）真有趣。和我从Google那得到的官方消息完全相反:)
评论 由 幻灭 — 十一月 10, 2006 @ 4:13 pm
[…] 自从网易官方澄清Gmail被封真相后，很多网友还是提出了自己的质疑，主要疑点认为，如果确实像网易的工程师所说是“某个不知名的墙”所造成的，那么同为国内的邮件服务商Yahoo，腾讯等为什么没有出现这样的问题，而偏偏是所谓的三大门户遇到这样的问题。 […]
Pingback 由 IT与人性|Src’s Blog » 网易在撒谎！Gmail事件没那么简单 — 十一月 10, 2006 @ 4:50 pm
明显是GFW的所为嘛,哪有三个门户一起屏蔽的!!!
评论 由 gfssdfasf — 十一月 10, 2006 @ 6:49 pm
Damn those nototious mail service provider s in China.
评论 由 pk — 十一月 10, 2006 @ 8:29 pm
[…] 阅读全文：网易官方澄清Gmail被封真相 Explore posts in the same categories: 互联网 […]
Pingback 由 GFansBlog » Blog Archive » 网易官方澄清Gmail被封真相 — 十一月 11, 2006 @ 1:08 am
:ŻGmail¼
:ŻGmail¼oBlog Created
Trackback 由 ɹ(GUGUA) — 十一月 12, 2006 @ 12:35 am
[…] 相关阅读：国内三大门户联合封杀Gmail！Google fans声讨三大门户，可否出来澄清真相网易官方澄清Gmail被封真相网易在撒谎！Gmail事件没那么简单[转]找出GFW在Internet的位置为什么Google在中国看不到前途 归类于： Src关注网络 — Src @ 4:41 pm […]
Pingback 由 IT与人性|Src’s Blog » 如何降低Gmail事件对你的影响 — 十一月 14, 2006 @ 5:33 pm
话说网易的邮箱服务确实很差，因为我的附件过多（没超过1g）把我从00年开始用了5年多的帐号封了，客服态度也很差！！！
评论 由 iamnin — 十一月 15, 2006 @ 6:03 pm
[…] 阅读全文：网易官方澄清Gmail被封真相 Explore posts in the same categories: 互联网 >>> Tags: none […]
Pingback 由 GFansBlog » Blog Archive » 网易官方澄清Gmail被封真相 — 十一月 16, 2006 @ 10:56 pm