Working around stupid SMTP servers

Like most other people studying computer subjects at university, my student email account is a pretty vital resource that tends to get used quite regularly throughout the day. I also tend to do most of my work on my laptop since it saves having to set up everything twice. And it’s really worked quite well… except for my student email.

First a bit of background. As everyone knows, SPAM is a huge problem. In the original design of the email system, mail servers were designed to forward any message they received towards the correct destination. The problem with this is that it allowed a bunch of slightly-less-than-ethical folk to send the world offers of “completely genuine luxury watches”, “magic” herbal supplement and offers to receive a billion dollar inheritance from your long lost Nigerian cousin, “relaying” the message via your mail server. Thus pretty much any well configured server will now only accept mail that is intended for it’s own users or from trusted addresses (think of machines inside a university or company network). Trouble is, if you’re on the outside, you can only use the mail server for sending to users on that network.

The usual solution is to use your ISP’s mail server (since you’re inside their network, they’ll accept your mail) and everything works as planned. Unfortunately this approach doesn’t work as well for mobile clients since as soon as you use the device somewhere else (at Uni, work, friends place), your ISP’s mail server will no longer accept your mail. So what do we do now?

Well another nice feature of SMTP is that you can use an authenticated connection. By providing a username and password you can prove that your a legitimate user (and not selling various “male enhancement” drugs) and the mail server knows that it can accept your email. This worked great for me for about 4 years until a recent “upgrade” of the central mail server at Uni resulted in this feature being switched off. To add the problem, whilst on the University network, you can’t connect to ANY other mail server at all. Thus, at present the only solution is to change the SMTPsettings each time I go between Uni and Home (that would mean at least twice a day) or only ever send mail to University email accounts from home (though this causes the emails to be considered more likely to be spam since they still come from an “untrusted” machine).

After trying this for about 6 months (and it driving me up the wall) and having my help desk requests ignored by the central IT, I’ve decided to make my own workaround. There’s a really nice program called socat that pretty much lets you connect any sort of terminal or socket device to any other. In this case we wish to connect a TCP socket listening on ‘localhost’ to the University mail server tunneling via one of the department’s student SSH servers. Since the SSH server is inside the Uni’s network then the mail server will trust the connection and allow email to be sent from anywhere I can SSH from (which happens to be both at Uni and home!).

socat -T 30 TCP-LISTEN:2525,bind=localhost,fork EXEC:"ssh ~/bin/nc 25"

This will probably require a small bit of explaining. First thing this command does is start socat, sets a 30 second inactivity timeout (-T 30) and tells it to listen with a TCP socket on port 2525 (TCP-LISTEN:2525). Since I don’t want to be giving everyone connection to the mail server we bind the socket so that it only listens on the localhost address – typically (bind=localhost). Finally we tell socat to fork for each connection received so that we can handle multiple connections (fork) – not absolutely required, but does prevent problems if two programs try and connect at the same time. The second part of the command (EXEC:"...") is responsible for connecting to the SSH server and telling it to connect the terminal to the department mailhost. First we start the SSH client (which is set up with a public key and a SSH agent so that it won’t ask for a password), then we tell it to run the ubiquitous netcat (though it’s not installed on the SSH servers so I had to compile it myself – hence the ~/bin/ part) and have that connect to the department mail server ( on port 25.

I’m curious to see how well this works out. Using socat saved me a few hours writing and debugging a Python script that I had been intending to use to do much the same thing.