Have you checked to see if you have a firewall sitting in front of this host preventing incoming port 25? The rules you have listed should definitely let you in. In fact, you have port 25 allowed twice.
On a side note, you should keep your rules consistent with Red Hat/CentOS's conventions. These rules:
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 23 -j ACCEPT
Should look like this, placed after the ESTABLISHED,RELATED line like so:
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 23 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
Also, make sure you run /etc/init.d/iptables restart after making changes to this file. To confirm if they've been applied, run:
# iptables -L -n | grep 25
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:25
Good Luck.
ctrl+] is an escape sequence that puts telnet into command mode, it doesn't terminate the session. If you type close after hitting ctrl+], that will "close" the telnet session.
Best Answer
Given only the informational message from telnet, most likely, the application that accepted your tcp connection either closed the connection on it's own accord or the application crashed/died.
The reason is that all "Connection closed by foreign host." by itself indicates is that the telnet application is of the opinion that the connection was shut down cleanly and the remote end initiated the shutdown. (And the OS/IP-stack (at least on my linux) will do a tcp-teardown if the application suddenly disappears, kill -9). To find out exactly why, your best bet would be if the application that listens to the port you telneted to logs somewhere and looking there for clues.
If this were to be network related you'd be far more likely to see something along the lines of timeout (or nothing happening at all) or connection reset by peer. If this somehow were caused by something along the network, that something would have to sort-of hijack your tcp-session to do the teardown handshake.