Readers Get Creative About Stamping Out Spam

In his Dec. 6 column, ''Business Technology: Ends Don't Justify Means, Despite Appeal'', Bob Evans asked readers what we should do about spam; the person with the best idea will receive a complimentary registration to our Spring Conference in Amelia Island, Fla., April 10-13, 2004. Here are the responses.

InformationWeek Staff, Contributor

December 17, 2004

5 Min Read
InformationWeek logo in a gray background | InformationWeek

Restrict Content Of Bulk E-Mail

A little requirements gathering might be in order to see what E-mail is about and how to proceed.

If we skip the obvious that E-mail with attachments from our friends or associates is something we want to keep, do we really want to get bulk mail?

Unfortunately, the answer is yes. The content of bulk mail, however, needs to be severely restricted. For example, an incoming E-mail message truly from one of my friends should be accepted in its complete form, but unknown senders should be able to send only a very short text (no HTML/Active-X content) to my mailbox indicating that they want to send a message. Some networking companies and instant-messaging software offer this type of courtesy message.

But, since we still don't know whether what the potential future friend is going to send is dangerous, we need to restrict the access of the content, much like what a guest logon does. The message content could be more than simple text, but unable to access any stubs that are considered potentially dangerous.

Next, if we decide that the sender is actually a good one, we can grant more access privileges, like to public files or even private files, or we can have dialog boxes to permit such access if attempted by the message content.

This framework is basically like "doorbell" message, "open door with chain intact" message, "open door" message, and "prepare a room for the visitor" message. Some will argue ad nauseam that it really should be five levels, not four, or infinite levels or just two levels with permissions for each content-accessible service under the higher one, but the point is that more than access or spam is needed to classify messages. We can still trash spam.

Now, having laid this framework of E-mail access, we need to discuss determining whether a message is really from a friend. This is where most people roll their eyes at the concept of checking the authenticity of sender. Immediately, hackles go up and encryption is the be-all and end-all of authentication. How we decide if a message is actually from a sender is a separate topic, but conceptually the sender gives us a method to recognize his messages as genuine, such as a public key, and he uses the private key to sign the message or parts of it to authenticate it as genuine. Encryption of the message for privacy is not discussed here at all. Implied authentication by privacy encryption is a red herring, not worthy of passing comment.

The architecture to provide connections is fairly complex currently, and monkeying with it will cause heartburn, but there is already much heartburn over spam and phishing to warrant considering alterations. Senders can connect directly or through a "post office," and receivers generally receive those messages through a post office, now that SAML doesn't work in the WWW. It should become a responsibility of post offices to record the sending IP address and insert it in the E-mail envelope in such a way that it can be proved where the message originated. Fake envelope contents should not be possible. Part of the connection process to port 25 should include offering "doorbell" service. The value of using a separate port for doorbell is doubtful.

The doorbell service would accept very short messages in plain text only (say 30 characters of subject only) to pass to a recipient without the post office's indicating whether the recipient is really valid or not. VCF might be a good candidate for doorbell messages, although assurance that no damaging content could be carried in them would be required. AIM offers the doorbell mechanism by opening a dialog box that Sender X wants to send a message. What's missing is the ability to restrict the access of the content of any messages permitted until Sender X is judged to be a friend. We also might reserve VCF for the next level of interaction and carry the public key or other mechanism to validate the genuineness of messages from Sender X.

Once the potential recipient has allowed the sender to move up from doorbell to door-ajar status, either the post office can enforce the rules by defanging damaging content or the recipient's mail program can defang them. Likely, both approaches will be needed to assure enforcement of policy, and enabling the recipient's mail program to permit or deny content access to machine services can then be a user decision as to what access for what sender on an individual basis.

[Note that Yahoo does provide the near-equivalent of SAML by holding IMs until the target logs back on. All IM programs should have this capability. Recently, I saw David Crocker receive an IEEE award for "contributing the @-sign to E-mail" or words to that effect. He did do a lot to help advance E-mail and its adoption. His hard work is sincerely appreciated, but I would like to apply for contributing the !-sign. You have a choice, except for Yahoo, that a message either goes by E-mail or by IM. Let's make the !-sign indicate a preference for IM but to E-mail the message to the corresponding address if the user is not logged on. Apologies to BGP users, D Crocker and to Yahoo, but it is frustrating to have two addresses, one for E-mail and one for IMs, and no way to indicate the urgency of the message except in X-headers. So, instead of @ we can put bang! between user and domain.[

Bob Evans was probably asking something else about spammers, but this is my contribution on the topic.

T. E. Sumner

Return to the story: Business Technology: Ends Don't Justify Means, Despite Appeal

Go to the winning letter on spam control

Read more about:

20042004
Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights