TidBITS Issue #714

26 Jan 2004 | Print

Mac Users Join the "A" List

Mac Users Join the "A" List -- When Apple's AirPort Extreme (IEEE 802.11g) wireless networking system was announced in January 2003, Steve Jobs declared an older, equally fast system deadShow full article

26 Jan 2004 | Print

DealBITS Drawing: Cocoatech Winner

by Adam C. Engst

DealBITS Drawing: Cocoatech Winner -- Congratulations to Gloria Harman of yahoo.com and Richard I. Levine of pobox.com, whose entries were chosen randomly in last week's DealBITS drawing and who will be receiving a copy of Cocoatech's Path FinderShow full article

26 Jan 2004 | Print

Dantz Ships Panther-Compatible Retrospect 6.0

by Glenn Fleishman

Dantz Development's venerable Retrospect backup software is now fully Panther-compatible with an electronic download release that shipped today. Although Retrospect 5.1 would work under Panther, and Retrospect Client ran fine in Panther, Dantz had released a laundry list of situations to avoid and problems in launching and getting the application to run after restarts and system failuresShow full article

Hide full article

Dantz Development's venerable Retrospect backup software is now fully Panther-compatible with an electronic download release that shipped today. Although Retrospect 5.1 would work under Panther, and Retrospect Client ran fine in Panther, Dantz had released a laundry list of situations to avoid and problems in launching and getting the application to run after restarts and system failures. (We all stuck with Jaguar on our backup servers.)

<http://www.dantz.com/>
<http://www.dantz.com/index.php3?SCREEN=kbase& amp;ACTION=KBASE&id=28093>

Retrospect 6.0 could be seen as a maintenance release with a hefty upgrade price tag unless you have one of four special needs: making backup sets larger than one terabyte; backing up to an Xserve RAID; using tape libraries over SCSI or Fibre Channel; or spanning multiple hard drives with a single backup set, something Adam ran into with his current hard drive-based backup strategy. The company also notes speed improvements.

<http://www.dantz.com/index.php3?SCREEN=kbase& amp;ACTION=KBASE&id=28121>
<http://db.tidbits.com/article/07295>

The software is available for download right now; the boxed version follows in mid-February. Pricing is complicated, as is usual with the number of versions Dantz offers for small, medium, and large networks.

Retrospect Desktop can back up one local Mac and two networked Windows, Mac OS, or Red Hat Linux systems with the included Retrospect Client software. However, it cannot back up computers running Mac OS X Server (either locally or with Retrospect Client), and it doesn't offer the large tapeset, Xserve RAID, or terabyte options. List price is $130 with a $60 upgrade from previous versions.

Retrospect Workgroup and Retrospect Server include client support for 20 and 100 machines, respectively, and all the large data options. However, only Retrospect Server can back up Mac OS X Server systems. Workgroup lists for $500, and an upgrade is $200; Server is $800 with a $350 upgrade.

All versions include Retrospect 5.1 if you want to run Retrospect on a Mac OS 9 system; Retrospect 6.0 can back up older Macs running Retrospect Client software. Also included is a bootable disaster recovery CD, but only with the boxed version, not as part of the electronic-only purchase.

26 Jan 2004 | Print

The Mac at 20: An Interview with Bruce Horn

by Adam C. Engst

Twenty years of Macintosh. At this year's Macworld Expo, Steve Jobs played a version of the famous "1984" ad that launched the Mac, and Alan Oppenheimer, who was responsible in large part for AppleTalk, gave a fabulous talk about the history of networking on the MacShow full article

Hide full article

Twenty years of Macintosh. At this year's Macworld Expo, Steve Jobs played a version of the famous "1984" ad that launched the Mac, and Alan Oppenheimer, who was responsible in large part for AppleTalk, gave a fabulous talk about the history of networking on the Mac. What I found most interesting was that although twenty years have passed, many of the original people from those days are not only still around, they're still producing great work. The history of the Macintosh is not only still being written, some of the same people are still doing the writing.

<http://www.opendoor.com/nethistory/>

