青蛙

GFW增加一网关导致中国发送海外邮件难度加大

从2007年7月15日左右，大量发往国外（包括港澳台）的邮件不成功，


退信表现为超时，丢失连接，' User not local; please try <forward-path>';
aaazzzaaazzzz....
还是国家防火墙(GFW)过滤导致！

GFW：
GFW（防火长城），也称“中国防火墙”或“中国国家防火墙”，指中华人民共和国政
府在其管辖互联网内部建立的多套网络审查系统的总称，包括金盾系统和相关行政审查
系统。一般情况下主要指中国对互联网内容进行自动审查和过滤监控、由计算机与网络
设备等软硬件所构成的系统。

如果希望暂时避开GFW，可以把邮件内容写在txt或word文档中，并用RAR或ZIP压缩后以附件的形式发送。

国内几乎所有发送海外邮件的用户都不同程度的受到影响。特别是国际贸易公司、进出口公司等视企业邮件为公司的生命线的公司，日常和国外客户、总部及代理商的几乎所有沟通均须通过企业电子邮件传递，此次GFW增加网关，对其海外业务造成了严重的影响。

据悉，这样的情况一般用户和运营商，都无力解决。

此次邮件故障经常表现为：

(host alt1.gmail-smtp-in.l.google.com[64.233.167.114]
said: 551 User not local; please try

lost connection with mx21.Forever21.com[65.125.176.131] while sending MAIL FROM

以及邮件内容被替换为：

AAAAZZZZZAAAAZZZZAAAZZZZ

等莫名其妙的情况

所有海外邮件投递问题的解决，无论是接收还是发送，都必须在物理上建立海外服务器的方式，并且在海外服务器和国内之间的传输上，采取加密措施，从而规避国际出口问题。

如果无物理上的海外服务器，或者是没有有效加密邮件传输技术的，从根本上，都无法解决海外邮件传输问题。


建议应急解决方案：
1、
考虑使用一些大型ISP提供的付费邮箱，比如YAHOO 网易等，需要该邮箱提供为你的服务器中继功能，具体设置“设置”－“主域”－“递送”－“尝试直接发送邮件，但无法直接发送的邮件发送到下列指定邮件服务器”（然后输入指定的服务器的IP地址或者主机名）
*该方法是应急方案，可以暂时缓解客户的邮件发送的问题，邮件发送的数量有限。

暂时使用hotmail, gmail 等国外邮件服务，在线发送邮件即可


2、待国家公共网络监控系统系统设置调整后，邮件收发会自动恢复正常。

具体原因请继续关注本帖

青蛙

从前天下午开始，上海电信在线电子客服电话就一直处于忙音状态，发往海外的邮件退信率极高。

是什么原因导致退信呢？
服务器在投递邮件后遇到对方的返回代码，邮件系统便中断了此封邮件的发送，产生退信。在此过程中首先远程主机提示回拒的代码后中断投递。回拒的代码可能来自对方服务器，或者还未到达对方服务器，在中间环节（可能是某个网络设备）回退的代码。从这几封退信中，退信统一为：551 User not local;please try <forward-path> ，经过观察发现，目前邮件都是发往国外有出现退信，且多是时而成功接受时而被拒退信。排除了发信服务器的问题根据退信代码查询网上相关资料。如排除对方服务器拒绝外则有以下可能性原因：
1.用户本地或者用户网络代理服务器中，杀毒软件或者防火墙开启了smtp防护功能。
2.国家公共网络监控系统GFW，对于发往国外的邮件做监控拦截导致退信
如果是第一种情况则可以在电脑中关闭SMTP发送监控。如果是第二种情况则只能等待GFW减弱监控拦截。
根据目前的检查结果，发往国外的邮件有发现两次回应信息，其中之一可能是由GFW回应的。因此怀疑是GFW截断导致退信

如何解决呢？
请尝试将outlook中的服务器设置"发送邮件（SMTP）"改为：smtp1.shaidc.com

青蛙

以下文字来自各处的搜索

GFW到底是什么？虽然GFW在一部分人的眼睛里并不陌生了，但相对与大部分人来说还是非常陌生的，引用我在google里找到的一段话：
    The Great Fire Wall of China的简写，意指“中国网络防火墙”(字面意为“中国防火长城”)，这是对“国家公共网络监控系统”的俗称，国内简称“防火长城”。
    GFW是“金盾工程”的一个子功能。“金盾工程”是以公安信息网络为先导，以各项公安工作信息化为主要内容，建立统一指挥、快速反应、协同作战机制，在全国范围内开展公安信息化的工程，主要包括建设公安综合业务通信网、公安综合信息系统、全国公安指挥调度系统以及全国公共网络监控中心等。该项目2003年开始生效。一般所说的GFW，主要指公共网络监控系统，尤其是指对境外涉及敏感内容的网站、IP地址、关键词、网址等的过滤。
    GFW的效果通常为，国内网络用户无法访问某些国外网站或者网页；或者国外网络用户无法访问国内的某些网站或者网页。这里的无法访问，有永久性的无法访问（比如色情网站），也有因为URL中含有敏感关键词或者网页上有敏感内容而暂时性的无法访问。
    国家防火墙并非中国的专利。实际上，美国也有国家网络监控系统，对进出美国的每一封电子邮件进行内容扫描。不同的是，中国的国家防火墙会直接切断敏感连接，而美国的国家防火墙（考虑更名）则只是做数据监控记录。伊朗、巴基斯坦、乌兹别克斯坦、北非共和国、叙利亚、缅甸、马尔代夫、古巴、北韩、南韩、沙特阿拉伯、阿拉伯联合酋长国、也门使用与金盾类似的国家防火墙。
    看了以上这段话相信大家都比较清楚GFW到底是什么了，但是一直有人说有GFW，但具体的位置在哪里呢？我们如何查出GFW到底在哪里呢？好象并没多少文章有介绍，所以我这里针对这点特别写了这篇文章。
    GFW这个东西很早我就已经知道，并且为防止GFW的“骚扰”我已经想过了很多办法来避免了，但由于收到外界机制的影响，仍然不可能完全避过GFW，而最近我所在的公司发到国外的邮件总是受阻，严重影响了公司的正常业务，所以我必须给他们一个非常圆满的答复，才有了找到GFW的位置的想法。
    最近我们公司总是有人反应发到日本的邮件会被退回来，我查看了一下退信内容，发现主要有如下内容：
<xxx@xxxxx.xxx>:
xxx.xxx.xxx.xxx does not like recipient.
Remote host said: 551 User not local; please try <forward-path>
Giving up on xxx.xxx.xxx.xxx.
或者：
<xxxx@xxxxxxx.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:0x800 len:0x4E
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:32988 IpLen:20 DgmLen:64 DF
******S* Seq: 0x2E68FF24  Ack: 0x0  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:0x800 len:0x4A
203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:49 TOS:0x0 ID:0 IpLen:20 DgmLen:60 DF
***A**S* Seq: 0x1527A9A1  Ack: 0x2E68FF25  Win: 0x16A0  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:0x800 len:0x42
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:33011 IpLen:20 DgmLen:52 DF
***A**** Seq: 0x2E68FF25  Ack: 0x1527A9A2  Win: 0x8218  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:0x800 len:0x93
203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:49 TOS:0x0 ID:37317 IpLen:20 DgmLen:133 DF
***AP*** Seq: 0x1527A9A2  Ack: 0x2E68FF25  Win: 0x16A0  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:0x800 len:0x54
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:33066 IpLen:20 DgmLen:70 DF
***AP*** Seq: 0x2E68FF25  Ack: 0x1527A9F3  Win: 0x8218  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:0x800 len:0x6B
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:33110 IpLen:20 DgmLen:93 DF
***AP*** Seq: 0x2E68FF56  Ack: 0x1527AA19  Win: 0x8218  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:<xxxxx
6E 40 6E 65 70 74 75 6E 65 2E 6C 69 76 65 64 6F  x_at_neptune.livedo
6F 72 2E 63 6F 6D 3E 0D 0A                      or.com>..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
在这里，当我们的服务器发送RCPT To的信息到对方服务器以后，按照SMTP协议的原理，对方在有这个用户的情况下应该返回250 ok这个信息，但是这个时候问题出现了，我们的服务器马上收到一个如下的信息：
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:53.103763 0:14:22:1F:4A:49 -> 0:11:43:58:71:FF type:0x800 len:0x41
203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:57 TOS:0x0 ID:64 IpLen:20 DgmLen:51
***AP*** Seq: 0x1527AA19  Ack: 0x2E68FF7F  Win: 0x0  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:0x800 len:0x4A
203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:49 TOS:0x0 ID:37321 IpLen:20 DgmLen:60 DF
***AP*** Seq: 0x1527AA19  Ack: 0x2E68FF7F  Win: 0x16A0  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:0x800 len:0x48
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:33131 IpLen:20 DgmLen:58 DF
***AP**F Seq: 0x2E68FF7F  Ack: 0x1527AA24  Win: 0x8218  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  <——可能发送错误信息的IP
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  <——真实服务器的IP
gw2#
使用 http://www.linkwan.com/gb/broadmeter/VisitorInfo/QureyIP.asp 的IP地址查询查到 202.147.16.125 属于澳大利亚，难道澳大利亚在监视我们的网络，想想虽然有这个可能性，但应该不会明显到这个程度。所以我想应该不是这个IP地址，然后我查了查第6跳的IP地址 210.53.126.2 ，通过查询显示为“中国网通”很明显6和7之间就是中国网通的出口路由，那么GFW就顺理成章安装在 210.53.126.2 这个IP之后。
    从上面的分析我们就可以完全的肯定阻断公司邮件正常来往的就是 210.53.126.2 之后的GFW发送的假信息。还好公司的邮件全都是正常的，GFW并不会完全封死，所以过段时间以后会自动恢复。由于发送的邮件非常多，也不一定是同一个服务器，所以不能用VPN来解决，不太现实。当碰到这样的问题的时候我们目前只怕唯一能做的就是等待，直到 GFW恢复我们的网络。

青蛙

双通道到底是什么东西?
答：利用全速在北美地区的网络资源及服务器资源，提供专门的发送邮件通道。即使一封信抄送给250个目标地址，如果使用双通道，每封信都可顺利发出，到达对方地址后也不会被当成是垃圾邮件。这样就可以避开国内邮件服务器对发送群发商务邮件的种种限制了。

为什么用双通道一秒钟发送几百人，都不会被别人屏蔽?
答：众所周知，美国是世界反垃圾邮件立法最早的国家，在防范垃圾邮件方面技术最全面。那么当我们在一秒钟发送250封信出去，是否会造成收信服务器的屏蔽呢？——不会的，因为服务器按照欧美地区严格的防范垃圾邮件的标准，对较高频率的邮件自动进行排队，间隔数十秒不等的时间逐一发出，所以邮件可能会有最多20分钟的延迟，但保证每封邮件都可以顺利发送出去。
    对于外贸公司用户来说，经常发生国外的ISP因为用户使用的企业邮箱IP在国内被封锁的情况，邮件到达率不理想。使用双通道之后，邮件从美国服务器发出，被欧美ISP封锁的情况基本不会出现。所以双通道使用之后，您和外国客户通信的邮件到达率增高，直接为您创造效益。


目前由于等原因，中国和国外的邮件通信一片惨象，海外邮件收发出现退信或丢失可以说是家常便饭。而面对这种情况，更是集中了几种表现：

1）企业自建服务器：对于这种情况束手无策，毫无办法。只能够考虑更换外包方式，或者继续忍受；
2）非专业邮件服务商：他们一般也不会投入海外服务器进行处理，或者投入海外服务器无论从能力还是技术上，都比较薄弱（比如无加密，无智能DNS），从而无法有效解决海外转发问题

青蛙

一、什么是GFW？
GFW是The Great Fire Wall of China的简写，指“中国网络防火墙”(字面意为“中国防火长城”)，这是对“国家公共网络监控系统”的俗称，国内简称“防火长城”。
GFW是“金盾工程”的一个子功能。“金盾工程”是以公安信息网络为先导，以各项公安工作信息化为主要内容，建立统一指挥、快速反应、协同作战机制，在全国范围内开展公安信息化的工程，主要包括建设公安综合业务通信网、公安综合信息系统、全国公安指挥调度系统以及全国公共网络监控中心等。该项目2003年开始生效。一般所说的GFW，主要指公共网络监控系统，尤其是指对境外涉及敏感内容的网站、IP地址、关键词、网址等的过滤。

二、GFW工作方式
GFW是专门用来对付国外网站的，但并不是全部国外的网站都会被封锁。那什么样的网站会被GFW封锁？GFW采用什么方法封锁？
GFW主要的工作方式有以下三种：
域名劫持
全球一共有13组根（Root）级别的DNS服务器，目前中国大陆已有多台DNS镜像。但没有一组受中国大陆直接控制，所以中国大陆方面未能从根本上控制网站域名。于是，中国大陆采取域名劫持手段来进行封锁中国大陆以外的“不合规格”的站点。域名劫持就是在劫持的网络范围内拦截域名解析的请求，分析请求的域名，把审查范围以外的请求放行，否则直接返回假的IP地址或者什么也不做使得请求失去响应，其效果就是对特定的网址不能访问或访问的是假网址。
简单的说，域名劫持是阻止人们直接访问某个域名所绑定的网站。GFW采用这种手段来阻止中国大陆网民访问部分中国大陆以外的网站。例如说，一个反对中国1111的网站地址为www.fg.com，若www.fg.com被劫持了，那么www.fg.com将无法访问。
国家入口网关的IP封锁
这个技术和上面的域名劫持有点相似，只不过域名劫持封锁的是域名，但IP封锁是直接封锁网站所在服务器的IP地址。很多对电脑比较了解的网民开始采取代理服务器的方式访问被封锁的站点，所以GFW也封锁了网民常用的一部份代理服务器的IP地址。
主干路由器关键字过滤阻断
这个技术有点复杂，那么我们来举个例子吧：
当你做飞机的时候，要进行安全检查，若你的行李里有违禁物品的话，将无法通过安检。
GFW相当于安全检查机器。当你访问一个国外网站的时候，必须经过GFW。GFW会检查目标网站的内容，若目标网站内含有敏感的词语的话，GFW将会切断你和目标网站的链接。当你使用海外的搜索引擎的时候，GFW会对你输入进搜索引擎的关键词进行审查，若你输入了敏感的关键词的话，GFW将会切断你和搜索引擎的链接。
对于邮件具体表现为：
如果邮件标题或内容有被GFW认为是所谓的敏感字符，会被GFW将数据包截获并自动抛弃，随即断开源IP与目标IP的连接，断开时间随敏感字符的严重性不等。换而言之如果公司采用NAT上网，使用pop3自动收取邮件，并且邮件服务器在国外，只要有一个被GFW认为带敏感字符的邮件，那么整个公司都将再也无法和这个server联系。

三、具体症状
Queue内出现大量无法发送至国外、HK及TW的邮件，maillog错误如下：
conversation with 111.111.0.0[111.111.0.0] timed out while sending MAIL FROM
lost connection with 111.111.0.0[111.111.0.0] while sending message body
host 111.111.0.0[111.111.0.0] said: 500 error (in reply to MAIL FROM command)
?
而未能收到邮件的对方却往往会收到一封或多封内容为“aaazzzaaazzzaaazzzaaazzzaaazzz”的无主题邮件

国外、HK及TW发往国内的邮件也会因为GFW而无法投递，退信显示如下错误:
Remote host said: not local; please try <forward-path>
551 User not local; please try <forward-path>

四、解决方案
A. Mail Server与MUA不在同一国家
对于服务器与MUA不在同一国家造成无法正常使用POP3、SMTP收取邮件的情况可以采用加密的Webmail (https)或POP3s、SMTPS解决。

B.国内MTA 发送邮件至国外、HK及台湾地区MTA
1).使用国外的邮件服务，比如hotmail，gmail来发送;
2).绕开GFW，或者加密通信通道。比如使用SSL加密，连接到海外邮件服务器，再转发email。或者使用VPN连接到海外，凡是发出去的emali全部走vpn通道。

