James Dempsey has updated his tutorial on how to create your own fancy stationery in mail.app for Snow Leopard.

First posted in 2007, he has updated it to make sure that nothing got broken in the last two years.

He walks through the process of finding, opening and modifying an existing mail.app stationery bundle in eleven easy steps.

Sometimes it helps to have things described in more than one way, so check out the tutorials at The Apple Blog , and the tutorial and templates at Technosanity as well.

And don’t forget the “Related Links” below. The plugin does a good job. Sometimes they are actually related!

Speaking of notification utilities, Stefan Schüßler is actively at work updating his popular (and beautiful) mail.appetizer plugin for mail.app.

The most recent development build (150) works with 10.6.4. You can download it from his development snapshot page where you will also find instructions for installing it.

For those not in the know, mail.appetizer makes beautiful notification previews of incoming email, with options to handle the email at the bottom of the preview window:

You can follow Stefan’s progress in releasing new development builds on twitter .

David Buxton at Reliably Broken has written a good explanation of the way Apple Mail treats email in POP and IMAP accounts, contrasting it (at the end) with the way Entourage handles each protocol.

As he notes:

Now when you go to remove an IMAP account Mail.app deletes all the local mailboxes for that IMAP account. This is not a problem, after all those local mailboxes are simple caches; the only reason the client keeps a copy is as a performance optimisation (as noted above).

Now when you remove a POP account Mail.app deletes all messages sent or received via that account, even though there will be no copy of those messages on the server (especially true for sent messages).

Not paying attention to this often has tragic results, as you can read in “The Mail POP Disaster: When it’s gone, it’s gone” and in Apple’s Mail Discussions (passim).

David dislikes this behaviour for POP accounts. He concludes: “This is not useful or intuitive – it is a bad design.” And he is not alone, by any means.

What do you think?

Not normally a huge Apple fan-boi, I actually side with the company on this one.

First, Apple gives you a big, fat warning when you attempt to delete a POP account, telling you quite plainly what will happen next — that this action will delete the settings, mailboxes and messages associated with that account:

Secondly, this behaviour makes sense. When you think of “an email account”, do you think of just the settings, or the mailboxes and email in that account as well? When users want to delete an account, Apple is right to take them at their word, and to delete everything.

Or to put it another way, to what extent are companies like Apple obliged to protect users from themselves? Some of my friends in User Support have strong (maximised) views on this, but may not be completely disinterested.

I might be wrong. I am open to persuasion. It just looks to me like Apple is getting panned for designing a process that actually does what the user wants.

Of course, the real moral of the story is not about design. It is backup, backup, backup!

It’s not Apple’s fault that so few people make them. I remember being appalled to learn during the 2006 WWDC Keynote that “only about four percent of users are utilizing automated software for backing up important files — only a quarter of users back up in any way whatsoever on a regular basis.” (Thanks to MacWorld for a transcript of the event)

Since Leopard, there’s no reason (apart from the performance hit and a few small annoyances) why people aren’t running Time Machine. Or one of the many other excellent backup solutions.

Just make sure that you are backing up up all the Mail files you should be.

Spotlight searching in Apple Mail is pretty good, but what if it could be even better?

Rocketbox is the plugin that delivers that wish — lightning fast, very smart searching, above and beyond what Spotlight can provide.

This plugin offers the ability to filter searches by several clever criteria that work together quickly to find the needle in a haystack.

The main interface shows how it works. An initial search term is further refined by mailbox, account, time range, and whether or not the email is flagged, has been replied to or forwarded. The results can be sorted by time or relevance:

The search term is highlighted in the results preview, making it faster to see if the particular hit is relevant or not.

The search terms themselves can be specified in a large variety of ways, including by boolean operators and by person:

And it’s fast. The developer, Central Atomics, provides a graphic that gives a good sense of the improvement:

It installs itself as a classic mail.app plugin in the Bundles folder of your Mail Directory. So it’s painless to remove either manually or with the uninstaller provided in the disk image.

An option in the View menu allows you to toggle between Rocketbox and Mail’s own search function (especially important for those who use the custom search features in MailTags ). Grey and white candybar stripes in the search box remind you that Rocketbox is installed and active.

