昨天发现GFW正在监视着你的邮件，在用telnet直接连接到SMTP抓包实验的同时，采用了sohu webmail和gmail互发含有敏感词的subject和正文的email实验。
Sohu mail和gmail的通讯验证了神秘中间设备的存在
通过两个邮件互发这个实验并不能证实GFW的存在，因为sohu可能有自我审查系统，各个邮件系统可能有反垃圾邮件的体系，因此某些内容发送失败是可能的，但是做这个实验的目的是为了和telnet的抓包实验互相印证。
结论非常有趣，首先sohu和gmail之间出现了发送障碍，gmail和sohu mail都发出了无法投递和投递困难的通知：
这是在sohu的邮箱收到一个无法发送通知：
发件人：系统管理员<MAILER-DAEMON@sohu.com>保存到地址簿拒收收件人：xxxx@sohu.com, 时 间：2009年1月12日 4:53:51 以下信息来自位于 websmtp.sohu.com 上的邮件系统:
非常抱歉，您的邮件不能被发送到某些或全部收件人。附件为邮件原文和错误报告。
请和管理员联系，以获得更多的帮助。
请将错误报告作为附件一并发给管理员. 您可以删除自己的信件.
搜狐邮件系统
<xxxxxx@gmail.com>: host gmail-smtp-in.l.google.com[209.85.xxx.xxx] said: 551
User not local; please try <forward-path> (in reply to RCPT TO command)
除上述通知还受到多个无法投递的通知，为报告连接意外断开。
这是GMail的通知：
This is an automatically generated Delivery Status Notification
THIS IS A WARNING MESSAGE ONLY.
YOU DO NOT NEED TO RESEND YOUR MESSAGE.
Delivery to the following recipient has been delayed:
mave99a@sohu.com
Message will be retried for 2 more day(s)
Technical details of temporary failure:
Unspecified Error (SENT_MESSAGE): Connection reset by peer
----- Message header follows -----
Received: by 10.90.100.20 with SMTP id x20mr9216098agb.12.1231778863388;
Mon, 12 Jan 2009 08:47:43 -0800 (PST)
Received: by 10.90.53.17 with HTTP; Mon, 12 Jan 2009 08:47:43 -0800 (PST)
Message-ID: <b4ba3b590901120847p1d7d78d9l1dc2e45db6e9cd2d@mail.gmail.com>
Date: Mon, 12 Jan 2009 16:47:43 +0000
这里的情况和SMTP抓包验证是一致的。 从网络上的反馈来看，GFW的这个行为应该从最早06, 07被发现后就没有停止过，只不过它现在似乎更加倾向于直接发送RST报文来断开连接，而不敢干更多欺骗行为导致被普通用户发现的概率降低了。
GFW的行为不稳定，拦截效果很差，但破坏效果很强
一个非常有趣的现象是，虽然Gmail没有发送成功email,但是sohu这里却受到来自gmail的信！而且有趣的是不是一封而是几十封，由于sohu webmail上我不知道如何看mail header,只能从时间来判断，应该是由于gmail的MTA在不断retry,有部分通讯在收到GFW的RST之前，发送已经完成了，所以sohu已经收下email, 而gmail受到了RST认为发送失败又再次重发…如此一来本来GFW妄图把这邮件通信掐断的，但反而导致其重复发送了多次 （虽然更多次的retry可能被掐断了）。
在telnet抓包实验中也可以发现这个现象，也就是GFW不是每次都能表现出类似的行为，以及其掐断连接的时机似乎是不确定的。
email是一种存储转发的体系，emailserver会在一定时间内按照一定的策略不断投递邮件，因此如果GFW不能100%以及足够快地响应，不但不能达到阴险目的，反而有时可能适得其反（比如上面的例子）。 然而其成事不足，败事是有余的，带来的恶果包括：浪费邮件服务器资源、浪费互联网资源，造成邮件重复、丢失或发送失败。
GFW造成邮件发送的几种有害行为分析
1. 发送失败，发送方收到失败通知
当GFW能及时发送RST到双方的时候，表现为SMTP的协议通讯无法正常完成，这时候发送服务器多次尝试失败后会警告和告知发送者。
一般邮件内容较大，或发送方网络带宽较弱比较容易出现这个现象。
2. 发送成功但重复投递
一种可能性是，A-B的SMTP会话已经完成，但连接尚未断开的时候，双方受到GFW的伪RST报文。 这时候A认为连接异常断开而发送失败。 B可能认为SMTP会话已经完成，忽略RST报文，而成功地保存此邮件。
一般邮件较小，并且双方服务器网络和处理性能很强的时候可能出现这种情况。这种情况应该是国外往国内发比较容易发生。
如前所述，这可能导致大量重发并且用户受到重复的邮件。
3. 发送失败，发送方以为发送成功，但邮件丢失
这时最有害的一种，但在目前的GFW机制下有可能发生：A-B SMTP会话已经完成，一般这时候双方的连接会正常断开。A或略了伪RST报文因为其认为连接已经正常断开，但B在正常断开前收到了RST报文而认为连接异常而放弃了本来已经接受的email.
这种情况比较容易发生在双方网络和处理性能不一致，并且很大程度上取决于B的服务器实现方式。 我认为处理能力和通讯带宽不难么强的企业邮件服务器出现这种状况可能较大。 |
发表于 13-1-2009 21:14:30
收藏
赞
踩
楼主