青蛙

使用Postfix TLS突破GFW封锁



本次采用Postfix的TLS实现SSL加密连接到海外邮件服务器，再转发email的方案突破GFW的封锁，经实际环境测试效果非常好。

1.TLS含义
Transport Layer Security (TLS, formerly called SSL) provides certificate-based authentication and encrypted sessions. An encrypted session protects the information that is transmitted with SMTP mail or with SASL authentication.

2.系统要求
Postfix 2.3以上并且编译支持TLS

3.具体实现
假设现有两台安装postfix的Mail Server, 主服务器在国内 (简称CN)有健全的邮件收发功能，转发服务在加拿大(简称CA)，且各自拥有MX记录与Internet固IP。

1). Mail flow:
Mail (CN) => yahoo.com => postfix transport_maps (CN) => TLS => postfix (CA) => yahoo.com

2). CN主机配置

main.cf:
# relay setting via TLS
transport_maps = hash:/etc/postfix/transport_maps
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy_maps

transport_maps：
yahoo.com    smtp:[CA主机域名]

tls_policy_maps：
[CA主机域名]    encrypt

postmap /etc/postfix/transport_maps
postmap /etc/postfix/tls_policy_maps


3). CA主机配置

main.cf:
# TLS relay config
mydestination = $mynetworks
smtpd_banner = $myhostname TLS enabled $mail_name - by extmail.org
smtpd_tls_security_level = encrypt
smtpd_use_tls = yes
smtpd_tls_auth_only = no
smtp_tls_CAfile = /etc/postfix/tls/smtpd.pem
smtp_tls_cert_file = /etc/postfix/tls/smtpd.pem
smtp_tls_key_file = /etc/postfix/tls/smtpd.pem
smtpd_tls_CAfile = /etc/postfix/tls/smtpd.pem
smtpd_tls_cert_file = /etc/postfix/tls/smtpd.pem
smtpd_tls_key_file = /etc/postfix/tls/smtpd.pem
smtpd_tls_received_header = yes
smtpd_tls_loglevel = 0
smtpd_starttls_timeout = 60s
mynetworks = 127.0.0.1 111.111.0.0 (CA主机IP)

