邮件服务器-邮件系统-邮件技术论坛(BBS)

标题: 551 User not local; please try <forward-path> [打印本页]

作者: dennishan 时间: 2006-9-27 08:44
标题: 551 User not local; please try <forward-path>
目前很多SMTP服务器发送均出现551 User not local; please try <forward-path>
可能和大规模病毒爆发有关。

实际测试，感觉和IP地址无关，和邮件内容有关，而且，据我了解未必和对方设置有关。
有遇到过的，一起讨论一下吧。

这个可能是最新的海外邮件问题。

作者: jmhyy 时间: 2006-9-27 12:06
标题: 我的也是这样
LZ,我所在的公司现在也是这样,我们在香港用的是盈通的邮件系统,以前出差到外面用outlook收发没有问题.前几天就不行了.出的提示也是551 User not local; please try<forward-path>,以为是香港那边的问题,但是打电话问了以后,他们说没有问题,也没有做什么设置.
现在不知道如何解决.有没有什么办法.

作者: ivana 时间: 2006-9-27 22:20
我们发给hotmail,gmail都有过这种现象

作者: dennishan 时间: 2006-9-27 23:06
目前看起来日本多一些，下午有好转迹象，可能和前天大规模蠕虫病毒爆发有关。

作者: lizhso 时间: 2006-9-28 12:45
这种问题真让人难受呀,总感觉无从着手去解决

作者: 安德烈 时间: 2006-9-29 17:09
这个问题最近是大面积的,我看了别的网站一帖子,提到了国家公共网络监控系统.觉得很有可能,大家可以去看看,标题:找出GFW在Internet的位置，全面分析国内到国外邮件受阻的原因.搜一下就能找到了.看后别忘判断和在这评论下啊.-----兄弟初来乍到,还请多多关照.

作者: dennishan 时间: 2006-9-29 21:05

原帖由 安德烈 于 2006-9-29 17:09 发表
这个问题最近是大面积的,我看了别的网站一帖子,提到了国家公共网络监控系统.觉得很有可能,大家可以去看看,标题:找出GFW在Internet的位置，全面分析国内到国外邮件受阻的原因.搜一下就能找到了.看后别忘判断和在这 ...

和我推测的一样，还好我们有欧洲美国转发主机，否则我们的客户发送重要邮件被退，中秋节都不太平......

作者: 安德烈 时间: 2006-9-30 10:08
如果这成立的话，那会不会跟最近黑客事件多有关？（百度新网被黑，中日黑客大战）自然增加了监控力度？但愿是暂时现象，呵呵

作者: 钉子 时间: 2006-10-4 00:03
这个问题，我找了一些资料，反到没有想到和会网络最近的一些变动有关。

作者: 钉子 时间: 2006-10-10 23:59
找到了安德烈说的文章，转过来大家看看：

找出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: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: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恢复我们的网络.

－－－－－－－－－－－－－－－－－－－－－－－－－－－
这个问题的补允说明有下面这一个帖子了。大家可以看一下：

1.截图分析传说中gfw造成的551 User not local错误

http://www.5dmail.net/bbs/thread-168216-1-1.html

2.GFW敏感字不完全列表

http://www.5dmail.net/bbs/thread-168245-1-1.html

作者: atong999888 时间: 2006-10-12 15:24
国庆过后这种情况就比较少了, 可能是国庆前那几天监控严格一些.

作者: veail 时间: 2006-10-12 16:56
最近这几天国外的邮箱给我发邮件的时候也会收到1551 User not local; please try <forward-path>这样的错误，也是因为我们国家国家公共网络监控系统有关系吗？

作者: stnana 时间: 2006-10-15 10:47
最近几天也会出现这种问题，不知道怎么对应呀。。真惨

作者: FlyingDuan 时间: 2006-11-9 12:11
标题: 回复 #10 钉子的帖子
这些都是在邮件服务器的日志里面找到的吗?我使用的是md,在哪里能找到这些类似的日志呢?

作者: atong999888 时间: 2006-11-11 10:41
你查日志也没用, 那个551是国家安全监控发的, 半路上就把你给挡住了.

作者: zjbeck 时间: 2006-11-22 13:16

原帖由钉子于 2006-10-10 23:59 发表
找到了安德烈说的文章，转过来大家看看：

找出GFW在Internet的位置
作者:刘宏光
邮件:iceblood_at_163.com
网址:http://www.nettf.net
日期:2006-9-26

看到这篇文章的标题,可能有人要问GFW到底是什么 ...

经典，受益匪浅。感谢钉子提供如此详细的实例

作者: feitianxiang 时间: 2006-11-22 19:43
目前还没碰到这种情况
不知道在什么情况下会发生这种情况？

谢谢钉子～长知识

作者: Rootong 时间: 2006-11-25 18:50
这些不是系统定义的，可能是用户自己定义出来的smtp banner

