My theory of the internet is that it is a medium for the exchange of information. More precisely, it is a medium for exchanging specific information actively sought out or which one desires to receive. The spirit behind the internet was and should be, "show me how to find it and I'll do the rest myself." I believe everything proposed here is in keeping with that basic philosophy. All of us have better things to do than wade through emails that we don't want.

It is also important for commercial users of email to present their product to the market, and to keep their names before clients who have specifically requested they do so. But in these cases it must fundamentally be the burden of the company to provide choice to the consumer; the technology of the internet should redound first to the benefit of the customer in a business setting. The solution proposed here allows continued email marketing while preserving the "Desired Information Only" philosophy of the internet.

Commercial use emails are proliferating. I see more and more HTML emails in my inbox (some nice looking, some really ugly) as people take advantage of this feature. HTML Emails are taking advantage of animated gif and Flash technology. The reason is that more people have the bandwidth to receive them, and the programming is catching on. Why send a plain text email when you can send a brochure just as easily? The trend is only going to increase as web designers try to offer their clients better ways than banner advertisement and search engines (which are not doing too well) to get their sites in front of potential clients. Certainly the best source of business is a client who has actively asked for information from you.

Issues that arise here are development of some conventions for email marketing, what is proper, what is improper, and how to enforce those conventions such as:
Stating whether it's from a known source or not, and the exact time you signed up for the service, and where you can go to modify this.
1. Allowing user to control content
2. Allowing user to have a one-click unsubscribe feature.
3. Keeping the actual message short and giving locations of where to get more (or to have your XML function archive the information and process it for you)
4. Allowing the client to control how often (and when ) he or she prefers to receive emails.

Businesses should remember that desirability is the paramount feature to offer in an HTML Email. I like getting "GearMails" from R.E.I. even though I don't always read through them due to time constraints. I like them because 1) It's an area of interest to me, 2) I don't feel as if there will be anything lost if I delete it, 3) I signed up for it. If you could add to that the ability to click and say "hold my mail for a few months, this is a busy time" I would feel even more in control.

What I hope to see developed in the next two to three years is a way of having a public email, but which no one can use without your permission. In other words, there is a way of giving your email out to a friend or associates so no one else can use it because of the protocol itself, BUT without adding work or effort to the owner of the email address or the users the owner wants to hear from. Let's start with a physical analogy:

Suppose I had a P.O. Box (I actually do have one; mine is Box 2095 in Culver City). That P.O. Box has an individual box number, along with a way of separating that Box from other Box 2095's in other Post Offices, i.e. the City and Zip.