4). TLS cert generation (CA)

mkdir /etc/postfix/tls
建立mkcert和smtpd.cnf文件，内容如下:

mkcert:
# package installation routine.
test -x /usr/bin/openssl || exit 0
prefix="/etc/postfix/tls"
if test -f /etc/postfix/tls/smtpd.pem
then
    echo "$prefix/smtpd.pem already exists."
    exit 1
fi
umask 077
cp /dev/null $prefix/smtpd.pem
chmod 600 $prefix/smtpd.pem
chown root $prefix/smtpd.pem
cleanup() {
    rm -f $prefix/smtpd.pem
    rm -f $prefix/smtpd.rand
    exit 1
}
dd if=/dev/urandom of=$prefix/smtpd.rand count=1 2>/dev/null
/usr/bin/openssl req -new -x509 -days 365 -nodes \
    -config $prefix/smtpd.cnf -out $prefix/smtpd.pem -keyout $prefix/smtpd.pem || cleanup
/usr/bin/openssl gendh -rand $prefix/smtpd.rand 512 >>$prefix/smtpd.pem || cleanup
/usr/bin/openssl x509 -subject -dates -fingerprint -noout -in $prefix/smtpd.pem || cleanup
rm -f $prefix/smtpd.rand


smtpd.cnf:
RANDFILE = /etc/postfix/tls/smtpd.rand
[ req ]
default_bits = 1024
encrypt_key = yes
distinguished_name = req_dn
x509_extensions = cert_type
prompt = no
[ req_dn ]
C=CN
ST=SH
L=ShangHai
O=ExtMail Server
OU=Automatically-generated SMTPD SSL key
CN=localhost
emailAddress=postmaster@extmail.org
[ cert_type ]
nsCertType = server


