Previous Issue | Search TidBITS | TidBITS Home Page | Next Issue

TidBITS Logo


Drowning in email? You need filters, and according to William Porter, you need Mailsmith, thanks to its innovative distributed filtering approach. Matt Neuburg offers a quick look at the new StuffIt Deluxe 7 and its new StuffIt X file format, we announce our sessions at the upcoming O'Reilly Mac OS X Conference, and we glance at a trio of updates from Apple, a new version of the PowerMate software, and an 8-inch Godzilla-shaped FireWire hub.


Copyright 2002 TidBITS Electronic Publishing. All rights reserved.
Information: <> Comments: <>

This issue of TidBITS sponsored in part by:


Apple Releases Mac OS X 10.2.1 and iTunes 3.0.1 -- Apple pushed a trio of small upgrades out the door last week through Software Update and as separate downloads. The most significant was Mac OS X 10.2.1, which peppers the operating system with numerous small enhancements. Examples include improved compatibility between iMovie and media converters; the capability for CDs burned on a Mac to be read under Windows; improvements in Mail to avoid messages being lost when the connection is broken; resolved printing issues; and a handful of iBook fixes. Mac OS X 10.2.1 is a 17.1 MB download. Also released, but without details about what's changed, was iTunes 3.0.1, which offers unspecified performance enhancements and Jaguar compatibility; the update is a 5 MB download. Finally, Apple posted Security Update 2002-09-20, which replaces the Terminal application for an undisclosed reason; the download is 680K. [JLC]


PowerMate 1.5 Released -- Griffin Technology has released PowerMate 1.5, an update to the software running its eerily popular $45 multimedia controller (the "shiny knob" we wrote about in our Macworld Expo San Francisco 2002 superlatives article. New in this version is emulation for Volume Up, Volume Down, and Eject keys; a Global Only setting; and a Long Click user action, as well as a few minor fixes. PowerMate 1.5 is available in versions for both Mac OS 9 and Mac OS X, and is a 3 MB download. [JLC]


DragThing 4.5 Gets Tabbed -- James Thomson's DragThing, the favorite Mac OS X launcher of some of us here at TidBITS, has now been upgraded to version 4.5. Aside from fixing some bugs introduced by Jaguar, this version sports a major new feature: a dock can now live off-screen, with just its tabs visible. When you click or drag into a tab, or use a hot key combination, the full dock slides into view (rather like Mac OS 9's tabbed windows or Sig Software's Drop Drawers X utility; see "Top Mac OS X Utilities: Alternative Controls" in TidBITS-628 for more details on both DragThing and Drop Drawers X). There are also many other small improvements, too numerous to mention here. This upgrade is free for registered owners of DragThing 4, $25 for new users (with a $20 cross-grade offer for owners of other launchers). [MAN]


Hubzilla Meets Macintosh -- Okay, this is just too funny. Charismac Engineering has introduced a 4-port FireWire hub embedded into an 8-inch (20 cm) tall plastic Godzilla toy. The ports are in his scaly back, his eyes are red LEDs, and there's a blue LED in his mouth (the LEDs all light up whenever Hubzilla is connected to your Mac). No drivers are necessary, though an optional power adapter (sold separately) provides external power if needed. Hubzilla costs $75 (which doesn't seem like an unreasonable markup over a boring old FireWire hub), and Charismac is taking pre-orders now. Normally we wouldn't write about a product that wasn't available, but Tony Overbay of Charismac told me the response has been great and he fully expects to sell out of the initial shipment (due to arrive in early November) on pre-orders alone. Hubzilla will remain available, but the second large shipment likely won't be available in time for the holiday shopping frenzy, though it might make it to Macworld Expo in January. Who knows, Charismac might be starting the next big design movement in computer hardware - disguising it as retro toys from yesteryear. [ACE]


Meet Us at O'Reilly Mac OS X Conference; Discount Available

by Adam C. Engst <>