Let's take a look at the shortcomings of this physical mail setup:
1. Letters are easy to address and send-just print labels for Boxes 1-5000 and you've got them all. Anyone can send me mail whether I know them, or whether I want their mail. Even it I don't read through the mail, I still have to look at it to see if it might be a bill or a check for a client, and I still have to throw it out.
2. There is no way to reject mail at the box level based upon the originator. (The post office will send mail as long as it's stamped.) Furthermore it is possible to send an envelope with no return address. You can tell the post office it was sent from but little more.
3. The address may or may not be mine, since at any point someone else could take it, so I could get mail intended originally for someone else at that box.
4. There is no "holding place" before the box-I must take all the mail and decide from there if I want it or not.
5. I cannot selectively hold some mail and keep other mail. I can hold ALL my mail when on vacation, but when I get back it'll all be there, waiting for me.

Email addresses are almost that easy to ascertain, and cheap in terms of processor time to send, and delivered very reliably. This "sower sewing the seed" approach is great for spammers, but not so great for us.

I believe we should expect internet technology to provide more solutions than the postal service, and in the next few paragraphs I hope to broaden your understanding to see what could be versus what is.

A Better System

Now, here's the goal in my opinion--to create a mail delievery system where

1. My friends and associates have a way to email me so I know that the email was from them (i.e. a known friend), and this occurs with no additional effort on my part or their part.

2. When I sign up for newsletters, I can give newsletter providers a "certificate" that I could control within my mail client, allowing me to specifically control receipt of their mail, without having to unsubscribe with them.

3. The commercial or other user would receive a response and be able to differentiate between returned misaddressed mail, and mail that was not accepted, and even WHY the mail was not accepted (I'm busy, articles are too long, hold any mail from you for two months, whatever).

4. Even though my email is public, no other person could use the information that the commercial user had to send accepted emails (i.e.-my email address could not be "sold" to Amazon by Ebay.com, because nobody else could use it).

5. All other mail just bounces off into a black hole in space; unless for some crazy reason I want to receive it.

These five issues are key to protecting both the information to the user and the marketing ability of the commercial user. (and though I won't discuss it in this article, you'll realize that this will force commercial users to be as to-the-point and effective as possible in their communications). You will realize that the solutions I am proposing would require a radically different email viewer and probably an extended protocol and server configuration.

Now, feature number one would make it difficult to email if I met someone at an office and exchanged business cards with them. It would be the first contact for whoever initiates the email, therefore I or they are unknown to the other party's email viewer or mail server. Options: We could come up with a code between us, but for lack of a more noble-sounding explanation--well, who wants to do that? Probably the easiest thing to do, and which would be no more a step than done typically, would be to require both parties to email each other. Suppose he emails me first, then I email him. My mail viewer, then, would "sense" that I sent an email to the other party, and therefore the email that he or she sent just prior to me would be recognized, and would appear in my inbox. This works because if the other person emails me now, he or she generally only knows if I received it if I email back.

For family that know my email and know me, as well as my new associate at the office above, I could set up a few simple codes on my email viewer, or a third party service that stores NON-CRITICAL personal information such as the last wedding that I went to (Kellie's and it was great, and her husband is a great guy by the way), what my Junior English teacher's name is, what's my favorite football team, etc.-stuff that I don't really care if the world knows but which they probably DON'T. Storing this information on my mail client would be done with parameters such as:

Favorite sport = hockey
Favorite color = blue
What I did at the party last night = danced on the table (well, not really)
Where I went to school = Austin

My new office associate could just remember that I told him last night that I went to school in Austin, TX and remember that when sending an email. Any family member or friend who can go to the third party service and get one or two answers right and the email goes through to my inbox-although they won't know it went through unless I respond. (If they don't know that I went to Kellie's wedding last June then they must be from some other planet anyway).

These ideas all use LOW security technology to make it almost impossible for a spammer to mount a spam campaign without making it harder for the rest of us.

The biggest issue would be "certificates" given to commercial users. Currently as a Visual Basic programmer it's easy to "forge" the from address; I can generate an email which will read as being from Mister-Ed-the-talking-horse@NBC.com in a heartbeat. But you can easily debunk this if you look at the routing codes in the email; any email will have a signature of the mail server that sent it, time sent, path sent by, etc., etc.-so if the server doesn't belong to NBC's servers, which is easy enough to figure out, then it's obvious that the person who's talking isn't Mr. Ed, the horse, of course, of course. (Click here for Mr. Ed's comment)

If my browser and mail viewer worked together I could give a commercial user a "certificate" when I sign up for a newsletter or other transaction, which would allow them to send me email from their mail server; this certificate won't work from any other server, so it would be hard to sell the certificate profitably just to other commercial users of that server. Besides, since I'd have a line at the top of my email saying who sent the email (like a subject line, but controlled by the certificate), I will know that this commercial user gave my certificate to someone else (because the email is from Honest Bob's Tire Store for example). It is then easy enough to send a complaint to THAT SERVER, which controls his email delivery.

Ideally my mail viewer should have the ability to send emails with certificates which will upon receipt by the other party allow only email-to-email communication between emails with those domain names, and between those servers. An example would be if I were to send an email from sam@compasspointmedia.com to Susie@ibm.com, there should be a piece of data on my computer and hers which would allow further communications strictly between my computer, my mail server, and the compasspointmedia.com domain, to her mail server, her domain, and her computer. As you can see from this example, there are three levels of control available on both ends. I think we can "keep it simple stupid" while preserving the concept of Desired Information Only.

Note that I have not addressed security issues here but only the limitations on transfer of information. Security issues may be covered in a future article.



Please click on these links for the following relevant subjects:
1. Customizing your Outlook and Outlook Express
2. An example third-party information control service.
3. Topics on Email Client Base management.
4. Further discussion on levels of control of identity of the second party.

Terms used in this article:
Commercial User
Certificate
Email viewer
HTML Email