[Read an edited version of this on the BBC News online, as ever]
About two weeks ago I started getting a lot of bounced emails. Most of them were notifications from the ‘postmaster’ somewhere that my email could not be delivered because the recipient didn’t exist, but quite a lot were from spam filters to tell me that I’d sent messages that they weren’t willing to accept.

It seems I’ve been pushing stocks in dodgy companies, offering pharmaceuticals without prescription and even sending virus-laden images to unwitting users.

Except it wasn’t me.  Honest.

Most of the messages that came into my mailbox, at the rate of one or two hundred an hour, were originally sent by people with names like hmvmshmcb@andfinally.com, and although that’s my domain, it certainly isn’t one of the few email addresses I send from.

And closer examination of the headers reveals that they didn’t come from the andfinally.com domain or any of the servers run by my network provider.

But of course, I had nothing to do with these messages, or the thousands that presumably get through to unwitting recipients instead of being bounced.

A spammer, or group of spammers, has picked on my domain to use as the fake ‘from’ and ‘return-to’ field in the headers of the emails they send out, hoping to fool a few more filters into letting them through.

Because of the way email works, and the lack of any built-in authentication, this is a trivially easy thing to do.  As a result I have to cope with thousands of these messages coming in, and I face the danger that my domain, on which I depend, will be blacklisted and my real emails will stop getting through.

It’s a complete mess, and it’s getting on my nerves.

There are a few things I can do, and I’m going to have to waste my time persuading my network provider to set up one or more of the cobbled-together authentication systems like Sender-ID or Sender Policy Framework. At least then recipients can choose to check whether I really did send an email about Goldmark Industries to non-existent users in Poland!

It won’t fix the real problem, of course. It won’t stop people around the world forging emails that seem to come from me or injecting them into the network. And it won’t stop the damage to my reputation that results.

Earlier this week I gave a talk to a customer conference organised by Lyris, whose business relies on getting email delivered to people. They make ListManager software, and had asked me along to talk about the fuuture of email – and whether
it even has one.

Despite the many problems, and even despite my own current experiences and unhappiness, email isn’t going to go away. It fills an important space in the ‘information ecosystem’, since messages are persistent and asynchronous, unlike instant messaging, and the recipient is notified of their arrival in a simple and usually convenient way.

Of course we need to sort out the big issues which make spam and forged headers possible. We need to think about how trusted computers and modern network standards like version six of the Internet Protocol, IP, can be used to authenticate messages and their senders.  And we may want to review the operation of  core email protocols, like the Simple Message Transport Protocol, STMP instead of relying on add-ons like Sender-ID to do the work.

For example, at the moment messages are sent along with their headers, so when I send a note to my friend Simon about the latest cool tech gadget – or, more often, when he points something out to me – a copy is made and transmitted over the network.

That copy sits on his server until he either downloads it using the Post Office Protocol, or reads it remotely using IMAP, the Internet Message Access Protocol. In either case he looks at his local copy and not the one sitting on my server.

But in an always-on world surely there’s no real need to send those bits over the network until they are actually needed?

Millions of people work happily with Gmail and Hotmail accounts, only able to access their messages when they have a connnection, so why not extend the model, at least for those of us who can get online pretty much at will?

Instead of SMTP we could have SMIP – the simple message indication protocol.

Instead of chucking bits across the network we could send only the headers, leaving the message itself to be retrieved by the recipient when they choose to.

And then we could do some proper checking before messages were accepted.

Because apart from solving the problem of how to know whether someone has received or read an email, this would also make it generating spam with fake headers a lot less useful for spammers.

When an email client received a message that appeared to come from me at andfinally.com, the first thing it would do would be to ask my mail server if there really was a message waiting to be collected.

It’s a lot harder to hijack a domain’s DNS entry than it is to forge a header, so most of the spam would never be accepted.  And there would be no bounced messages since even the dumbest corporate email server would realise that a forged header which didn’t relate to a message sitting on the real andfinally.com server didn’t come from me.

Checking the originating domain is basically how SPF and Sender-ID work anyway but they are not yet in widespread use and take some effort to set up – as I am currently discovering.

They rely on having a network provider who is willing to respond to technical support queries and make changes to the mail server configuration, and so far my provider hasn’t bothered to get back to me.

I know I could run my own mail server on my own box, but while the technical aspects don’t worry me I already have too little time for real work, and taking direct control of even more aspects of my online existence is not really an option.

It would be much better to have an email architecture that actually made forged headers an exceptional technical achievement instead of something that any two-bit spammer can do in seconds.

Bill’s Links
It isn’t just me;
http://www.speed.net/support/forgery/
Sender Policy Framework/Sender ID: http://www.maawg.org/about/whitepapers/spf_sendID/
Sender Policy framework
http://en.wikipedia.org/wiki/Sender_Policy_Framework
Not the perfect solution, though:
http://www.theregister.co.uk/2004/09/03/email_authentication_spam/

Also relevant:

  • No Related Post