作者: 钉子 时间: 2007-2-1 04:34
关于这个问题有新的进展了，我今天帮一个客户处理香港的邮件服务器，问题现像是，可以成功的发往国外，但是就是经常发不到163,sina等国内的邮箱，出现类似：
551 User not local; please try forward-path
550 sunnyyaoyun is now disabled with MTA service.
这样的错误，我认为GFW已经对境外连接也有防范了。

还有另一种情况是,服务器下有多个域。所有域下的info@。。。邮箱发邮件要不是不能发送出上面的错，要不就是延迟。而其它帐号相对就正常一些。

作者: swg1970 时间: 2007-3-10 15:19
这样的实例讲解非常通俗易懂，谢谢。

作者: vincentlee 时间: 2007-4-9 11:01
关键是现在还没有对策呀,我今天也出现了...

作者: atong999888 时间: 2007-4-10 22:42
把邮件内容存为一个word附件发.

作者: 钉子 时间: 2007-4-10 23:59
标题: 回复 #22 atong999888 的帖子
atong,你说的方式能有效的解决这个问题吗？

作者: atong999888 时间: 2007-4-11 10:38
去年我就这么做的, 一般能发出去的, 大家可以试一下, 记住主题也改一下.
那个GFW要是连附件也扫描, 估计会崩塌掉.

[ 本帖最后由 atong999888 于 2007-4-11 10:40 编辑 ]

作者: 钉子 时间: 2007-4-11 11:28
标题: 回复 #24 atong999888 的帖子
不错的消息，有机会试一下。

作者: stone_public 时间: 2007-6-2 09:47

經典...

作者: st_2000 时间: 2007-6-6 09:38
附件形式发，应该可以。

作者: flyerheart 时间: 2007-6-13 11:58
我今天也碰到了,用附件形式发的出去

作者: powercyk 时间: 2007-6-14 22:31
不至于现在发邮件都这么困难吧。
贴子不错，学习了。

作者: nicktang 时间: 2007-6-19 17:40
顶上来！
有多少地方最近也碰到这种类似情况的？

作者: nicktang 时间: 2007-6-19 17:44
顶上来！
有多少地方最近也碰到这种类似情况的？

作者: atong999888 时间: 2007-6-19 19:20
应该是无数人有同样的问题.

作者: qin_cai 时间: 2007-6-20 12:05
我顶一个我也遇到了

作者: nichol 时间: 2007-6-20 13:16
同遇，真是令无数英雄竟折腰啊！~~~

作者: nicktang 时间: 2007-6-20 16:36
大家通过以上的方法能够解决问题嘛？

作者: lqcbj 时间: 2007-6-21 15:53
标题: 香港邮件收发问题
公司的邮件服务器在北京公司的机房了，香港的同事能ping 服务器，却不能登录，偶尔会登录上但一会就断了，很不稳定啊。难道真的是GFW 给闹的！恨死它了。香港邮件收发问题一直没有解决，那边又催得紧，郁闷啊！

作者: lqcbj 时间: 2007-6-21 15:55
标题: 香港邮件收发问题
公司的邮件服务器在北京公司的机房了，香港的同事能ping 服务器，却不能登录，偶尔会登录上但一会就断了，很不稳定啊。难道真的是GFW 给闹的！恨死它了。香港邮件收发问题一直没有解决，那边又催得紧，郁闷啊！

作者: lqcbj 时间: 2007-6-21 16:04
标题: 国内用户收发正常
国内用户收发正常，北京，上海，广州登第都没有发现问题，大陆与海外的连接有问题吗？但是香港的同事能登录公司网站http://www.xxx.com.cn . 却不能登录邮件服务器https://mail.xxx.com.cn ，用加密的安全超文本协议就被封了吗？

作者: lqcbj 时间: 2007-6-21 16:22
有谁碰到这种问题现在已经解决的，赶紧上来通报一声啊！救急嘛！

作者: 钉子 时间: 2007-6-21 16:41
最近发国外邮件问题,怀疑是GFW问题的话,想了解GFW可以看这个网站,里面有一些技术介绍和过滤列表:http://www.great-firewall.com

作者: nicktang 时间: 2007-6-22 15:12
不仅是国外，sohu 21cn或多或少都会有问题。
群发很多都会有问题；发送单个收件人，一个人不能发送，换一个发件人发送，又正常。

作者: lqcbj 时间: 2007-6-22 18:06
标题: 代理上网真慢
用firefoxl 浏览器再使用Tor代理上网真慢，登录服务器打开都慢，没法进行操作，更不用说收发邮件，我的目的能让香港正常的收发邮件。奇怪的是，今天早上九点之前登录邮件服务器很顺利，过后就不行了。不知怎么回事？

作者: your615 时间: 2007-6-29 15:39

