E-mail and its security discontents

Why Microsoft, Cisco, IBM and others need to step up to protect SMTP

The late Internet pioneer Jon Postel (1943-1998), among others, developed the Simple Mail Transfer Protocol (SMTP) in 1982 that is still used today for Internet mail communications. But I'm sure Postel would be turning over in his grave if he could see the abuse that his protocol is subject to today.

Software writers in earlier days have sometimes made comments that they expected the code they wrote to be replaced long ago because they were writing for systems severely limited by both processor and memory. Postel, could he speak to us via a seance, might say the same.

We have inherited problems that stem from the fact that originally the only people using SMTP e-mail were the academic and scientific communities that had a strong level of trust with each other.

Today we are faced with billions of users across undefined communities and a completely different level of trust that exposes this incredible communication channel to abuse. And while concepts such as asymmetric key cryptography and encryption existed, the processing power required was not feasible for e-mail engines, even though it may have been necessary.

The root-cause of the problem that exists today is two-fold: no authentication (of either user or the message) or encryption. You are free to be whoever you want to be, and of course everything sent is in clear text, just like sending a postcard using the regular mail; everyone who handles it can read it, and if they want -- change it.

Yet billions of people use e-mail for personal and business use and do so without understanding the flaws in the system and damage that can be done as we include credit-card information, username and passwords, and personal details in e-mails that are sent over the Internet.

In business, we naively assume that because it is a corporate e-mail system all e-mails are subject to the same rigor and controls even when sent to an external e-mail address rather than sending to an internal recipient. In reality, for the majority of organizations, any controls or security that were in place for an internal e-mail system are simply discarded at the perimeter and the e-mail is sent as clear text, open for all to read.

There are standards to fix this. But as computer-science professor Andrew Tanenbaum said: "I like standards; there are so many to choose from."

These include SMTP over Transport Layer Security (SMTP/TLS), Sender Policy Framework (SPF), Secure MIME SMIME & PGP-MIME, (S/MIME ), Domain Keys (DKIM) [Cisco & Yahoo] and SenderID Framework) [Microsoft] (SIDF ).

Then there are other standards such as Pretty Good Privacy (PGP), GnuPGP, and a large selection of other secure e-mail solutions.

Jericho Forum Principle No. 5 states that "Devices and applications must communicate using open, secure protocols" and No. 8 states "Authentication, authorization and accountability must interoperate / exchange outside of your locus /area of control". For e-mail this means a way to validate the sender, or at least the sending domain, and ensure that the contents are secure in transit when outside of your e-mail system, and especially over the Internet.

Unfortunately, the use of SMTP/TLS or S/MIME (the two most commonly agreed upon IETF standards) account for only a small percentage of the total Internet e-mail traffic. Not surprising, given the lack of common agreed-upon standards and absence of any leadership on what people should be implementing.

The resulting lack of guidance from our industry means the end effect is that Joe Public is left by and large to live with a non-secure e-mail standard, and the spammers and phishers (organized crime) are free to spoof, spam and phish the online world.

Pragmatically, the SMTP standard is here to stay with no viable alternative. So there needs to be clear consensus on what we need to add to protect this totally insecure protocol that is built in and enabled as standard on all e-mail systems, and that we all use by default.

Join the newsletter!

Error: Please check your email address.

More about BillCiscoGoogleHewlett-Packard AustraliaHISHPIBM AustraliaIETFMessageLabsMicrosoftOpen GroupOraclePGPPioneerPostiniVIAWikipediaYahoo

Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by Paul Simmonds

Latest Videos

More videos

Blog Posts