Much ado about Port 25

I just spent a couple of hours doing some support for a local business person who was having trouble with sending email from the road. It turned out he was suffering from WiFi driver problems (most likely caused by a prior virus and spyware infestation), and also the notorious "Port 25 blocking" problem. The former was easy to fix, the latter, well its pretty much endemic now and unlikely to go away.

To me port 25 blocking has always seemed like a brute force workaround for a much deeper problem. Its kind of like taking the wheels cars to prevent speeding, it solves the problem but it sure impacts mobility! Ironically the very people who instigated port 25 blocking - the big companies who offer DSL and Cable - are finding its hurting their own users who can no longer send email away from home without resorting to webmail. Naturally a lot of them would much rather you used their webmail because third party email clients like Thunderbird and Outlook just give them heaps more support issues to deal with. However until all web email packages are as good as Scalix I think I'll pass on that restriction. Plus you know there are times when I just have to have my email on my local computer because the network isn't always there, reliable and unfettered even though some people would just love for you to think that is the case.

Now I have noticed that Microsoft has managed to build into Outlook support for reading and sending email via HTTP, but only for its MSN Hotmail service. That appears to work well and nicely gets around the pesky port 25 problem. It even manages to keep the local and remote mail nicely synchronized without any third party or additional steps. It just works. However this solution is basically a proprietary one that doesn't address the problem that there is no universal alternative to SMTP that fixes all of its problems.

Indeed why didn't they do just that - fix the problems? Well the problem is that no one could really agree on what the fix is - between safe harbors of SPF (Sender Policy Framework) and DomainKeys there's an ocean full of mail servers that are ignorant of both. Indeed it will probably be years before a significant number of all mail servers are aware of these new standards, and properly configured to reject email from unsigned domains or inappropriate sources. If you doubt me just look how long it took for people to figure out that open relays (mail servers that will forward email from and too anyone) are really a bad idea.

I have my doubts that either DomainKeys or SPF (the former is superior) will have any significant effect on spam since spammers will still be able to set up valid domains on the fly with all the right credentials, spam from them and disappear into the night. And they will still be able to find compromized machines and extract (or guess) valid email credentials to send via a legitimate mail account. Remember that enough machines can be hijacked then a huge spam attack can be sent using even a modest amount of sends from each machine. An ISP might notice someone sending a thousand emails in a day - but its not out of the ordinary for a business customer or someone who mails to a list regularly. They might step in to investigate if someone was sending say 10,000 emails a day, but if you have thousands of machines compromised one would never have to exceed or even reach these levels.

In the mean time we'll have to live with the shot gun approach of port 25 blocking because spaming from open WiFi connections and hijacked "zombie" machines still gets the majority of its mail through to the recipient. When the day comes that the majority of email is rejected and the majority which gets through is filtered, then finally spamming may just die out. But my prediction is that at the end of my long dark tech-time of the soul we'll still be living with spam. It will effectively be the trash in the streets of the Internet that everyone sees, few bother to do much about and all complain about.

What is the real solution?

Well clearly the act of accepting email for sending and accepting it for delivery to the end recipient need to be well separated. The initial stage should always require an authenticated connection from a valid user of that server, delivery to the recipient should not. All agents that deliver email after the authenticated user session has ended need some kind of independently authenticated status, possibly with a bond or insurance purchased against abuse by spammers.

The former can be achieved by handing out email sending certificates obtained by application to a registrar - just like we do with registering a domain. Indeed the two might be combined for those that want both a domain and license to deliver email. One could argue this is exactly what DomainKeys does, maybe it is. The latter can be achieved by an add on service on purchases - varying levels and costs of insurance/bond could be granted and a mail recipient could rank incoming email by metric. For senders without any insurance/bond the recipient could then fallback on a distributed trust metric obtained via monitoring of spam traffic. Hopefully servers that have a record of not sending spam will eventually earn a good trust metric and be able to purchase a bond or insurance at a heavily discounted rate.

Of course there is no reason why good old unregulated and free (as in beer) port 25 SMTP mail can't continue but just like unmoderated Usenet it will become the domain of low signal to noise traffic with little commercial or actual value (except perhaps for terrorists communicating somewhere below the noise level). At that point I wont begrudge anyone blocking it with impunity.