A couple of weeks ago, I wrote in this column that the problems of spam cannot be resolved without addressing the underlying security issues of SMTP and POP3 protocols. A number of readers agreed, but they wondered what could possibly be done to fix those security holes.

Meanwhile, the furor over email spam--unsolicited commercial email--continues to inflame the public, culminating this month with a meeting of the Federal Trade Commission (FTC) in Washington specifically devoted to the problem. At that meeting, ePrivacy Group, a privately held company based in Philadelphia, presented a white paper on a new standard called Trusted Email Open Standard (TEOS) that is receiving a lot of positive attention by lawmakers and technologists.

The white paper, entitled "Trusted Email Open Standard: A Comprehensive Policy and Technology Proposal for Email Reform" examines the social, economic, and technological conditions that are fueling the current proliferation of email spam on the Internet and offers a technical standard--along with best practices in implementation--to Simple Mail Transport Protocol (SMTP) to eliminate the problem.

What Is TEOS?

But what exactly is TEOS, and how does it change the way email might be sent? Will it remedy the problem of email spam? How might it be implemented--and by whom--over the next couple of years? Finally, what impact will TEOS have over your email infrastructure, and what might the costs be to implement the standard after it has reached maturity?

TEOS is a proposed standard that describes best practices for the implementation of SMTP, an automated mechanism for enforcing those standards, and an oversight board to maintain and distribute rules governing email transmissions. Its primary focus is to provide security in the transmission and the receipt of email communications.

ePrivacy Group divides the requirements for TEOS into three increasing levels of security:

• Sender Identity Level 1 provides a standard minimum accountability to vouchsafe the identity of the sender.
• Sender Identity Level 2 identifies the sender, identifies the message type, asserts a relationship with the recipient, and provides a standardized opt-out methodology.
• Sender Identity Level 3 identifies the sender and the message type, identifies the relationship with the recipient, provides trusted means of opting out, delivers a security certificate, envisions an oversight authority, and provides a dispute resolution mechanism.

Each level envisioned in the open standard is scaled to the requirements of email security to address the issue of spam, while also providing optional features (called "optional assertions") designed for custom and future potential requirements.

Noteworthy Features

There are three noteworthy features of this proposed standard. The first is that it addresses the issue of spam from a functional perspective and has scaled its response to the needs of all the users of email. For instance, at the base tier or Level 1, the proposal provides a means of ensuring that the sender's identity from a particular domain is, in fact, not bogus.

It also provides various "optional assertions" to allow the recipient to classify email received. For example, advertisements would be so marked, communications from a government agency would be verifiable through the certificate, and business-to-business communications could be identified.

How does it accomplish this?

TEOS sees identity verification, through the use of identification certificates, as an absolute base-level requirement and then proposes to build upon that security. Levels 2 and 3 provide reinforced security layers--with other optional assertions--to create an infrastructure of communications to meet a whole spectrum of requirements for private, business, and government security communications.

This approach transcends the current public uproar about "garbage communication" and positions TEOS as a real, comprehensive solution to a whole array of security issues that have yet to be addressed in email. It is not a "one size fits all" or "quick fix" solution; instead, it tries to be a measured, engineered security implementation designed to resolve current and potential abuses of email security.

An Additive Approach

The second noteworthy feature of this standard is its applicability to the current implementations of SMTP. The TEOS proposal understands the basic dilemma of today's Internet email infrastructure: How can email be cured of spam without killing the "killer app" of the Internet?

In fact, it is the simplicity of SMTP that has earned email the moniker of the killer app. Creating an email communication is simple: External files can be attached and transmitted, workflow systems can be built around the messages (e.g., Lotus Notes/Domino databases), and nearly every operating system in the world can make use of it. As a result, SMTP has become a sacred cow, and no one dares to impugn or exchange this workhorse of data transmission protocols.

However, the security of the current SMTP standard is spectacularly porous. It is a protocol designed to allow data to be exchanged between senders, servers, and recipients. As such, it is the barest envelope describing a transmission of data between two or more machines. This makes SMPT extremely versatile but also exceptionally susceptible to abuse by spammers.

So how does TEOS replace SMTP? It doesn't!

TEOS addresses SMTP by enhancing it with its own external mechanisms, engines, and standards. It also makes use of existing mechanisms--such as filters, IP blacklists (filter exclude lists), and address white lists (filter bypass lists)--that are currently being deployed in the fight against spam. The TEOS proposal will certainly add complexity to the SMTP network of servers and senders, but it's designed to work with the current SMTP, providing a structure of security that is, generally, self-maintaining.

Imbedding Security into the SMTP Network

TEOS envisions an external sender-side identity verification engine or "trusted email sending engine" (TESE) program that would package the sender's identity, bind that identity with the domain from whence the message was derived, and encrypt a certificate before the message is transmitted. This TESE program would sit on the sender's machine as an add-in module to the current email application that the sender uses.

The identification certificate that was created would be transmitted with the message itself through the Internet to a gateway (potentially a router) where a counterpart engine, called a "trusted email receiver engine" (TERE) would verify the certificate, including any optional "assertions."

Existing receiver-side server filter mechanisms, including blacklists and white lists, would further parse the messages that were passing through the gateway. All this would occur before any message was actually placed into the receiver's mailbox.

