I sometimes -although not often- work for my previous employer, a railway equipment manufacturer, to set up Linux servers.
They called me earlier this week to help them find a solution to a problem they had with getting their email off the company server, located in Hong Kong, from their office in Shanghai.
For months, every time more than a handful of connections were made, the server in Hong Kong would become unreachable, not just for email but for web access as well. The strange thing was that access to the rest of the Internet would be untouched.
Only that server would become impossible to access after a little while.
The office in Shanghai uses an ADSL connection provided by China Telecom. It’s a standard broadband service with a dynamic IP allocated every time they reconnect to the network. Nothing special there except that they block port 25 -used to send email-.
A lot of ISP do that in an effort to block spammers and worms infecting desktop PC: they require you to use their own SMTP servers to send email.
If it was only port 25, it would have been fine, but other ports to _collect_ email would trigger the blocking behaviour as well: getting your email through IMAP or simple POP3 on ports 143 and 110 would result in everyone in the office being unable to connect to fetch their email.
When this occurred, the ADSL modem had to be physically disconnected. Everything would be fine again for a short while after reconnecting and getting a new IP.
So that was the situation when I started to think about ways to circumvent all that.
First thing I did was to open some randomly chosen ports on the mail server and redirect all traffic from those ports to their corresponding local ports: you would now access email on port 523 instead or the normal 143 for IMAP, etc.
Well, this didn’t work for long. After just a few hours it seem that _they_ caught up with us again and we were back to square one.
Whatever was blocking the connection was more clever than just blindly blocking a few designated ports, it was also analysing the content of network packets to specially detect email activity.
The second solution was to again use 3 non-specific ports on the server for SMTP, IMAP and POP3, but this time use secure encryption (SSL) to ensure that the packets could not be analysed.
So far this seems to have worked. The only instance of blocking the office suffered so far was due to a laptop that was still using the original ports to send/receive email. Once its mail client was reconfigured, things went back to normal.
This spurred me add a couple of technical articles to my long and extensive [email server how-to][1] on
[1]: http://etc.nkadesign.com/EmailServer/EmailServer
[2]: http://etc.nkadesign.com/EmailServer/SecureAccess
[3]: http://etc.nkadesign.com/EmailServer/AlternateAccess
Comments
Hi. My wife is actually in Suzhou, and I am in charged of setting its Thunderbird… from France. So I would like to know what is the SMTP server used by China Telecom, but I was unable to find the answer on the Internet… Can you help me? Thanks! By the way, for my own, and dealing with your post, I connect to my server using an SSH connection and I am doing port forwarding in order to access all my servers (SMTP, SQL, …).
Right, I have also had this problem. The solution: exactly as stated above; use a different port. However, FYI all, port 587 seems to be more common. I run my own web servers so it was easy, but most providers will use an alternative. I hope this helps if the above port doesn’t.
Comments are closed.