Next week, after celebrating Tonya's birthday on Sunday, I'm jetting off to Santa Clara, CA to speak at and attend the O'Reilly Mac OS X Conference from September 30th through October 3rd. On Wednesday, 02-Oct-O2 at 2:15 PM, I'll be presenting a session called "Mac OS X Report Card" in which I'll grade Apple's performance with respect to different aspects of Mac OS X. For a sneak peak at the talk, read what TidBITS Talk participants think of my grades. Also, in "Automating Mac OS X" on Tuesday, 01-Oct-02 at 10:45 AM, TidBITS Contributing Editor Matt Neuburg will be showing how you can use tools like QuicKeys, BBEdit, and REALbasic along with applications like Eudora, Microsoft Word, and FileMaker Pro to turn your Mac into a mindless automaton (better it than you!).


If you've been looking for a Macintosh conference that's somewhere between Macworld Expo and MacHack in technical depth, this one may be your cup of tea. There are sessions of interest to developers, but also plenty that will intrigue network administrators, technologists, and power users. Along with the usual suspects like Tim O'Reilly, Ted Landau, and David Pogue, a number of TidBITS and TidBITS Talk contributors will be speaking, including Glenn Fleishman, Dori Smith, Rich Siegel, Stuart Cheshire, Cory Doctorow, Gordon Meyer, and Dan Frakes. Along with all the scheduled sessions, a number of us will be hanging out in the evenings for informal discussions and a Birds of a Feather session Wednesday night at 9:00 PM - think of it as TidBITS Talk in real time.


If you have considered attending the conference, but haven't yet signed up, O'Reilly has extended this 35 percent off discount code - macosx02tdbt - to TidBITS readers. Hope to see you there!

StuffIt Deluxe 7 - What's in a Filename?

by Matt Neuburg <>

Perhaps you've never been tight on disk space; and perhaps you've always lived in some remote hermitage with no desire to share files with others. But I doubt it. If I'm right, and if you've been a Mac user for any length of time, then of all the good old workhorse utilities you depend on without even thinking, surely Aladdin's StuffIt is the one you take the most for granted. Archive a file or a folder and presto, it takes up less space on your hard disk and less bandwidth when transmitting it over the Internet. That's why when Mac OS X came out in March of 2001, I was glad to see a Mac OS X-compatible version of StuffIt Expander included in the Utilities folder. There was just one problem: It didn't work.

I exaggerate, of course. It worked pretty well most of the time. But every now and then I'd download an application, expand it with StuffIt Expander, and find the result unusable. Often I'd check back on the Web site to find a second version, compressed in some other way - as a gzipped disk image to be opened and mounted with Disk Copy, for example - because users had found that the StuffIt-compressed version wouldn't work for them.