原帖由 nicktang 于 2007-6-19 17:44 发表
顶上来！
有多少地方最近也碰到这种类似情况的？

应该很多人碰上吧,俺也属幸运者.
我从6月20就发现,在香港用outlook收不了公司的邮件,每次身份验证完就意外断开了,而且改用WEB也是一样,一会就断开连接了,在公司(服务器在大陆)这边发国外部分客户邮件也就是能连上,等半天都传不了数据,最后退信日志写到connection timed out.

有什么办法可以解决的55555555555555555555555555555555

作者: atong999888 时间: 2007-7-2 12:10
7.1过了, 希望我们可爱的ZF的拦截能放松点.

作者: tdk 时间: 2007-7-3 13:27
可能有希望了....
看完
http://www.5dmail.net/bbs/thread-167411-1-1.html
也许测试

作者: 钉子 时间: 2007-7-3 21:18
刚接到通知。整个7月份网络内容严打月。

作者: VBWORK 时间: 2007-7-5 12:26
我身在香港，想收到國內同事的電郵。曾嘗試兩位同事發送相同的電郵，當中一位能收到，而另一位同事的郵件就被退回，不知為何，請各大大幫忙。謝謝

作者: 263 时间: 2007-7-6 09:40
受到同样的问题困扰！！！

作者: 263 时间: 2007-7-6 09:41
受到同样的问题困扰！！！

作者: atong999888 时间: 2007-7-6 16:12

原帖由钉子于 2007-7-3 21:18 发表
刚接到通知。整个7月份网络内容严打月。

能否把通知发给大家看一下.

作者: qin_cai 时间: 2007-7-10 17:08
顶起来
有解决的说一下

作者: windbamboo 时间: 2007-7-12 08:46
今天我也看到了这个
发往日本的，都被退信了

作者: pctoper 时间: 2007-7-12 09:10
发往德国相同域名的某些用户有问题，严重困扰中。。。。

作者: dustsailor 时间: 2007-7-12 15:41
我最近也遇到同样的问题，发给美国客户的有些邮件出现551的错误，而给同一个地址发其他的邮件内容，比如正文只打个test就可以发过去。看来是内容过滤！

作者: joyp 时间: 2007-7-16 10:43
今天发IBM的遇到 551 USER NOT LOCAL....

作者: ivana 时间: 2007-7-16 11:44
我们这也是啊，今天早上又接了N多电话，不是connection reset 就是user not local
都疯了～～

作者: kadey99 时间: 2007-7-16 16:00
鬱悶死了,要如何才可以解决!!!!!

作者: yejeff 时间: 2007-7-16 16:54
顶,求解决方法

作者: lizhso 时间: 2007-7-16 17:08
今天早上开始发到香港和美国的邮件出现上面大家说到的退信,有些地址也出现
#5.5.0 smtp;500 Non RFC-compliant responsereceived>今天前都是没问题的.同时在系统日志里产生10009 DCOM的错误,伴随这个错误的是某个地址发不出去.以前也发生过找不出问题的原因好久后自动好了.

作者: apollo 时间: 2007-7-17 11:44
从昨天开始,我的邮件服务器也是这样啦--很难发送成功,邮件服务器是在HK,看那位大侠能帮忙找到解决方案!在此先谢过了!

作者: apollo 时间: 2007-7-17 11:50
标题: 回复 #38 lqcbj 的帖子
建议你在邮件服务器上面更改一下SMTP POP3的端口,可以解决HK同事不能收发的情况,不过还在要对垃圾邮件做一些过滤,不然的话时间长了更改后的端口也无法通讯了,GFW太让人烦了

作者: gongliang1984 时间: 2007-7-17 13:37
我也是，昨天开始台湾邮件发不过去，什么551问题，主管还在问倒底怎么回事呢，真不知道怎么回复

作者: webmedia 时间: 2007-7-17 14:08
标题: 郁闷哟
这个邮件问题真郁闷哟

作者: lwt1028 时间: 2007-7-17 15:20
我们这收不到51job的邮件，他们的退信显示Error Message: 551 User not local; please try
，晕菜！

作者: nicktang 时间: 2007-7-17 17:23
楼上的是收不到网站的还是员工的邮件啊？

作者: 钉子 时间: 2007-7-18 02:16
这个问题的补允说明有下面这一个帖子了。大家可以看一下：

http://www.5dmail.net/bbs/thread-168216-1-1.html

截图分析传说中gfw造成的551 User not local错误

作者: 钉子 时间: 2007-7-23 02:03
下面的帖子提供了＂GFW敏感字不完全列表＂

http://www.5dmail.net/bbs/thread-168245-1-1.html

作者: 深山野人 时间: 2007-7-31 19:05
我快被烦死了，希望快点解决

欢迎光临邮件服务器-邮件系统-邮件技术论坛(BBS) (http://5dmail.net/bbs/)