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 on : SecureAccess, AlternateAccess.