chmod 755 /etc/postfix/tls/mkcert
./mkcert


本内容转自extmail.org

青蛙

找出GFW在Internet的位置，全面分析国内到国外邮件受阻的原因

一般所说的GFW，主要指公共网络监控系统，尤其是指对境外涉及敏感内容的网站、IP地址、关键词、网址等的过滤。GFW的效果通常为，国内网络用户无法访问某些国外网站或者网页；或者国外网络用户无法访问国内的某些网站或者网页。这里的无法访问，有永久性的无法访问（比如色情网站），也有因为URL中含有敏感关键词或者网页上有敏感内容而暂时性的无法访问。国家防火墙并非中国的专利。实际上，美国也有国家网络监控系统，对进出美国的每一封电子邮件进行内容扫描。不同的是，中国的国家防火墙会直接切断敏感连接，而美国的国家防火墙（考虑更名）则只是做数据监控记录。伊朗、巴基斯坦、乌兹别克斯坦、北非共和国、叙利亚、缅甸、马尔代夫、古巴、北韩、南韩、沙特阿拉伯、阿拉伯联合酋长国、也门使用与金盾类似的国家防火墙。看了以上这段话相信大家都比较清楚GFW到底是什么了，但是一直有人说有GFW，但具体的位置在哪里呢？我们如何查出GFW到底在哪里呢？好象并没多少文章有介绍，所以我这里针对这点特别写了这篇文章。GFW这个东西很早我就已经知道，并且为防止GFW的“骚扰”我已经想过了很多办法来避免了，但由于收到外界机制的影响，仍然不可能完全避过GFW，而最近我所在的公司发到国外的邮件总是受阻，严重影响了公司的正常业务，所以我必须给他们一个非常圆满的答复，才有了找到GFW的位置的想法。最近我们公司总是有人反应发到日本的邮件会被退回来，我查看了一下退信内容，发现主要有如下内容：<xxx@xxxxx.xxx>:xxx.xxx.xxx.xxx does not like recipient.Remote host said: 551 User not local; please try <forward-path>Giving up on xxx.xxx.xxx.xxx.或者：xxxx@xxxxxxx.xxx:xxx.xxx.xxx.xxx does not like recipient.Remote host said: 500 errorGiving 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:0x800 len:0x4E 10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:32988 IpLen:20 DgmLen:64 DF******S* Seq: 0x2E68FF24 Ack: 0x0 Win: 0xFFFF TcpLen: 44TCP 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:0x800 len:0x4A203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:49 TOS:0x0 ID:0 IpLen:20 DgmLen:60 DF***A**S* Seq: 0x1527A9A1 Ack: 0x2E68FF25 Win: 0x16A0 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.80traceroute to 203.131.198.80 (203.131.198.80), 64 hops max, 40 byte packets1 210.83.214.161 0.722 ms 0.699 ms 0.612 ms2 210.83.193.49 0.595 ms 0.486 ms 0.615 ms3 210.52.131.6 16.979 ms 16.978 ms 16.975 ms4 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 ms6 210.53.126.2 50.083 ms 49.955 ms 50.334 ms7 202.147.16.125 50.583 ms 50.207 ms 50.587 ms8 202.147.16.205 51.204 ms 50.081 ms 50.209 ms9 202.147.16.214 103.055 ms 103.050 ms 103.179 ms10 202.147.0.206 99.803 ms 99.677 ms 99.806 ms11 203.192.131.250 103.802 ms 103.549 ms 103.430 ms12 203.174.64.13 99.804 ms 100.053 ms 100.681 ms13 203.174.64.146 100.056 ms 100.799 ms 102.075 ms14 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 msgw2# 这里可以很清楚的看到为15跳，充分证明了TTL没有任何问题，而对方的服务器也没有使用防火墙以及NAT来映射25号端口。=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+09/26-14:44:52.744633 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0x800 len:0x4210.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:33011 IpLen:20 DgmLen:52 DF***A**** Seq: 0x2E68FF25 Ack: 0x1527A9A2 Win: 0x8218 TcpLen: 32TCP 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:0x800 len:0x93203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:49 TOS:0x0 ID:37317 IpLen:20 DgmLen:133 DF***AP*** Seq: 0x1527A9A2 Ack: 0x2E68FF25 Win: 0x16A0 TcpLen: 32TCP 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.da74 61 2D 68 6F 74 65 6C 2E 6E 65 74 20 46 2D 53 ta-hotel.net F-S65 63 75 72 65 2F 76 69 72 75 73 67 77 5F 73 6D ecure/virusgw_sm74 70 2F 32 32 30 2F 35 61 2D 70 30 37 2D 62 33 tp/220/5a-p07-b32E 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:0x800 len:0x5410.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:33066 IpLen:20 DgmLen:70 DF***AP*** Seq: 0x2E68FF25 Ack: 0x1527A9F3 Win: 0x8218 TcpLen: 32TCP 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.cn0D 0A .. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+我们的服务器给对方发送了一个SMTP协议所需要的HELO信息。由于内容太多中间SMTP协议的握手我就不再详细介绍了，所以我这里直接跳到出问题的地方。=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+09/26-14:44:53.049710 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0x800 len:0x6B10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:33110 IpLen:20 DgmLen:93 DF***AP*** Seq: 0x2E68FF56 Ack: 0x1527AA19 Win: 0x8218 TcpLen: 32TCP Options (3) => NOP NOP TS: 121485755 9713787 52 43 50 54 20 54 4F 3A 3C 6A 69 6D 67 72 65 65 RCPT T<xxxxx6E 40 6E 65 70 74 75 6E 65 2E 6C 69 76 65 64 6F x_at_neptune.livedo6F 72 2E 63 6F 6D 3E 0D 0A or.com>.. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+在这里，当我们的服务器发送RCPT To的信息到对方服务器以后，按照SMTP协议的原理，对方在有这个用户的情况下应该返回250 ok这个信息，但是这个时候问题出现了，我们的服务器马上收到一个如下的信息：=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+09/26-14:44:53.103763 0:14:22:1F:4A:49 -> 0:11:43:58:71:FF type:0x800 len:0x41203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:57 TOS:0x0 ID:64 IpLen:20 DgmLen:51***AP*** Seq: 0x1527AA19 Ack: 0x2E68FF7F Win: 0x0 TcpLen: 2035 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:0x800 len:0x4A203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:49 TOS:0x0 ID:37321 IpLen:20 DgmLen:60 DF***AP*** Seq: 0x1527AA19 Ack: 0x2E68FF7F Win: 0x16A0 TcpLen: 32TCP 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:0x800 len:0x4810.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:33131 IpLen:20***AP**F Seq: 0x2E68FF7F Ack: 0x1527AA24 Win: 0x8218 TcpLen: 32TCP 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.80traceroute to 203.131.198.80 (203.131.198.80), 64 hops max, 40 byte packets1 210.83.214.161 0.722 ms 0.699 ms 0.612 ms2 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 ms4 210.52.130.10 46.711 ms 45.836 ms 45.838 ms5 210.52.132.230 50.208 ms 49.957 ms 50.085 ms6 210.53.126.2 50.083 ms 49.955 ms 50.334 ms7 202.147.16.125 50.583 ms 50.207 ms 50.587 ms <——可能发送错误信息的IP8 202.147.16.205 51.204 ms 50.081 ms 50.209 ms9 202.147.16.214 103.055 ms 103.050 ms 103.179 ms10 202.147.0.206 99.803 ms 99.677 ms 99.806 ms11 203.192.131.250 103.802 ms 103.549 ms 103.430 ms12 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 ms14 203.174.64.214 101.012 ms 99.676 ms 100.179 ms15 203.131.198.80 100.805 ms 99.926 ms 99.929 ms <——真是服务器的IPgw2# 使用 http://www.linkwan.com/gb/broadmeter/VisitorInfo/QureyIP.asp 的IP地址查询查到 202.147.16.125 属于澳大利亚，难道澳大利亚在监视我们的网络，想想虽然有这个可能性，但应该不会明显到这个程度。所以我想应该不是这个IP地址，然后我查了查第6跳的IP地址 210.53.126.2 ，通过查询显示为“中国网通”很明显6和7之间就是中国网通的出口路由，那么GFW就顺理成章安装在 210.53.126.2 这个IP之后。从上面的分析我们就可以完全的肯定阻断公司邮件正常来往的就是 210.53.126.2 之后的GFW发送的假信息。还好公司的邮件全都是正常的，GFW并不会完全封死，所以过段时间以后会自动恢复。由于发送的邮件非常多，也不一定是同一个服务器，所以不能用VPN来解决，不太现实。当碰到这样的问题的时候我们目前只怕唯一能做的就是等待，直到 GFW恢复我们的网络。

amy

。。。。。。。。。。。。复杂。。。。。

青蛙

是比较复杂

Alice

楼主，我的邮件被退回来了。我还不知道是什么原因呢。我用的是公司的邮箱 outlook的，发往国外的都被退回来了。国内的是可以发的。请问是为什么？

青蛙

这个我也不是清楚。

ipod

好技术类型的文章哈！我先收藏！下次遇到问题在看！