Matt Ronge has detailed his plans for the plugin’s future development, including MailTags integration (yeah!), list view, domain searching and more.

He writes in an email:

Right now I’m doing major work on the engine to make way for these enhancements. Beyond that, I have ideas but nothing I want to make concrete yet (I have one big UI change planned, but can’t comment on that yet).

While he is coy about declaring his hand, he assures me that this next major version will be free for those who have bought version 1.0.

Rocketbox is available from Central Atomics web site where you will also find some nifty searchable FAQs .

It costs USD 14.95. Is it worth it? It depends how much your time is worth. I have a lot of email. After using it for a day, I can already see how much time it will save me.

I am about to revise my ancient post on the Top 10 Things every Mail.app user should have. This will be in it.

(Disclosure: I ought to say that Matt was kind enough to provide me with a license so that I could test out the plugin and write this piece. Thanks.)

I’m sorry for the lapse in taste, but I can’t help myself.

This morning at 6.05 am, Hawk Wings served its 5 millionth page to the world.

At least, that’s the total Mint has cranked up since I installed it in July 2006:

So, 3,425 page impressions a day on average, every day for four years. Thanks to everyone who has dropped by, especially to those loyal readers who kept me in their RSS feeds despite repeated long periods of inactivity.

Teary-eyed, as I stand before this milestone, I am grateful to several luminaries in the blogosphere who encouraged me to continue throughout the long stretch when the numbers were not so promising. *sniff*

Thanks too to the aggregators who picked up my posts. Sweet!

Blogging; it’s cheaper than therapy.

P.S. Obviously, this is small beer in the global scheme of things, but it is _my_ beer ;-)

Jumsoft has released a new collection of ten free email stationery templates for mail.app.

Opinions are divided on whether HTML stationery is a good idea, but you will remember from the 2006 WWDC Keynote presentation that Steve Job is a fan. Like he said, “You can drop your own photos in here and move things around. Birthday announcements, dinners, you name it.”

The templates cover a range of possibilities — birthdays, the birth of a boy or girl, party invitations, and so on:

They all contain place-holders for your own photos and text. Creating your own masterpiece is just a few keystrokes away:

The templates are free and easy to install. You can get them from the Downloads section of Apple’s web site.

Somewhere, in recent updates to Safari 5.0 (included in the 10.6.4 update), something went wrong with the way applications pass text to each other.

A post at MacFixIt suggests that the fault lies with WebKit, which is now “using rgb(0,0,0) as the value for the CSS “background-color” property for messages”.

Whatever the cause, emails generated in other apps often arrive in Mail.app with black text on a black background.

Here are some I made earlier: one generated by mailing a to-do from iCal:

Another created by running an applescript over a blog post in Safari:

Suggested workarounds vary in complexity. Some involve dragging iCal appointments to the Desktop and then into Mail, others suggest copying all the blacked-out text, cutting and pasting it into another app like Textedit to turn it into plain text and then pasting it back again.

Unmarked Software, the developer of TextSoap, has even produced a stand-alone Mac OS X Service, FixMailText , as a work around.

In fact, the fix is quite simple. Apple’s technote on the problem points out that all you need to do in most cases is

1. Place the cursor into the body of the email.

2. Press ⇧+⌘+T (Shift + Command + T) to turn it into plain text. Or select “Make Plain Text” from Mail’s Format menu

3. Carry on.

It also suggests a slightly more convoluted workaround for those who need to preserve links embedded in Rich Text:

If you want to preserve links the message might contain:

1. Click in the body of the Mail message
2. Press Command-A to select all
3. Press Command-X to cut
4. Press the Delete key to clear remaining elements
5. Press Option-Shift-Command-V (Paste and Match Style)

This will replace the black-on-black text with text that uses your default Mail font settings.

As others have said, a technote from Apple on the problem is as close as one will get to acknowledgement that something is wrong.

Hopefully a proper fix is not far away.

UPDATE: 6 July 2010 Mail Attachment Iconizer, a mail plugin that is also afflicted with this bug has been updated with a release (2.1.10) that resolves the problem. [ via MacFixIt }apple mail, safari, webkit, mail.app, apple mail bugs, ical, applescript