Let me introduce you to another member of the original Macintosh team, Bruce Horn, who was responsible for a number of the key aspects of the Mac and who has continued to write innovative code. At Apple, Bruce was responsible for the design and implementation of the Finder (oh, that!), the type/creator metadata mechanism for files and applications, and the Resource Manager (which handled reading and writing of the resource fork in files; a note in Apple's technical documentation at one point exclaimed, "The Resource Manager is not a database!"). The Dialog Manager and the multi-type aspect of the clipboard also appeared thanks to Bruce's ingenuity.

So, to commemorate this 20th anniversary of the Macintosh, I wanted to talk with Bruce about not just what he did at Apple, but also what he's up to now, since in many ways, his current work is both a return to his roots and a glimpse at what might be possible with the Macintosh in the future.

Adam: Bruce, many of the aspects of the original Mac that you worked on revolve around accessing structured data. The Finder was a front end to the filesystem; the Resource Manager, despite that note in the documentation, was a bit like a flat-file database; and type/creator codes were metadata that were just screaming to be used by a database. To what extent was all that planned, or did you just come to these solutions as you were working?

Bruce: Several different goals drove me to these solutions. Having had most of my programming experience in Xerox's Smalltalk environment, where you could change anything you wanted at runtime (changes made while the program was running), I was looking for a dynamic way to handle objects in the system so data such as localizable strings, menus, images, etc. could be modified by non-programmers without recompiling the source code. At the same time, I was realizing that the kind of data that I needed to manage with the Finder - icons for applications and documents, and bindings to those icons - needed the same sort of mechanism, and I wanted a unified solution. So the Finder's Desktop Database was the driver for much of what the Resource Manager ended up providing.

The file metadata also was driven by Finder needs. Early on I realized that to provide a double-click-to-open mechanism for documents, I'd need a simple way to link a document to a default application that would open it. Similarly, since multiple applications could open multiple file types, I couldn't just have a single mapping from a type to an application that would handle all files of that type. Thus the separation of the type code (the actual format of the file) and the creator code (the default application, which could be easily changed). Independent type and creator codes stored in the filesystem also enabled us to avoid polluting the filename with type information, which I felt was a significant advantage of our approach over others.

The Desktop Database was a cache of the bindings between types and creators and the icons representing them, stored as resources. Since application bundles - groups of resources tied together describing document type and icon information - were stored in application resource forks, installing an application simply involved copying the appropriate resources from the application into the Desktop. The redundant information - type and creator information in the directory, and bundle information in application resource forks - made it possible to rebuild the database at any time without losing anything. It turns out that this was important in the early days.

Resources were, of course, heavily used in factoring out non-program data (like menus and text strings) that could be localized to different languages. With ResEdit, this allowed language experts to quickly create versions of an application without needing access to the source code.

Once I was able to convince Andy Hertzfeld of the utility of the Resource Manager, he rewrote most of the Toolbox to take advantage of it, which saved significant space in the ROM and gave us the ability to easily localize applications in a general way.

Adam: So Mac OS X's reliance on Unix-style filename extensions for mapping documents to applications is something of a step backward, then?

Bruce: Yes and no. The original rationalization behind this was that Mac OS X needed to be compatible with Windows filename conventions, and to do so we'd need to force filename extensions to be provided. Because there are so many places that a file might leave the sanctity of the Mac OS and go out into the cruel world where extensions are required, it was deemed impossible to translate names from the Mac convention (with types and creators) to the outside world's convention. As far as compatibility is concerned, this did the trick.

But over time it has become apparent that it is difficult to do this right, and the original mechanism of having redundant type information, and allowing the user to name the files whatever she wants, was more flexible and less prone to error. It turns out that Mac OS X still needed a creator mechanism by which individual documents could be opened by specific applications, so this information is stored in the resource fork of the file (of all places, since Apple is discouraging use of the resource fork), rather than simply in a creator code.

So the filename extension approach has worked, but with a little less elegance than the original.

Adam: Why didn't you go all out and create a system-level database to handle all this data in the original Mac? Was it a horsepower issue, or were the software problems too tricky at the time?

Bruce: It would have been nice. I had some ideas in mind, but when it came down to fitting it in the 64K ROM, the Resource Manager was all we could fit. It was a real effort on everyone's part to make code as small as possible. The Resource Manager was 3K, and the Finder 46K - amazing considering the size of applications these days!

Adam: When did you leave Apple, and what caused your departure?

Bruce: I left Apple in the spring of 1984, after doing a "final" version of the Finder. I guess I was just looking for something new to do: having spent several years working intensively on the Mac, I was ready for a break. Being on the Mac team, working with absolutely tremendous people, was one of the most significant things I've done, and it still gives me wonderful feelings when I think about those times.

Adam: Can you give us a quick rundown of where you worked after Apple? Were there any common threads among the various projects?

Bruce: After Apple I went to Adobe and worked a bit on a variety of small projects, including a LaserWriter spooler. When I was there I met a couple of Carnegie Mellon grad students, and, to make a long story short, they convinced me that I should go to CMU for graduate school (Chuck Geschke, one of the founders of Adobe, was also a CMU Ph.D.) Grad school was a great experience. I spent some time at the University of Oslo, Norway as a research assistant, did some consulting at Apple now and then, and had a chance to work with some intriguing startups while I was a student. My Ph.D. thesis described the design of a constraint-based object-oriented programming language called Siri, which I'd love to re-implement someday.

After graduating I went back to Apple as a consultant in the Advanced Technology Group and worked on a project called LiveDoc with Tom Bonura and Jim Miller, among others. LiveDoc was an experiment in automatically structuring documents so that various recognizers could determine that, for example, 555-1212 was a phone number and 124 Main Street was an address, and provide contextual actions on those items. It was a lot of fun, and I wish I had LiveDoc today in Mac OS X. Simson Garfinkel's SBook provides some of these features as a PIM application.

<http://www.sbook5.com/>

But none of these projects really addressed the problem I wanted to solve, which was: how can I design an information browser that works with all types of data, from email messages to images to music files to documents, and provide a unified mechanism for organizing, searching, and viewing this information?

I began the iFile project in 1997 to do this, and worked on it for a couple of years before putting it on the back burner to start my other company, Marketocracy, where I've been since the middle of 1999.

Marketocracy is a mutual fund company that I co-founded with my business partner Ken Kam. Our team built a Macintosh-based Web site running WebObjects and a FrontBase database to allow over 50,000 people worldwide to buy and sell stocks in real time (but with fake money) to create a model stock portfolio. We provide a wide variety of tools to help our users to become better portfolio managers, and by watching their performance over time and ranking them, we can find the best people in the world to run our funds. Our Masters 100 Fund, based on the top 100 in our community, has been running for over two years now and has surprised even us with its impressive performance and low risk. It has returned over 39 percent since inception when the market has been essentially flat, and with a beta of 0.47 - half as risky as the market!

<http://www.marketocracy.com/>

Adam: What are you working on now?

Bruce: Recently I've picked up where I left off in 1999 with iFile (just a codename for now). iFile is a unified desktop information browser, like the Finder, but with significant architectural improvements. It is based on an object-oriented database of my own design that provides a general way for linking together and organizing objects of all types. The basic unit of organization is called a "collection," which is distinct from a folder in that an object may exist in many collections but in only a single folder. Collections are like iPhoto albums or iTunes playlists, but they can contain anything: text files, images, email messages, music files, contacts, notes, appointments, and so on. While this sounds a bit like BFS (BeOS Filing System) and the BeOS Tracker combined, it is much more general and can be used on any filesystem with the appropriate drivers.

The obvious first application for the iFile technology was in photo organization, an area in which iPhoto does quite well already. However, iFile provides more capability in organization by image metadata (it currently keeps track of 46 different pieces of metadata for each image), and it should scale much more smoothly for large collections than iPhoto. But iFile is not simply a photo manager: it is a general purpose information browser that can be used in a variety of ways, and can easily integrate different information sources, such as PIM, email, and music, among other data types. I think the version of iFile that I will release publicly will provide much more capability in those domains.

Adam: Is it fair to describe iFile as the Finder you'd write today?

Bruce: Possibly. I think it is much more ambitious than I had originally intended. If I can eventually get it scaled down to a level where new users can understand it quickly, it might be a nice alternative to the Finder.

Adam: Have you shown it to people at Apple? What did they think?

Bruce: Back in 1999 I showed it first to the Finder group, then to Avie Tevanian, and finally to Steve Jobs. I think that Apple was strongly focused on solving the problems of getting Mac OS X out the door as soon as possible, and looking at an alternative Finder was low on their priority list. I believe they were intrigued but had already committed to a different direction, and couldn't turn the ship in time to take advantage of the iFile technology. Given the history of Mac OS X, I think they made the right decision.

Adam: Let's look at iFile more deeply. There are two aspects to any filing system, getting data in and displaying that data to the user. How would someone get data into iFile?

Bruce: The current version of iFile requires the user to specify the folders that the user would like iFile to track; this is done by dragging the folders into the iFile workspace window. Once this is done, iFile tracks any changes to the contents of the folders and automatically updates the database as required. For example, the user can drag in the Pictures folder and be able to browse all the images, create collections, etc., without actually copying any files or moving any data. iFile respects your directory structures and never modifies anything directly, in contrast to iPhoto, which copies images into its own directory hierarchy.

The release version of iFile will not require the user to request that certain folders be scanned. Instead, iFile will initially provide a view on the user's home directory, and will scan the files and folders in the background automatically.

Adam: Good! The less work users must do, the better. In fact, one of the main problems with any filing system is that few people put enough effort into categorizing and managing their data to be able to find things later reliably. Can iFile automatically categorize files based on metadata and content?

Bruce: Yes, it can. Collections are a way to automatically categorize files by their properties. Because iFile maintains file metadata in the object database, it can search and sort through the metadata very quickly to return the appropriate files. Collections are also "live": specifically, if files appear on the disk that match a collection's specification, they will be automatically added to that collection, regardless of whether the collection is currently being viewed. One can imagine all sorts of interesting AppleScript scripts that could be triggered based on these events.

Collections also collect files based on their content. Rather than searching for individual words as Google does, collections search for key phrases: a word or a sentence. Files that contain any of the key phrases specified in the collection are automatically gathered into that collection.

So, what collections do is provide a new way to slice-and-dice the information you already have in a different way, without requiring you to import your data or commit to a completely new organization.

Adam: What do you think about adding a capability along the lines of a Bayesian classifier that would evaluate the contents of a file statistically, much the way some spam filters or the email classifying program POPfile work? That could reduce the user's effort even further.

Bruce: That is a great idea and has been discussed for quite some time. In fact, Apple had worked on a project that was based on this idea. Piles were automatic groupings of files based on their content:

<http://www.theregister.co.uk/content/archive/ 30360.html>

One of the challenges here is to determine an appropriate similarity function: how do you decide what the collections should be a priori, to avoid the problems of hundreds of collections, each with one file, or a small number of collections with thousands of files? That will take some work.

Adam: What does iFile do on the display side? Can users create their own "smart folders" (a bit like smart playlists in iTunes) that automatically show files that match a specific query?

Bruce: Absolutely. A collection is essentially a smart folder, with a query specification. For example, it is easy to create a collection that groups together all the images taken by a particular model camera by specifying "<Model> is '2500' and <Make> is 'Nikon'", since that data is available in the EXIF metadata for the image. Similarly, metadata such as ID3 tags for music; image data such as resolution, width, and height; file data such as filenames, creation and modification dates, and sizes; and so on are all stored in the database for object retrieval and organization.

So collections actually have three mechanisms for grouping: manually via drag-and-drop; automatically via metadata query specification; and automatically via key phrase match.

Adam: iFile's architecture sounds tremendously appealing, but I suspect the devil is in the details, and thus in the interface. Does iFile stick with the current file/folder metaphor (despite the terminology shift to collections), or does it offer a rethinking of how we interact with our data?

Bruce: You are right that the devil is in the details. I'm currently working on how to present all this information in an appropriately intuitive fashion, and I think I'm getting closer, but there is still clearly work to do.

iFile begins with the traditional, icon-based file and container organization (containers being either folders or collections), but goes further with a variety of different views and layouts. Many of the layouts provide preview views of the contents of the files, and in the case of text files, iFile automatically creates hyperlinks to related collections from within the text. It's difficult to explain, but once you use iFile you'll find that some of the views do in fact provide you ways to view your data from different perspectives.

The more you provide iFile with information regarding how you want to see your data, via defining collections, the more it can help you by cross-indexing and showing relationships where they were not clear before.

Adam: Are some of the things you're attempting in iFile beyond what many users can understand? Lots of people just want to be told what to do, and something with iFile's flexibility might be lost on them unless it was able to watch their actions and automatically build collections.

Bruce: I agree that iFile can be somewhat intimidating to new users: there are a lot of different things that iFile can do, and there needs to be more immediate gratification when using it. Creating collections automatically is a good approach, and by creating useful collections based on not only images but documents and email, I think that the power of the technology will become more apparent. I'm planning on implementing some of this in the next few months, so stay tuned! For anyone interested in this technology who would like to be contacted when there is a public version available, sign up at the site below, and I'll keep you up to date. I'd be happy to go into detail about the release version in a future issue of TidBITS.

<http://www.ingenuitysoftware.com/>

Adam: Bruce, thanks for taking the time to chat with me, and we're all looking forward to seeing what you come up with iFile. Who knows, perhaps now that Apple has stabilized Mac OS X, they'll be interested in looking at what you've done again.

26 Jan 2004 | Print

Can CAN-SPAM Can Spam?

by Brady Johnson

Talk about deja vu. I recall having written this introduction for a TidBITS article about spam before, each time changing the unhappy statistics about spam volumes in an upward directionShow full article

Hide full article

Talk about deja vu. I recall having written this introduction for a TidBITS article about spam before, each time changing the unhappy statistics about spam volumes in an upward direction. I always start by looking at Brightmail and other sites that track spam to see how the efforts have fared so far. Sad to say, the news has never been good. Even Congress has acknowledged this in the opening lines of the CAN-SPAM Act, enacting this sorry comment into law: "Unsolicited commercial electronic mail is currently estimated to account for over half of all electronic mail traffic, up from an estimated 7 percent in 2001, and the volume continues to rise."

<http://db.tidbits.com/series/1169>

In fact, according to Brightmail, spam is rising faster than the mercury on a hot summer day. In 2002, spam accounted for 40 percent of all email, meaning that if Congress's 7 percent number is correct, between 2001 and 2002 there was a nearly 600 percent increase. By the end of 2003 that number had soared to 58 percent. If the trend continues, 65 percent of our email will be spam by the end of 2004.

<http://www.brightmail.com/spamstats.html>

To stem this tide, Congress has enacted the "Controlling the Assault of Non-Solicited Pornography and Marketing Act," or CAN-SPAM. On 16-Dec-03 President Bush signed the bill into law and it became effective on 01-Jan-04.

<http://www.spamlaws.com/federal/108s877.html>

CAN-SPAM has generated much discussion and debate, with much of the wired community angrily dismissing it as a deal with the devil and the marketing community hailing it as a significant step forward in the battle to combat spam.

Reading the various commentaries on CAN-SPAM, it quickly becomes clear that a key disagreement turns on the definition of "spam." To many regular Internet users, "spam" includes any unsolicited bulk email from any source. To these users, CAN-SPAM addresses only a small subset of spam while legitimizing the rest of it. The marketing community and others maintain that bulk email that is not misleading or deceptive is fair exercise of their commercial free speech rights and is no more objectionable than junk snail mail. Thus, they claim that it should not be included in the definition of "spam." To these users, CAN-SPAM represents a major step forward.

What Is "Spam" Anyway? I feel obligated to point out that spam is actually a pinkish processed meat product made by Hormel. Hormel has belatedly taken issue with using their product's name for noxious email and is attempting to block trademarks that include "spam" such as SpamArrest.

<http://abcnews.go.com/sections/scitech/Business /techtv_spam030801.html>

But to many folks, "spam" simply refers to any unwanted email from a stranger trying to sell a product, tout a position, advertise a commercial Web site, or sway the reader's opinion in some way. As anti-spam legislation has been enacted in the various states, the definition has morphed and narrowed to "unwanted commercial email" or "UCE," exempting non-commercial email such as political or charitable solicitations. CAN-SPAM narrows this definition even further.

CAN-SPAM uses the term "spam" only in the title acronym and in one of the initial recitations. (Recitations in a statute have no legally binding effect and are merely statements of policy reasons to aid courts in interpreting it.) CAN-SPAM defines "commercial electronic mail" as email, "the primary purpose of which is the commercial advertisement or promotion of a commercial product or service." Political and charitable solicitations are still excluded from this definition, as are "transactional or relationship messages," which are email messages from a party with whom you have an existing connection of some kind.

CAN-SPAM gives the Federal Trade Commission (FTC) the authority to change the definition of "transactional or relationship messages... to the extent that such modification is necessary to accommodate changes in electronic mail technology or practices and accomplish the purposes of this Act." However, the FTC does not have authority to alter the definition of "commercial electronic mail."

Key CAN-SPAM Provisions -- CAN-SPAM's most severe prohibitions focus on certain types of deceptive and fraudulent email. These can subject the spammer to substantial criminal penalties of three years in prison for a first offense and five years for a subsequent offense, or for deceptive commercial email that is sent in furtherance of another felony. This would include, for example, the many messages claiming to be from exiled political leaders seeking help to launder and share their hoards of untold wealth if only the recipient would provide a valid bank account number to them first. Those messages - already the subject of prosecutions under existing criminal statutes - are subject to further criminalization under CAN-SPAM.

Other criminal acts include using a computer, server, or domain to send or relay commercial email without the lawful owner's permission, and using false headers or misleading subject lines. These activities are also subject to civil actions and penalties in addition to criminal prosecution.

CAN-SPAM uses an opt-out model, requiring that all commercial email include a method of opting out of future mailings from the sender and must include the sender's real email address and snail mail contact information. The statute specifies that spam must contain a mailto, Web link, or other online mechanism that the recipient can use to opt out. All commercial email subject to CAN-SPAM is required to identify itself as an advertisement. The statute does not specify how spammers should identify their email, leaving that to the FTC, which has until April Fools Day (01-Apr-04) to publish the identifying marks that spammers must use. Like other provisions of CAN-SPAM, this identification requirement does not apply to mail sent to anyone who has affirmatively consented to receiving the messages.

CAN-SPAM considers certain actions to be "aggravated violations" potentially subject to more severe penalties. These include the common practice of harvesting email addresses from various Internet sources and of using "dictionary attacks." Hijacking someone else's server is also an aggravated violation.

One heavily criticized component of the Act is the provision preempting all state laws addressing spam with certain very limited exceptions. The only state laws that survive this evisceration are those that prohibit falsity or deception in commercial email such as the Washington state statute and large parts of the California statute, and those that only incidentally affect email. Examples of statutes with incidental effects on email would include general computer trespass laws, consumer protection statutes, and other laws that apply generally to conduct that may sometimes include email. That means that much existing state law has fallen by the wayside and that the California opt-in statute which was to take effect this year has been essentially nullified in most material respects.

As far as enforcement goes, CAN-SPAM allows no private right of action, meaning that individual victims of spammers cannot go to court and sue for violation of the statute. Authorized enforcers are the FTC and other federal government agencies, state Attorneys General, and Internet service providers. It's worth noting that Internet service providers often have their own acceptable use policies relating to email and spam. The new federal statute does not disturb these private rules, meaning that an ISP retains authority under those policies to cancel or suspend a user and often to claim damages, etc. for violation. Leaving ISP authority in place provides an independent, if seldom-used, basis of liability against spammers.

Will CAN-SPAM Work? I don't think so. CAN-SPAM is a decent enough starting point, but in my opinion it has too many flaws to make it effective to stop or even slow spam.

CAN-SPAM's good points are that it is a federal statute and thus applies uniformly throughout the United States. This eliminates the sometimes confusing patchwork of different laws in the states that have enacted anti-spam statutes. It also goes a long way toward resolving jurisdictional issues involving whether a state has authority to control a business operating outside its boundaries. These jurisdictional disputes were quite common under state spam enforcement.

It's also good to see the various "aggravated violations" called out and codified, since having them more clearly made illegal will simplify the job of prosecutors.

Also, anything that increases the potential liability for spammers may sway the economic balance of spam. If sending spam could result in prison, spammers will have to determine if the rewards are worth the potential risk. While added liability may not impact the scofflaws who will ignore any legal mandate or prohibition unless they are arrested, increasing the risk of prison or significant monetary penalties will probably scare off businesses that might been considering skirting the law before.

But despite those good points, CAN-SPAM's flaws abound. Let's examine them.

International Problems -- Unfortunately, CAN-SPAM applies only in the United States. True, U.S. law and international treaties do confer jurisdiction on U.S. courts to address issues arising internationally if they impact the U.S. But while that may sound nice on paper, it suffers from two major problems.

First, there is the problem of actual enforcement. Spammers operating outside the U.S. are often not subject to U.S. courts, and even where they are, any judgment or court order is worthless unless it can be enforced. This fact means that the only way an enforcement agency can compel a foreign spammer to comply with the law is via diplomatic pressure from the U.S. Show of hands: how many people think that enforcing U.S. spam law is likely to become a high priority for U.S. diplomatic efforts any time soon? Now, if we could show that spammers were actually fronts for terrorist organizations...

Second, CAN-SPAM's opt-out approach is directly at odds with the approach taken by much - perhaps most of the rest of - the first world. The European Union has adopted a Directive (a policy document) that establishes an opt-in approach. Each individual member nation must then enact specific laws implementing the Directive. (The first URL below goes to the English language version of the Directive; the second URL leads to versions in other languages.)

<http://europa.eu.int/eur-lex/pri/en/oj/dat/2002 /l_201/l_20120020731en00370047.pdf>
<http://europa.eu.int/information_society/topics /ecomm/useful_information/library/ legislation/text_en.htm#dir_2002_58_ec>

Australia has also adopted an opt-in law broadly prohibiting commercial email being sent to Australians. In short, while it seems likely that most spam comes from the U.S. or is touting products and services of U.S.-based companies, opt-in appears to be the model of choice in most of the technologically developed world, with the U.S. falling out of step with the rest of the global community.

These conflicting approaches are likely to cause problems similar to, and perhaps worse than, those that existed within the U.S. before the federal law was passed, and when there were various state statutes with differing mandates and standards. In the U.S., at least all of those states were subject to the same federal government and general rules of legal analysis and interpretation. On the international scene, the problems caused by such wildly conflicting anti-spam models are likely to be worse. Since the U.S. law is less restrictive, it appears to me that the E.U. nations and Australia may continue to be flooded with spam that is legal in the U.S., but illegal in their countries.

Opt-Out Problems -- The unfortunate choice of an opt-out model requires that recipients contact the sender to opt out of future messages. While this may work for legitimate marketers who actually include a working unsubscribe mailto or Web link in the message, most spam is not legitimate, and use such links merely as unscrupulous means of confirming or harvesting email addresses. By encouraging people to use these opt-out links, CAN-SPAM may actually increase the amount of illegal spam. It also potentially increases the risk of identity theft and other crimes targeting the unsophisticated Internet user.

Enforcement Problems -- CAN-SPAM puts the entire burden of enforcement on the shoulders of already overworked federal and state enforcement agencies, which show no signs of rushing to prioritize spam enforcement. It seems likely that ISPs will take action, but most ISPs lack the resources to mount intensive investigations to track down spammers in other countries, or to support the sort of litigation that may be required to bring them down.

To be fair, prior to CAN-SPAM, most enforcement had to take place at the individual level, much of it in states without strong anti-spam statutes. Most individuals can't afford the expense of a full-fledged spam investigation any more than many ISPs can. But CAN-SPAM does not permit individual victims to file private suits for violating its terms. It seems counterproductive not to allow individual enforcement since it would both aid in the overall effort to combat spam, and would result in remedies to the actual spam victims - the end users - in cases where the spammer could be found and held accountable.

Lastly, even once spammers are dragged into court, CAN-SPAM may suffer from loopholes. For instance, the "primary purpose" prong of the spam definition means that spammers can include personal notes in their messages that incidentally offer something for sale, then argue that the solicitation was not the "primary purpose" of the email. I suspect that most people reading this have received spam along the lines of: "Hi there! How are you doing? I am having a great time. By the way, I ran across this item <insert product here> and thought you might be interested." While this ambiguity may not pass the laugh test in court, it is the sort of thing that will almost certainly have to be tested in court before it has any appreciable impact, thus further delaying any potential benefit until one of the authorized enforcers chooses to put the question to a judge. This is another reason that individual enforcement would have been a good thing - it seems more likely that an individual or consumer group would take up this issue sooner than I expect one of the authorized enforcers to do it.

Summing Up -- In previous articles, I have concluded that if spam is outlawed, only outlaws will spam. An increasing amount of spam is already in violation of our current state laws and has not been eliminated or even reduced as the result of having been outlawed. Legitimate companies have attempted to comply, but the less-than-legitimate scum will freely violate the new law unless and until they are physically caught.

In the final analysis, CAN-SPAM is a good start, but is far too flawed to be an effective tool against spam. Like the state laws, it will successfully prevent legitimate companies from resorting to spam (not that most legitimate companies were spamming before), but it will have no impact on spammers outside of U.S. jurisdiction and thus not subject to the U.S. law, or on unscrupulous spammers who will ignore the law unless they are arrested. The inconsistency with anti-spam laws used in other parts of the world may harm those nations' efforts to control spam by allowing spam from the U.S. to circumvent their laws.

Put bluntly, CAN-SPAM tells spammers that they can spam, so long as they are careful to drive their truckloads of spam through the truck-sized loopholes in the statute. What's perhaps most disappointing is that we've waited for years for a federal anti-spam law, and the one we ended up with isn't nearly as good as it could have been, or even as good as some of the now-preempted existing state laws are. That's a shame, and it's one we'll undoubtedly have to live with for some time.

[Brady Johnson is a grouchy attorney in Seattle who really, really hates spam.]

26 Jan 2004 | Print

Hot Topics in TidBITS Talk/26-Jan-04

by TidBITS Staff

AppleWorks international versions -- It wasn't clear when Apple released the latest AppleWorks update, but an international version was also updated at the same time (though French is still not updated) (2 messages) Habeas under attack -- Habeas is facing its first serious test in the war against spamShow full article

TidBITS Watchlist

Type Faster on an iPhone or iPod touch

Recent TidBITS Talk Discussions

Other articles in the series Spam Laws

TidBITS#714/26-Jan-04

Mac Users Join the "A" List

DealBITS Drawing: Cocoatech Winner

Dantz Ships Panther-Compatible Retrospect 6.0

The Mac at 20: An Interview with Bruce Horn

Can CAN-SPAM Can Spam?

Hot Topics in TidBITS Talk/26-Jan-04

TidBITS Watchlist

Type Faster on an iPhone or iPod touch

Recent TidBITS Talk Discussions

Other articles in the series Spam Laws

TidBITS#714/26-Jan-04

Mac Users Join the &quot;A&quot; List

DealBITS Drawing: Cocoatech Winner

Dantz Ships Panther-Compatible Retrospect 6.0

The Mac at 20: An Interview with Bruce Horn

Can CAN-SPAM Can Spam?

Hot Topics in TidBITS Talk/26-Jan-04

Mac Users Join the "A" List