Like so many other early Mac OS X programs, StuffIt at this time had various shortcomings, but the most glaringly obvious was its inability to deal with long filenames. The restriction on how long the name of a file could be had been lifted from 31 to 255 characters when HFS+ arrived over 4 years ago, and high-level programming APIs to deal with long filenames were provided starting with Mac OS 9. But most users didn't actually encounter long filenames until Mac OS X, where such names could at last be assigned in the Finder and when saving - in appropriately written programs, that is. Some programs, such as Microsoft Office, couldn't (and still can't) deal with long filenames even under Mac OS X.

In the case of StuffIt, the problem was particularly serious, because it turned an archive into a kind of roach motel: long filenames could go in but they couldn't come out. Expanding an archive containing long filenames would change those names into something shorter. That might be annoying by itself, but keep in mind that Mac OS X is full of filenames you can't normally even see. Even if an application's name is short, an application file in Mac OS X is often actually a package (essentially a special folder), and one of the many files inside it might have a long filename. If that name gets munged, the application likely won't work.

In September 2001, Aladdin released StuffIt 6.5, still without support for long filenames. Now, a year later, the problem is at last solved. Aladdin has released StuffIt Deluxe 7.0, boasting a new file format, StuffIt X, which handles long filenames. Various other improvements in the new format include stronger encryption, the capability to include huge amounts of data in an archive, optional redundancy to prevent data loss, and claims of tighter compression.


StuffIt X -- In the past, a new StuffIt file format has not been cause for rejoicing. Readers will doubtless call to mind the StuffIt 5 debacle of early 1999, when a new format that lacked backwards compatibility caused no end of trouble until everyone had finally upgraded. Public faith in Aladdin was seriously undermined, and Aladdin knew it. With this release, though, Aladdin has taken steps to redeem itself through what seems to me a sensible approach. The new format isn't compatible with the old, and doesn't try to be, but you can easily tell the formats apart: archives in the new format are distinguished by the ".sitx" suffix. Meanwhile, StuffIt can still unstuff and (more important) archive to the old ".sit" format, resulting in complete and readily accessible backwards compatibility. If you don't want to use the new format, you don't have to. Of course, if your archive involves long filenames, you do have to. Although current and past versions of StuffIt Expander cannot expand StuffIt X archives, the free StuffIt Expander 7 can, and it's available now.


As with StuffIt Deluxe 6.5, StuffIt 7's Finder integration is provided through the Finder contextual menu and the Magic Menu menu icon. My menubar is too full as it is, so I don't even install Magic Menu, but I am tremendously fond of the contextual menu, since it puts StuffIt's functionality just a Control-click (or right-click) away. The contextual menu is thus the main way I stuff and expand things; I almost never fire up the actual StuffIt Deluxe application.

Unfortunately, though, the items of this contextual menu don't provide a choice between archiving to the new or old format; you must remember to set a preference first. The included DropStuff droplet has the same problem; instead of providing two droplets, one to stuff as .sit and one to stuff as .sitx, Aladdin still gives you just one, and you must set its preferences appropriately before dropping anything on it. I find these interface decisions of Aladdin's extremely annoying. The most convenient solution to such difficulties is probably to take advantage of the included StuffIt Express PE application, which lets you make your own droplets, onto which files and folders can later be dropped for archiving to a particular format (StuffIt Express can do much more; if you need to perform the same set of file manipulation tasks on a group of files, it's worth a look). Ironically, you can't save a StuffIt Express drop box with a long filename.

Other features in StuffIt Deluxe 7 include a Drag and Drop window for compressing files, integration with Microsoft Word so you can compress and mail documents from Word 2001 and Word X, full support for Zip archives, support for Microsoft Entourage and Apple's Mail with the Stuff and Mail component, command-line tools for stuffing and unstuffing files, and an ArchiveSearch application for searching within StuffIt and Zip archives.

StuffIt Deluxe 7 costs $80, or $30 to upgrade. Also available is the $50 StuffIt Standard Edition (previously known as StuffIt Lite), which includes DropStuff, DropZip, DropTar, and StuffIt Expander.


Mailsmith and Distributed Filtering, Part 1

by William Porter <>

We've never met, but I know something about you: you're getting more email this year than you did last year, possibly a lot more. If you simply let messages pile up in your incoming and outgoing mailboxes, sooner or later you'll have an organizational nightmare on your hands. The best way to prevent this nightmare (and the best way to deal with the mess if it has already developed) is to define and use email filters. Indeed, after allowing you to receive mail and send mail, helping you organize your mail is the single most useful thing an email client can do, and filtering is the number one tool for the job.

This article is a followup to "Mailsmith 1.5: Lean, Mean Email Machine," my review of Mailsmith in TidBITS-638. In that review, I stated my judgment that Mailsmith's filtering options are more powerful, more flexible, and more varied than those of any other Mac OS email client. Mailsmith's most distinctive feature, called "distributed filtering," is so novel that the editors of TidBITS have given me a chance to say a bit more about the subject, both so people considering Mailsmith come to appreciate what it might offer them, and so those already using Mailsmith can take full advantage of the power at their fingertips.


Distributed Filtering -- You can use, and people do use, Mailsmith's filters in the traditional way, simply sorting incoming messages into the appropriate destination mailboxes. Mailsmith's traditional filters are powerful; perhaps more so than those in any other email program. But Mailsmith also provides a completely different and wholly original way to approach filtering: distributed filtering.

If you use traditional filters, every message, as soon as it hits the incoming mailbox, is examined by each and every filter you have defined. Even if the message happens to meet the test in filter 29, it must usually continue to be tested against filters 30 through 50. When all the filters have had a chance to examine the incoming message, the program determines which tests, if any, have been satisfied, then decides how to process the message, resolving conflicts between filters if necessary. Normally, the result is that the message is sent directly to the mailbox where you want it to end up. Note that, in this scenario, the way your mailboxes are organized has no effect whatsoever upon filtering.

Not so with Mailsmith's distributed filtering, which uses the way your mailboxes are organized as a way of controlling and limiting the application of filters to incoming messages. Incoming messages are greeted initially by the mailboxes at the top level of the hierarchy, starting with the first one in alphabetical order. As soon as a mailbox "recognizes" an incoming message, that is, as soon as a test in one of the filters attached to a mailbox is met, that mailbox lays claim to the message. The message now continues to be examined by any mailboxes inside the one that claimed it; but the message will never be tested by filters attached to mailboxes at the first level of the hierarchy that come alphabetically after the mailbox that claimed it.

How Distributing Filtering Works -- My description above is by necessity a bit abstract, so let's look at a concrete example that shows the power of distributed filters.

Consider the following mailbox hierarchy, based loosely on my own setup. The (incoming) and (trash) mailboxes belong to Mailsmith - in other words, they are created by Mailsmith and cannot be moved, deleted or renamed. I created the other top level mailboxes - clients, lists & subscriptions, and personal - which correspond to the three main server accounts (POP mailboxes) from which I download email.

 lists & subscriptions
   - Mailsmith
      -- Mailsmith / keep
   - FileMaker
      -- FileMaker / keep
   - TidBITS

Let's create filters that will catch messages from the first two server accounts:

 If Server Account Contains "clients"
 [Then] Deposit


 If Server Account Contains "lists"
 [Then] Deposit

Now attach the first filter to the clients mailbox and attach the second filter to the lists & subscriptions mailbox. (Note that my example filters look much like what you will see in the Mailsmith filter definition dialog. I've edited them only slightly to make them easier to understand here.)

When new mail arrives from the lists server account, it will be offered first to the clients mailbox for examination, because "clients" sorts alphabetically before "lists & subscriptions." But the message won't match the criterion in the clients filter, so it will be passed to lists & subscriptions. The filter attached to that mailbox will match the message, so the message will be deposited in lists & subscriptions. The personal mailbox will never see it.

But the message is not home yet. It may be filtered further by the mailboxes inside lists & subscriptions. There is a mailbox named "TidBITS" in there, and let's assume that this filter is attached to it:

 If To Contains "tidbits"
 [Then] Deposit

If our imaginary message happens to meet this test, it will end up deposited in the TidBITS mailbox. Using distributed filters with the "deposit" action, messages percolate through the mailbox hierarchy in a straightforward and efficient way.

Why is this approach better? Setting up distributed filters is concrete. You can visualize the way your filters will work by simply looking at your mailbox list. This makes troubleshooting easier, too. None of my mailboxes have more than one or two filters attached to them; my incoming mailbox has no filters attached to it at all. If mail does not end up where it is supposed to end up, I just observe where it does end up in my folder hierarchy, and climb back up the mailbox tree until I find the branch where things went wrong. This process almost never requires looking at more than one or two filters. In Microsoft Entourage, by contrast, if you have fifty filters and one isn't working, almost any of the other filters could potentially be causing the problem -- not to mention Entourage's mailing list rules and junk mail filters, both of which are located elsewhere in the program.

Filtering to the Max -- So far we've looked only at the basics of distributed filtering. What's most impressive about distributed filtering is not that it does what traditional filters do, just a little better, but rather that distributed filtering takes the whole idea of processing your mail to a new level. Consider the following:

I subscribe to the active and helpful Mailsmith Talk list. A filter initially deposits incoming mail from the list in a mailbox named "Mailsmith." When I find the time to read new messages, their status changes from unread to read automatically. I enjoy reading all the messages (traffic on the list is not so heavy that this is impossible) but I'm interested in saving only a handful each week. So as I read, if I want to keep a message for future reference, I use a simple keystroke I defined to mark the message with a custom label ("keep"). Now, inside my "Mailsmith" mailbox there is a child mailbox named "Mailsmith / keep," to which two filters are attached. Here is the first, named "Archiving."

 If ((Label Is Equal To "keep"
   Or From Contains "")
   Or Answered Is Equal to True)
   And Read is Equal to True  
 [Then] Deposit

I've used parentheses above to show how Mailsmith interprets the criteria. This filter catches messages that meet one of the initial three criteria - I applied the label "keep" to them, they're from me, or I replied to them, - and they have been read.

What happens to the rest of the messages? They are processed by the following simple filter named "Trash."

 If Read Is Equal To True
 [Then] Transfer [to] "(trash)"

This filter simply takes everything that wasn't caught by the first filter and moves it into the trash mailbox.

Note that the alphabetization of the filter names matters here. If the Trash filter got to the messages before the Archiving filter, well, all my read mail would get routed into the trash. I could make the Trash filter safer by adding more tests to it, but I have come to trust this setup completely.

Of course, incoming messages are by definition unread, so these filters never catch new messages. They process messages after they have been read; most filters process messages before they are read. So how are these filters activated? Although I could automate the process by writing a simple AppleScript script that runs, say, every time I launch Mailsmith, I prefer to activate the filters manually, by using Mailsmith's Re-Apply Filters command on selected mailboxes. Messages that had already been filtered once when they arrived are now filtered again, and since their properties have changed, they meet filter tests that they didn't meet originally.

And so all my list traffic - hundreds of messages a day - is processed from cradle to grave, so to speak, by Mailsmith's distributed filters. I don't bother deleting messages one by one. Instead, as I read, I focus on what I want to keep, rather than on what I want to trash. This is far more efficient, since in most cases, I want to keep far fewer messages than I want to delete.

Contextual Filtering -- But wait, distributed filtering is even cooler yet! You can attach the very same filter to many different folders, and its effect will be determined by the context in which it is applied.

All of my list mail is processed in exactly the same way as mail I receive from the Mailsmith Talk list. Mail from the various FileMaker lists I subscribe to is deposited initially in a "FileMaker" mailbox. Inside that mailbox, there is a child mailbox named "FileMaker / keep," to which are attached the same two filters attached to the "Mailsmith / keep" mailbox.

Look back at those two filters and you'll see they test for properties that have nothing to do with whether a message came to the Mailsmith list or the FileMaker list. You can test in Entourage to see if a particular message is in a particular folder and respond accordingly, but that isn't contextual filtering, because the test must be defined within the filter.

Filtering Multiple Accounts -- Distributed filtering works exceptionally well for users like me who have multiple email accounts. It lets me route all mail from one account directly into that account's top-level mailbox, and then filter further using content-based tests specific to the mail I get from that account. The content filtering works especially well for my list traffic, since lists messages always come to the same address and are easy to match in a filter.

Unfortunately, not all of my incoming mail is so cooperative, and some of the uncooperative mail is extremely important. I try to encourage my clients to use a special email address when they write to me, so their mail ends up in a dedicated POP account. I can then snag it with this filter attached to the clients mailbox:

 If Server Account Contains "clients"
 [Then] Deposit

Inside the clients mailbox, I have special mailboxes defined for clients with active projects. Each of these mailboxes has attached to it a filter that catches mail specifically from that client. For example, the mailbox for a client named Not So Big Company, Inc., might look like this:

 If From Contains ""
 [Then] Deposit

But as you might imagine, my clients do not always use the preferred address when they write to me. Sometimes client mail comes to my personal account instead. My solution is simply to attach the client-specific filters both to the top level "clients" mailbox and to the individual client mailboxes inside it. That way, if the first filter doesn't catch the message, the second filter will. Any given mailbox can have multiple filters attached to it.

Is this approach better than simply defining a transfer-action filter and attaching it to the incoming mailbox? I think so. Even when there is a certain amount of redundancy in the way they are applied, distributed filters are still easier to define and troubleshoot, although it would be nice if Mailsmith's filter list could show me to which mailboxes a given filter is currently attached.

Next week, I'll finish up this explanation of Mailsmith's innovative distributed filtering by examining how you can use distributed filtering to manage not just your incoming mail, but your outgoing mail as well. Plus, we'll look at how distributed filtering can help you stem the ever-increasing tide of spam.

Non-profit, non-commercial publications and Web sites may reprint or link to articles if full credit is given. Others please contact us. We do not guarantee accuracy of articles. Caveat lector. Publication, product, and company names may be registered trademarks of their companies. TidBITS ISSN 1090-7017.

Previous Issue | Search TidBITS | TidBITS Home Page | Next Issue