There’s been a lot of discussion in the last few months about the rapid increase in spam e-mailings, defined loosely by one website as “mass-delivered, unrequested advertising delivered via email or discussion groups.” Many have wondered what should be done, but few have proposed anything truly worthwhile.
One of the problems with the internet is that is got big really quickly. So quickly, in fact, that many poorly designed architectures were implemented and adopted. In truth, a better, fairer way to say it is that many of the recognized standards were designed without the knowledge of the degree to which they would used and depended upon. Protocols like telnet, ftp, nntp, and http are insecure plain text transfers and are routinely manipulated, cracked, and exploited. Only recently have extensions or replacements to these, ssh, ftps, nntps, and https, become commonplace. In fact, in some cases, they are really just extensions, not designed from the ground up with intentions of security or administration. Though these were all designed by brilliant and talented engineers, they didn’t have the knowledge we now have to plan properly for the ways people would abuse their project.
This is common all over the internet. I, surely, do not propose to be smarter or more inventive than the designers of the internet. In comparison, my skillset is supremely dwarfed. However, I think everyone can agree, all of what has been adopted on the internet was done so without the knowledge that it would catch on so quickly and so intensely. Even the central protocol that powers the internet, IP, needs to be upgraded to a new version to accommodate the growth rate and security needs unforeseen by those who put the ball in motion 30-odd years ago.
That said, one nasty habit of interneteers has been to “jiggle” the current internet to fix problems as they arise. Of course, it’s impractical to create a new internet that does things properly. In addition, replacements are hard because getting everyone to switch over is an arduous and tedious process. But some problems simply don’t have simple or practical solutions, and the most obvious problem is spam.
Spam affects nearly everyone with an e-mail account. It’s been estimated that around 3% of all internet traffic is SMTP, or Simple Mail Transfer Protocol, the TCP port on which e-mail is sent. Further, this website reports that “Brightmail, an anti-spam software maker, reported that spam will account for 40 percent of e-mail traffic in 2003.” 40 percent! That’s nearly half of all e-mail transmitted! They also estimate that each piece of spam, at the least, takes about 4.5 seconds of our time. For the average person, simply receiving 10 pieces of spam a day takes, at the very least, a minute of their time. Multiply this times the many billions of messages sent out each day. And some of us are fortunate enough to receive up to 100 spam mails a day.
Read about recommended solutions to the spam problem and you’ll get the same few answers:
This got my mind going. I’m not an internet engineer, so I’m not knowledgeable enough to propose a 1-2-3 solution. Instead, I have an idea and I’d like to generate some discussion and entertain the feasibility of a next-generation replacement to the way things are currently done.
I’m not sure the exact details of SMTP, and truthfully, I’m not even sure that what I propose should be implemented in a protocol, perhaps it’s just intelligent client software. Either way, I think it might mostly solve the spam problem.
I imagine this measure as a “Mail Transfer Handshake Protocol (MTHP).” First off, we take SMTP as is as a starting point. The way e-mail is transmitted is not a problem – it works, though the protocol is unencrypted. The next step is that we add some “authentication” to the mix. Every e-mail transmission is, by default, disallowed. E-mail servers will not accept e-mail from anyone who doesn’t have the right authentication. Each domain is then granted a key of some sort – perhaps it’s similar to a “trust certificate” or, better yet, a PGP (or GnuPG) key. Each mailbox is then granted a unique id on that domain (some sort of random ID number/letter combination). When an e-mail is sent to a mailbox, it queues at a MTHP server, which holds it for a specified “drop dead period.” While in queue, the mailbox owner has the ability to view certain information about it – the display name, the originating e-mail address, IP address, and any other information contained in the packet headers. Before the e-mail is viewed, the mailbox owner can then choose to send the originator their individual key that includes the domain key and the mailbox id. When this transaction is complete, an e-mail may now be sent. Further, from then on, there need be no further key exchange, so long as the key remains valid. From then on, it resembles simple SMTP traffic. Should a person not respond within the wholly configurable queue time, the MTHP server simply dumps the message.
At this point, the ISP could be building a list on their MTHP servers of messages designated as safe and those rejected. Perhaps the rejected ones, once they reach a certain number of blocks, can be sent to a central agency that maintains blacklists that an ISP might use to find their own offenders, or, if they choose, find addresses which they can blacklist from even their MTHP servers, so that spammers couldn’t even get into the queue. Maybe even a central propagating feedback system similar to eBay’s that can be distributed via a method like the root DNS servers.
I’d anticipate that after a few months, you would rarely need to visit your MTHP queue for approval. Most of the time, people you know would have your key. In fact, an MTHP server could be configured to send you a periodic digest of mail you have in your queue waiting to be seen so that you’d never need to think about “checking” something else. The system would deliver a heads up, not for each message, but every so often, to let you know what’s waiting.
There are a number of other details to be considered. First off, it must be possible to create “open mailboxes” that can receive e-mail without a key. Another possibility would be mailboxes that simply have a general public key. Since they would be few and far between, it would hardly be worth hunting for those few to spam them. Another important point would be how to transmit this “handshake.” Clearly, the handshake would have to be encrypted. Should the rest of all e-mail then be encrypted? This will definitely slow things down.
Also, we need to consider the security of the key. What if it falls in the wrong hands? Though it might be easy for me to re-key my own domain” with all three of its POP mailboxes, I sincerely doubt users of Hotmail or Yahoo! mail would be very excited about re-approving all of their safe list each time the key is compromised. What if I’m a spammer and I sign up for a Yahoo! mailbox just to send myself the key and then dissect it? We’re talking about some serious work that must be done to keep each individual key safe, otherwise any work done would be in vain. The best solution, as I see it, is to make each key contain a bit about the sender’s address that was granted express approval. Then, you at [email protected] couldn’t take my certificate and use it, or worse, sell it, to [email protected] and use my key.
Of course, right now, people are vulnerable in real life with social security numbers, ATM codes, and credit card numbers, so it’s unfair to assume that people would be unable to keep their keys safe.
Now, admittedly, implementing a new system like this is not a “weekend project.” We’re talking about changing the way the whole internet works well into this project. The question I’d ask is, how long will it be until we are FORCED to start over? At some point, we’ll be limited by the constraints of certain current methods and architecture and be forced to use replacements, much the way that we’ve had to increase storage capacity in our datacenters, multiply bandwidth at our places of work and homes, and regulate allowed transport methods of network traffic. At some point, IP will be replaced, much the same way that IPX has been made extinct, with another new shiny suite that better suits the internet as it stands at that time, which might be well in the future. Maybe IPv6 is the savior – maybe it will give developers the tools to overcome much of the abuse that takes place today. However, the primary benefits on IPv6 are less on the workstation and more on the network side of things, implementing multicast and IPsec as mandatory rather than optional, limiting routing table sizes, and network autoconfiguration, amongst many other things. We should be planning a “second internet” using lessons learned now. While the name internet 2 is already in use, the idea is one we should take seriously.
It’s been suggested that simple filters, like “spammer” and “nonspammer” acheive the same goal, but consider this: the Gartner Group guesses that spam click through rate is about 1% (many rate it less). We can probably safely assume that most people won’t grant spammers their key, so even if 1 out of every 100 people were to grant their key, that means that it would take a hundred times as many e-mails to generate the same response as today. We know spammers will only continue to spam as long as their is a response and it is economical. Personal lists still deliver the mail and count on you to file them, most don’t use any filtering system. MTHP generally would prevent it from ever reaching your mailbox.
As any project gets larger, there become participants that disproportionately further its cause and those who disproportionately detract from it. The detractors are the abusers, and in this case, spammers. It’s up to the technology savvy to be innovative and propose and share their ideas, even when they’re incomplete, if only to inspire the ones truly destined to change the world. Here’s my idea. Whatta ya think?
