Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

January 1, 2003

Closing the Door

What price are organizations paying for receiving unwanted mail?

by Michael J. Hudson

Continued from Page 1

So, unfortunately, the onus of dealing with spam is on the receiver. The receiver must find a way to decide which email is legitimate and which email isn't. Corporate environments that rely on email to do business can't realistically do away with email altogether. The next choice is to buy spam-filtering software, which uses either some set of analysis heuristics to find the unwanted email or publicly available blacklists of IP addresses that are spam havens. However, both techniques are highly flawed, don't stop all the spam, and are known to block some legitimate pieces of email as well. And spammers still find new ways to evade these filters. For many, getting rid of spam — and finally reducing the substantial cost it creates — is impossible.

The main problem is that the price of sending spam is relatively small. This cost needs to be a lot higher. I'm not advocating new laws that force people to pay money for every email they send. Not only is this approach impractical to enforce on a worldwide basis, but it also would greatly reduce the effectiveness of email itself. The cost of sending email shouldn't be monetarily based; it should be effort-based. The most extreme method is to have each email user create an open list of email addresses for every person or mailing list that the user wants email from. Email from someone not on that list would be discarded.

A Simple Plan

This idea may sound overly restrictive, but it would decrease unwanted email if not completely rid you of it. This approach isn't really new, and many organizations and individuals already use it to some degree.

But for this solution to gain widespread acceptance, it requires a request authorization specification that easily describes how to manage the permissions list. This specification could be similar to how you subscribe to a mailing list — you send an email with some kind of keyword like "subscribe" in the subject line to the mailing list's majordomo server. From there, another series of keywords are used to continue to communicate with the mailing list to edit or cancel the subscription.

However, in this case, instead of requesting access to a mailing list, you're requesting the ability to send email to a user's account. This approach creates a purely opt-in email environment and substantially increases the time, effort, and cost to get an email into someone's email inbox. All request emails would either be filtered into a separate folder, or the email client itself would graphically manage the requests. All nonrequest emails that aren't on the user's open list would either be completely ignored or another email would be sent to them on how to request access. Either way, all unwanted email would be deleted or put into a separate spam folder.

At any time, users could check on the incoming requests and either accept or reject the request for access. If they accepted the request, their permissions lists would be updated. This system would still allow email advertisements from companies that you have on your permissions lists, but it would also let you cancel access if a certain email address was abusing its privilege.

The idea is in its infancy, but a few email clients such as TDMA and ChoiceMail already implement similar schemes. However, this approach needs a standardized specification that describes the details of how to format and authorize access requests. For instance, if you buy something from Amazon.com, you usually get an emailed receipt. Unless Amazon explicitly tells you what email address the receipt will come from and you add it to your permissions list, this receipt will either be discarded or put into a massive spam folder. The same problem exists for receiving returned email because of an invalid email address. Standardizing this mechanism as part of an email client or the email protocol itself would solve these problems.

Initially, this method sounds like a lot of work. However, getting a standardized solution up and running shouldn't take much effort because it only requires email and existing mailing list software. The real challenge is describing how to format and authorize the request email. The sender must also only send email from a specific email address that the receiver expects, but that sacrifice is worthwhile if users can regain control of their own email inboxes and the cost of dealing with enterprise mail servers decreases.

Rate This Article

Comments:

Optional e-mail address:

Another benefit is how easily you can associate public keys with each person in your list. This feature is exactly what's needed to effectively push encrypted email across the enterprise. One of the largest problems in developing a public key encryption infrastructure is the need to easily obtain and have public keys for everyone in your address book. Instead of just letting anyone request access to your account, you can go one step further and require that only those who can also provide their public keys can have access. All your email is consistently encrypted between you and your colleagues, customers, and partners.

Regardless of its additional uses, a request authorization system is the perfect balance between controlling unwanted email and allowing a level of access to a user's mailbox. It adds only a slight amount of work for the receiver, who needs to periodically check a request list. However, senders must go through a number of steps before they reach their audience, which makes them more responsible for the email they send. In the end, such a system would greatly reduce costs on both a personal and enterprise level, not to mention eliminating the need to constantly update spam-filtering software with new heuristics or blacklists. More important, a request authorization system eliminates the daily aggravation and annoyance of wading through tons of spam just to get to the email you want.

Michael J. Hudson [mjhudson@praxiseng.com] is a software architect for Praxis Engineering Technologies, a software architecture firm based in Annapolis Junction, Md. His current work includes developing enterprise architectural solutions for both commercial and government clients.