The Federal Trade Commission's commissioner Orson Swindle gets spam -- both literally and figuratively. If Swindle's inbox was not being inundated with junk e-mail, he might not be nearly as motivated -- as he was at last week's FTC three-day forum on spam -- to see that something gets done about it.
Judging from the keynote he gave to a standing room only crowd of vendors, scientists, politicians, and press to kick off the forum's final day, Swindle appears dedicated to tackling a problem that threatens one of the Internet's biggest killer apps.
I was surprised and impressed by the FTC's attempt to develop a 360-degree view of the spam problem. The forum covered every solutions angle from legislation to technology, many of which are outside of the FTC's purview. Swindle and other FTC folks proved to be aware of the delicate balance that must be struck among legislators, developers, service providers and e-mail senders and recipients if a domestic (let alone international) anti-spam law and technology dragnet has any hope of achieving the only acceptable end game: to make spamming a waste of time.
The efforts on behalf of all of the communities working against spam --- particularly the legal and technology communities --- must be harmonized with each other. If they're not, we'll end up where we are today with blacklists (see story below)--only worse.
Inspired by the book Tuxedo Park, Commissioner Swindle urged those empowered to stop spam to do so in a collaborative fashion. In that non-fictional World War II story, the allied leaders realized that a more mature version of the radar technology developed by the British could give them the upper hand against the Axis powers. Some of the free world's top scientists were committed to a collaborative project that proved to be one of the most important rapid response teams in history. Virtually overnight, the collaboration produced a bevy of radar-oriented, tide-turning technologies that gave the Allies unsurpassed powers of observation and helped return to them the upper hand in the war.
In the war on spam, the need for collaboration between legislative and technological approaches is particularly evident in the unsubscribe problem.
Many people complain that when they receive spam, the spammer-provided unsubscribe mechanism doesn't seem to work. For the most part, these mechanisms, whether e-mail or Web based, are little more than Tom Foolery designed to determine whether the recipient's e-mail address is active.
| | ||||
| |
||||
| Dark side of blacklists For those of you just joining the discussion, blacklists are used by Internet service providers to deny spam safe passage through the Internet. However, an ugly side effect of this well-intentioned idea has been the non-delivery of legitimate e-mail, often without notification to the sender that a failure has occurred. It's a shining example of what happens when one or two communities trying to eradicate spam take action without consulting the other communities that might be affected. Most everyone I know now agrees that blacklists were an ill-conceived idea. At least three communities --- the vendors of e-mail clients and servers, the vendors of anti-spam solutions, and the Internet Service Providers --- should have worked together to produce a more harmonious outcome. They might have figured out that filtering based on message content or source IP address is not a battle worth fighting because spammers are willing to fight that battle. |
||||
| | ||||
| | ||||
The problem is that the different anti-spam communities are not talking to each other. The three aforementioned communities -- vendors of e-mail clients and servers, vendors of anti-spam solutions, and ISPs -- should get together with three other communities--antispam advocacy groups and legislative bodies, legitimate bulk e-mailers, and individuals and organizations who depend on e-mail for communications. For example, having bulk e-mailers ask for a hall pass based on a set of best practices they devise without input from the recipients is not unlike letting the fox watch the henhouse.
Should all six communities get together, they might realize that something as subjective as a list of certifiable best practices will be impossible for lawmakers to enforce, and even more difficult for technology to incorporate. A better blend of technology and law would be to provide a standard, enforceable way for an e-mail recipient to terminate a relationship with any sender.
Today, we have two ways of terminating an e-mail relationship: with filters, or by unsubscribing. Neither works very well. Since just about anything in the e-mail header can be forged, filters cannot reliably identify an e-mail's source, much less terminate our relationship with it. Even though an unsubscribe mechanism may be mandated by law, method of implementation is still up to the sender and not all senders see themselves covered by the law.
| | ||||
| |
||||
| Communities working against spam * Developers of email clients and servers * Developers of email security solutions * Internet service providers and Inbox Providers * Non-profit privacy and antispam advocacy groups, and legislative bodies * Individuals and organizations who depend on the reliability of Internet e-mail for everyday business communications * Legitimate senders of high volume e-mail |
||||
| | ||||
| | ||||
The answer is to remove subjectivity from the legal and technological tests. During the forum, I posited that existing mail protocols need to be hardened in such a way that source can be positively identified at the sender level (which, technologically, requires tamper-proof credentials) and that the ability to terminate a relationship should be embedded into a protocol supported by all e-mail clients and servers.
By embedding it into a protocol, a recipient could pick a "terminate relationship" command from the e-mail client's menu in the same way that the recipient now chooses the "send" command. If, when viewing a piece of e-mail, the recipient issued the terminate relationship command, the original sending system would recognize that as an instruction to never again send an e-mail to that recipient. Furthermore, prior to allowing that e-mail into the recipient's inbox, the e-mail server on the receiving side could test the sender's system to make sure its support for the protocol is up to snuff. It would also check to make sure the credentials on the e-mail match those of the sending system and that the credentials have not been tampered with. If any of these tests are failed, the mail is not allowed into the recipient's inbox and a message is returned to the sender indicating the reason for the failure.
Tampering with the credentials or disabling the protocol should be made illegal, in the same manner that tampering with the odometer on a car is illegal.
Why does this make sense? Because the technology and the law can respond to simple pass/fail tests instead of a gray area that is impossible to navigate. Another advantage is that it allows a recipient to terminate an e-mail relationship with anyone. Forget the messy business of who is and who isn't a spammer. It doesn't matter. I should be able to terminate relationships with spammers, businesses, or individuals.
| | ||||
| |
||||
| Reader Resources ZDNet White Papers |
||||
| | ||||
| | ||||
This sort of framework also makes it easy for international governments to pass their own laws which, similar to the way running a red light is illegal in most countries, provides for a system that's universally understood by everyone and easy to implement.
Certain countries, like South Korea and France, are willing to be very tough on practices associated with spamming. In France, for example, it's illegal to harvest e-mail addresses from the Internet. I'm rather certain they'd be happy to install a few more laws as long as most matters of interpretation as well as international deltas in culture and business ideology were avoided. Even for those countries that don't outlaw protocol tampering, the technology would still serve as a fall back for keeping most non-compliant mail out of our inboxes.
There's no silver bullet for spam. But, a combination of technical and legal approaches , requiring a great deal of harmony between all those empowered, could draw us much closer to the end game I identified earlier--making spamming a complete waste of time.
Commissioner Swindle recognizes that all anti-spam communities must work together to produce a tightly integrated system of anti-spam laws and technologies. But he also acknowledges that this sort of multilateral cooperation can't be mandated by the FTC--or by anybody else. Cooperation has to come from the troops.
JamSpam bearing fruit
Such a framework for cooperation is precisely what JamSpam is about. Already, JamSpam appears to be bearing some fruit. Shortly before the FTC began its deliberations, the three biggest ISPs --- AOL, Yahoo, and Microsoft ---- announced that they would begin to work together on the spam problem. Officials from all three companies (and Earthlink) conducted introductory business card exchanges at the first JamSpam meetings.
During the FTC's final session on technology and structural changes, Microsoft's Ryan Hamill was non-committal on what the new partnership would produce. But he did promise to solicit feedback from all interested parties before moving forward. I hope that this feedback is solicited at the next as yet unscheduled JamSpam meeting, which AOL has volunteered to host at its Virginia headquarters.
So far, JamSpam is the only ready-made forum in existence where the who's who of every community with a stake in the spam problem and most of those who would want to comment on any proposal put forth by the leading ISPs are already organized (mailing lists included!) and waiting for an invitation to act.
With a cooperative framework like JamSpam in place, where technologists and legislators can gather on a regular basis, a repeat of blacklist-like sins is greatly decreased. But, whether it's under the umbrella of JamSpam or not, I hope everyone takes to heart Commissioner Swindle's request to cooperate.
Use TalkBack to let your fellow ZDNet readers know what you think. Or write to me at david.berlind@cnet.com. If you're looking for my commentaries on other IT topics, check the archives.