Once in the in-box, the recipient's own filter mechanisms could come into play, further classifying and triaging the messages received. If required, feedback mechanisms could be implemented to better inform the gateway's TERE engine of the receiver's email filtering system.

Building a Real SMTP Community

The concept of identity certificates is not new, of course: They've been used successfully in a variety of non-SMTP mail environments for years, such as Lotus Notes or Microsoft Mail. The implementation of engines such as the TESE and TERE are, in essence, an implementation of principles onto the SMTP structure.

However, the TEOS proposal goes further still.

One of the primary problems with SMTP spam today is that the authority to eradicate it is dispersed: SMTP was a grassroots protocol that was developed by consensus by hundreds of thousands of SMTP administrators on local servers. This protocol then spread to ISPs without any solid mechanism for monitoring and control.

Spam itself was first seen as a localized problem that individual ISPs and SMTP administrators attempted to tackle. As a result, ISP blacklists, which often contained erroneous information, were sporadically implemented by individuals, creating virtual blackouts of domains and often pulling down innocent senders in the process.

TEOS addresses this problem of community head on.

At the higher security levels (Levels 2 and 3) TEOS envisions automatic mechanisms by which users can securely opt-in to lists and transparently communicate through the structure to resolve spam-related issues.

For instance, TEOS proposes an automatic arbitration mechanism by which falsified identities or abusing spammers can be pinpointed and their identity certificates invalidated--potentially at the router intersection where the message enters the SMTP network itself.

This arbitration mechanism would then automatically promulgate the offender's identity throughout the SMTP network to all the TERE modules, shutting the offender out before the messages can penetrate the network through other entry points.

Conversely, individuals whose identification certificates were erroneously added to a TERE blacklist (as sometimes happens now with ISP router blacklists) would have a central entity to resolve disputes, enabling them to clear their offense so that they might be allowed back onto SMTP TEOS networks.

This same central authentication entity or "oversight board" would add new message "assertion" classifications for each level of security as they became standard on the SMTP TEOS network. With this kind of mechanism, created and maintained through the community of ISPs on the oversight board, the monitoring and control of the overall system could finally become automated, standardized, extensible, and highly functional.

Can TEOS Work?

As a beginning, ePrivacy Group's TEOS proposal holds some real promise: It addresses the issue of spam with a realistic solution that recognizes the limitations and the power of the SMTP email legacy, while simultaneously addressing the need for an Internet community-based centralized solution. It is not the first serious proposal for a solution to spam, but it may be the most realistic that is currently available to us.

Its "additive" approach to technology, instead of a "scrap and rebuild" approach that many other organizations have previously proposed, will resonate well with network administrators who have already made substantial investments toward eliminating spam.

It is not itself a technology, but a blueprint for an open standard that could act as a framework for future solutions.

It's nonproprietary, so different organizations with differing email infrastructures on differing platforms can implement at will. At the same time, it is comprehensive, realistic, measured, and extensible. It holds the promise of preserving the powerful capabilities of SMTP without placing an undue burden upon administrators and users.

Limitations of Scope

However, if TEOS is adopted by ISPs to address spam, it will be ultimately unfortunate. Why? Because TEOS is a real-life kludge, patching yet another piece of fabric over the holes in the ancient technology of SMTP.

SMTP was a protocol built of expediency: It needed to be small, simple, and versatile in order for Internet email to be generally adopted by such a wide audience. But it's already an old technology, and its limitations stretch far beyond the abuse of spam and current public uproar over unsolicited email.

Besides its lack of security, SMTP's message data structure is bulky, readily intercepted by hackers, and highly susceptible to carrying viruses in the form of email attachments.

It's unfortunate that spam has drawn so much attention to the problems of the protocol, because it has created such a strong public and political demand to simply "fix it."

Yet, at the same time we are addressing spam, we could also be addressing technologies of data compression, XML-like syntaxes, beefed-up content security, and real workflow functionality that could greatly automate so many more functions of electronic correspondence. Such an investment would further the functionality of email, for the good of the entire Internet community.

Nonetheless, ePrivacy Group is owed a debt of thanks for starting the ball rolling with TEOS. Their insight and their expertise in this field make "Trusted Email Open Standard: A Comprehensive Policy and Technology Proposal for Email Reform" a "must read" for anyone who is seriously concerned with the problems of spam on the Internet.

TEOS may yet take the sting of spam out of the sound of "You've Got Mail" and preserve the killer app that we all have come to rely so heavily upon.

Thomas M. Stockwell is the Editor in Chief of MC Press, LLC. He has written extensively about program development, project management, IT management, and IT consulting and has been a frequent contributor to many midrange periodicals. He has authored numerous white papers for iSeries solutions providers. His most recent consulting assignments have been as a Senior Industry Analyst working with IBM on the iSeries, on the mid-market, and specifically on WebSphere brand positioning. He welcomes your comments about this or other articles and can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

Thomas M. Stockwell is an independent IT analyst and writer. He is the former Editor in Chief of MC Press Online and Midrange Computing magazine and has over 20 years of experience as a programmer, systems engineer, IT director, industry analyst, author, speaker, consultant, and editor.  

 

Tom works from his home in the Napa Valley in California. He can be reached at ITincendiary.com.

 

 

Also Read

IBM i Shops Pivot to Battle COVID-19

Energy, Vibe, and Atmosphere

Murphy’s Security Law