As of July 2007, the government has been intermittently blocking emails to oversea\'s.

The emails returned typically have the following "issues":
Remote host said : 551 User not local; Please try
Giving up on xxx.xxx.xxx.xxx.Giving up on xxx.xxx.xxx.xxx.
Or :
Remote host said : 500 error
Giving up on xxx.xxx.xxx.xxx.Giving up on xxx.xxx.xxx.xxx.

If we check our mail logs, we find things like:

Sep 26 14:46:23 livedoor qmail: 1159253183.972578 delivery 118310: failure:Jan 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./Xxx.xxx.xxx.xxx_does_not_like_recipient. / Remote_host_said : _500_error/Giving_up_on_xxx.xxx.xxx.xxx.

If we packet sniff the connection to check where the errors are appearing, we see this:

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

09/26-14:44:53.049710 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0x800 len:0x6B09/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 DF10.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*** *** AP Seq : 0x2E68FF56 Ack : 0x1527AA19 Win : 0x8218 TcpLen : 32 TCP Options (3) => NOP NOP TS: 121485755 9713787TCP 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>..52 43 50 54 20 54 4F 3A and 3C 6A 69 6D 67 72 65 65 RCPT TO : 6E 6E 40 65 70 74 75 6E 65 2E 6C 69 76 65 64 6F x_at_nep tune.livedo 6F 72 63 6F 6D 2E 0D 0A or.com 3E "..

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

When our server issues an RCPT TO, to send a message to the remote server, the other side should return an OK. However, we our server receives a 500 error (from a different machine):

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

09/26-14:44:53.103763 0:14:22:1F:4A:49 -> 0:11:43:58:71:FF type:0x800 len:0x4109/26-14 : 44:53.103763 0:14:22:1 F : 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:51203.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*** *** AP Seq : 0x1527AA19 Ack : 0x2E68FF7F Win : 0x0 TcpLen : 20 35 30 30 20 65 72 72 6F 72 0D 0A 500 error..35 30 30 20 65 72 72 6F 72 0D 0A 500 error ..

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

If we look at the ttl values for the conversation, we see that the ttl\'s jump to a different value than the one we expect.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

09/26-14:44:53.154738 0:14:22:1F:4A:49 -> 0:11:43:58:71:FF type:0x800 len:0x4A09/26-14 : 44:53.154738 0:14:22:1 F : 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 DF203.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*** *** AP Seq : 0x1527AA19 Ack : 0x2E68FF7F Win : 0x16A0 TcpLen : 32 TCP Options (3) => NOP NOP TS: 9713798 121485755TCP Options (3) = "NOP NOP TS : 9713798 121485755

32 35 30 20 4F 6B 0D 0A 250 Ok..32 35 30 20 0D 0A 4F 6B Ok .. 250

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

We then see a correct reply from our remote server, but as we have already seen a fake reply telling us that there is an error, our server terminates the conversation.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

09/26-14:44:53.155026 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0x800 len:0x4809/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 DF10.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: 32F ** *** AP Seq : 0x2E68FF7F Ack : 0x1527AA24 Win : 0x8218 TcpLen : 32 TCP Options (3) => NOP NOP TS: 121485860 9713787TCP Options (3) = "NOP NOP TS : 121485860 9713787

51 55 49 54 0D 0A QUIT..51 55 49 54 0D 0A QUIT ..

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Now we know something is interfering with the connection, we can do a traceroute, and check to see whats causing the issue.
gw2# traceroute -n 203.131.198.80Gw2 # traceroute-n 203.131.198.80

traceroute to 203.131.198.80 (203.131.198.80), 64 hops max, 40 byte packetsTraceroute to 203.131.198.80 (203.131.198.8 0), 64 hops max, 40 byte packets

1、 210.83.214.161 0.722 ms 0.699 ms 0.612 ms1210 .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 ms2210 .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 ms3210 ms .52.131.6 16.979 16.975 16.978 ms ms

4、 210.52.130.10 46.711 ms 45.836 ms 45.838 ms4210 .52.130.10 ms 45.836 46.711 45.838 ms ms

5、 210.52.132.230 50.208 ms 49.957 ms 50.085 ms5210 .52.132.230 ms 49.957 50.208 50.085 ms ms

6、 210.53.126.2 50.083 ms 49.955 ms 50.334 ms6210 ms .53.126.2 50.083 50.334 49.955 ms ms

7、 202.147.16.125 50.583 50.587 50.207 ms ms <--- Probable Cause here (based on TTL value to server)

8、 202.147.16.205 51.204 ms 50.081 ms 50.209 ms8202 .147.16.205 ms 50.081 51.204 50.209 ms ms

9、 202.147.16.214 103.055 ms 103.050 ms 103.179 ms9202 .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 ms10202 .147.0.206 ms 99.677 99.803 99.806 ms ms

11、 203.192.131.250 103.802 ms 103.549 ms 103.430 ms11203 .192.131.250 103.802 ms 103.549 ms 103.4 30 ms

12、 203.174.64.13 99.804 ms 100.053 ms 100.681 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 ms13,203 .174.64.146 100.056 ms 100.799 ms 102.07 5 ms

14、 203.174.64.214 101.012 ms 99.676 ms 100.179 ms14,203 .174.64.214 99.676 101.012 ms 100.179 ms ms

15、 203.131.198.80 100.805 ms 99.926 ms 99.929 ms <â€"â€"Real Remote server

If we check to see where 202.147.16.125 is, we find its in Australia. So, this is probably not the cause. The jump before though is inside Chinese Net Space, and belongs to China Netcom.

So our international hop is on the ip address before that, and that would be where the firewall is located. So, we can infer that the firewall is running on IP 210.53.126.2

As we do not control international connectivity, all we can do is wait until the government lifts the blocks.