Hide full article
Last week I explained how you can use Mailsmith's distributed filters to manage your incoming mail in flexible and efficient ways. This week I concentrate on outgoing mail, with a few tips on handling mail you do not expect - and may or may not want.
<http://db.tidbits.com/article/06943>
<http://www.barebones.com/products/ mailsmith.html>
Filtering Outgoing Messages -- In most email programs, the mail you send is all lumped together in a single Out box on the assumption that you probably don't want to read something you've written. However, it's often important to go back and discover what you said to someone (did you really tell your client that job would be done by Friday?), or make sure you're not repeating yourself on a mailing list. With every outgoing message stored in one Out box, you must either perform a search or scan the messages by date to find the one you're looking for.
To work around this annoyance, I use Mailsmith to filter my outgoing mail into logical locations. For example, all messages between me and a client - incoming as well as outgoing - are grouped together in one mailbox, making it easy to experience the back-and-forth nature of our correspondence.
On the surface, it would appear that you can't use Mailsmith's distributed filtering to process outgoing messages. It's true that you can't get mail out of the outgoing mailbox using a deposit-action filter, because a move directly from the outgoing mailbox to any user-defined mailbox would be a lateral move, and deposit-action filters don't work this way. They must always drill further down inside a given mailbox. The trick to making this work is to get all your mail out of the outgoing mailbox and into one that contains the other mailboxes - you can do this by defining only one such filter. From that point on, deposit-action distributed filters can kick in.
The test to use for this filter is simple enough:
If Sent Is equal to True...
Two things to note about this test. First, the special Sent property of messages in Mailsmith applies to only outgoing messages; it fails (or is ignored) when applied to incoming messages. Second, since mail in the outgoing mailbox is filtered only after it has been sent, this test is strictly a formal requirement. You can't define an action without defining a test to trigger it, and this is the one test that all outgoing mail will satisfy.
So where do we transfer these messages? The incoming mailbox would seem like the obvious choice, since all other mailboxes, including the outgoing mailbox, sit logically inside it. But that hierarchy is precisely why the incoming mailbox won't work. Follow along for a minute: You send a message. Once it's on its merry way to the intended addressee, Mailsmith transfers it out of the outgoing mailbox and up to the incoming mailbox, and since the transfer action causes further filtering to be halted, the message just sits there. Later (seconds later, or weeks later) you reapply your filters to this message. It is offered first to the outgoing mailbox, which - you guessed it - kicks it back up to the incoming mailbox. It's like catching a fish that's too small, throwing it upstream, then catching it again, and throwing it back upstream. If you don't want to see that fish any more, you need to throw it in the other direction.
The solution is to create a catch-all mailbox that lives downstream from the outgoing mailbox in the filtering hierarchy and contains all your other user-defined mailboxes. Then, you start filtering everything from there. Accordingly, my folders are set up something like this:
(incoming)
(outgoing)
my mail
- clients
- lists & subscriptions
- personal
The mailbox named "my mail" is one that I created. (I could have named it anything I wanted.) Only three filters are attached to it to catch mail from all of my server accounts. When messages are downloaded, they are moved here first. Nothing is ever left in my incoming mailbox.
This arrangement proves to be very flexible no matter what type of outgoing mail I have. I have outgoing messages to mailing lists deleted, since I know I'll get copies back from the list. I use a single filter for this purpose, with a test that catches outgoing messages to each of the lists I subscribe to:
If To Contains "mailsmith-talk@barebones.com" Or To Contains "bbedit-talk@barebones.com" (etc.)
This filter does not need the "Sent Is equal to True" test. That test was simply a formality to catch outgoing messages that didn't match any more specific tests. Why don't I just test to see what server account is being used for outgoing mail and throw everything sent using the "lists" account to the trash? Because occasionally I write off-list messages to people using that account, and I may want to preserve them.
Outgoing messages not addressed to lists are then processed by the next filter:
If Sent Is equal to True
Transfer (to) "my mail"
This moves everything that is not to a list into the "my mail" mailbox.
From time to time, I manually refilter that mailbox so the appropriate subordinate mailboxes in my hierarchy pull all the outgoing messages into themselves. Doing so insures that messages to my mother end up in the same folder as messages from her.
And the neatest thing is that the same filter processes both incoming and outgoing mail. How is this possible? To use a modification of an example from last week, I use the following filter to catch correspondence from a certain imaginary client:
If (any address) Contains "@notsobig.com" [Then] Deposit
This filter catches not only mail to me from the guys at Not So Big, Inc., but also my mail back to them. The "(any address)" criterion first appeared in Mailsmith 1.5.3. So: one correspondent, one mailbox, one filter. Very efficient.
Are Transfer-Action Filters Obsolete? With the sole exception of the filter used to extract sent mail from the outgoing mailbox, all of the filters I have described use the deposit action, because it's integral to the concept of distributed filtering. If you use the deposit action to pull a message into a folder, you don't have to specify the folder's name, and that means you can use the same filter in many different contexts. Plus, the deposit action does not forestall additional movement of the message the way the transfer filter does. The deposit action - unique to Mailsmith - is so important to distributed filtering that it's easy to think they're one and the same thing.
Nevertheless, the transfer action remains useful, at times even necessary. As I pointed out above, you must use at least one transfer-action filter if you want to filter outgoing mail, since deposit-action filters can't get their hands on outgoing messages any other way.
The essential ideas of distributed filtering are, first, that different filters are attached to different mailboxes and second, that the filters are applied in conformity to the way you organize your mailboxes. Almost every mailbox in my hierarchy has at least one filter attached to it. The one exception is the incoming mailbox, which has absolutely none.
Dealing with Leftovers -- Because I filter the messages I expect so aggressively, almost all of my correspondence with lists, clients, family, and friends ends up in the right place instantly. But not all of it. Five to ten percent of the mail I receive is either (a) welcome but unexpected or (b) extremely unwelcome but increasingly expected - in other words, spam. The odds are heavily weighted in favor of (b), but not heavily enough that I can simply move all unfiltered messages into the trash without perusing them first.
There's not much you can do about the messages in group (a). You can't create filters for messages you don't see coming. A couple weeks ago, I received email from my best friend in high school. I hadn't heard from him in twenty-five years, so I didn't have a filter defined for him. Even some messages you do expect are hard to filter, for example, acknowledgments from online stores where you've just placed an order. These messages land in the "my mail" mailbox and I file them by hand.
And as for group (b) - spam - well, filtering spam turns out to be constant and persnickety battle. I do want to note, however, that the fact that Mailsmith lacks a built-in spam-sniffing process like those in Microsoft Entourage and Apple's Mail does not mean that Mailsmith users are by any means defenseless against spammers. Although traditional filtering techniques work as well on spam as distributed filters, Mailsmith still performs well thanks to its powerful grep pattern matching capabilities. The members of the Mailsmith Talk list love to share spam-catching tests, many of which make use of grep to tease out the subtle patterns that differentiate spam from legitimate messages.
Honestly, though I initially wrote more about filtering spam, over the last few weeks I've stopped using most of my homegrown filters in favor of a new shareware utility for Mac OS X called SpamSieve. Written by developer Michael Tsai, SpamSieve employs Bayesian probability theory to identify junk mail (the first link below explains the theory behind Bayesian filtering). You have to train SpamSieve by feeding it both spam and legitimate messages, but once it has a satisfactory statistical base, you can ask it to start identifying and labeling spam, using Mailsmith's custom labels feature; then you filter the spam wherever you want. I've been using SpamSieve with excellent results - no false positives, and a growing success rate at identifying the mail that I personally regard as spam. And the best thing is that it merely extends Mailsmith's capabilities, so what happens to the spam remains entirely within my control. [We're planning a full review of SpamSieve soon - it currently supports Mailsmith, Entourage, and CTM Development's PowerMail; support for other email clients, including Eudora, is in the works. -Adam]
<http://www.paulgraham.com/spam.html>
<http://www.c-command.com/spamsieve/>
Getting It -- Distributed filtering is so novel that it took me a while to "get it," and I have noticed other people going through a similar evolution on the Mailsmith Talk list. If you don't get distributed filtering, or if for some reason you decide you just don't like it, Mailsmith lets you work entirely with traditional filters, and even in this area, it's more powerful than any of its competitors. But if you stick with distributed filtering for a while, you will get it, and once you do, you won't want to go back.
PayBITS: Did learning about Mailsmith's distributed filtering
save you time? If so, why not drop Will a few bucks via PayPal?
<https://www.paypal.com/xclick/ business=paypal%40polytrope.com>
Read more about PayBITS: <http://www.tidbits.com/paybits/>
