after tcp handshake done, no packets can be receieved on each other side,why??

I'm going to guess that your email server has iptables running. Try disabling iptables temporarily and see if the packets make it through after that.

iptables is notorious for causing bizarre TCP behavior if it's not configured properly.

Dear gr8gonzo,
Thanks for your quick response.
The iptables is off. I have double checked it.
What is more, the client and server can talk to each other in the packet i caught.
The strange thing is after tcp seems setup, no packets can be received on each side any more, that is the problem.
Thanks!
[root@ip-10-136-13-206 ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination        

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        
[root@ip-10-136-13-206 ~]# chkconfig  |grep iptables
iptables        0:off   1:off   2:off   3:off   4:off   5:off   6:off
[root@ip-10-136-13-206 ~]#

Have you disabled the client-side firewall?

Any hardware firewalls/routers that have security features?

Also, are you on a home internet connection, like Verizon FIOS or Cox Cable? Sometimes home internet providers will block SMTP sending unless it goes through their own SMTP server.

Dear gr8gonzo,
The client side should work well. Becuase when i use another email account on another server. It works well.

Please know about that.
Thanks~!

What is more, when I change another networking environment , it is the same.
I think, the problem should be on the server side which i currently do not know.

Best Regards,
Robert

Changing the network environment won't always fix the problem, if the new environment also has the same problem. Unless you're in an environment that you know 100% for sure does not restrict outbound SMTP...

Also, some mail accounts on other servers can work fine - it depends on the server. For example, from my home PC, I cannot connect to my own server on port 25 (because of my ISP's restriction), but I can connect to GMail's SMTP server on port 465 (secure SMTP).

Don't assume things ARE working well just because they SHOULD be working well. When things SHOULD be working well, they usually are, but sometimes the most mysterious problems are in the unexpected exceptions.

Yes. In fact, the server is an EC2 instance. When I change to other ec2 instance in the same subnet environment. The server also works well. So it should not be issues on client side, or ISP block the smtp issue. It should be server configuration issue.
The work server is centos, while the not work server is red hat enterprise linux.

Please know that.
Thanks!
Robert

Was the capture on the server side done directly on the server?

The server is acting as if it never received the final ACK in the 3-way handshake.

If you look the the server side capture the server:

received a SYN request
sent SYN, ACK reqeust
received ACK
resent SYN,ACK over and over.

So somehow it appears something may be blocking the final ACK in the handshake.

Dear giltjr,
Thanks for your investigation.
Yes, that is what i am willing to figure out.
It seems server side does not receive the ack from server side packets.
From the client side, the client also does not receive the final handshake ack from server side.
It is very strange.