Hey, I sped up Apple Mail Rules

When the Hey email software/service came out last summer, I had two instant negative reactions:

  1. A proprietary layer on top of an open system? No, thank you.
  2. The headline feature is screening email? Like I did with procmail back in the 90s? For $99? No, thank you.

Since then, a lot has been written about Hey.1 It’s certainly more than just message screening, but very little about it is compelling to me. I’m lucky in that email has never been a big burden to me.

But it did get me thinking about procmail and Rules, which is the Apple Mail equivalent. Making new rules and extending old ones is easy, but it isn’t fast. Too much clicking and selecting and typing.

A particular type of spam inspired me to figure out an easier way to use Rules. It’s mail that starts like this:

Hi, Dr. Drang!

I just read your great article on . We here at [whatever.com] are experts on [topic I don’t care about] and would love to write new articles for your site. Please get in touch…

What bothers me about these is not just the obvious insincerity, it’s the persistence of these bastards. Because if I don’t answer (which, of course, I never do), they’re back a week or two later, “checking in” to see what I think. And a week or two after that, they’re back again because maybe I’m not the right person for them to have contacted, and maybe I could pass their email on to someone else in the massive Leancrew empire.

For some reason, marking the first message as spam doesn’t prevent the later ones from appearing in my inbox. The only guaranteed way to block the followup emails from these pests is to make a Mail Rule for them. Like this:

Apple Mail Rules tab

Persistent Spam rule

But this is where my impatience and the fiddliness of Rules got in the way. I wanted to rid myself of this kind of email, but the click-click-click of adding a new sender to a rule like this took too long. The one thing that was definitely appealing about Hey was the speed with which you could block senders.

So I started thinking about how to automate Mail to simulate the ease of blocking senders with Hey. Because the various steps of adding a rule condition were in my head, I built a Keyboard Maestro macro that simulated all those steps:

Persistent Spam Keyboard Maestro macro

I’ve been using this macro for several months now, and it’s been quite reliable, but as I was writing this post, I began to have doubts. Could this be done better in AppleScript? Yes, and it was really easy:

applescript:
 1:  tell application "Mail"
 2:    -- Start by getting the sender's address and the message's account
 3:    set selectedMsgs to selected messages of first message viewer
 4:    set thisMsg to first item of selectedMsgs
 5:    set acct to account of mailbox of thisMsg
 6:    set spamAddr to extract address from sender of thisMsg
 7:    get acct
 8:    
 9:    -- Add that address to a new condition of the rule
10:    set psRule to rule "Persistent Spam"
11:    tell psRule
12:      set newCondition to make new rule condition at beginning of rule conditions
13:      tell newCondition
14:        set rule type to from header
15:        set qualifier to equal to value
16:        set expression to spamAddr
17:      end tell
18:    end tell
19:    
20:    -- Delete the message
21:    set mailbox of thisMsg to mailbox "Trash" of acct
22:    
23:  end tell

The most complicated part of this script is the center section in Lines 9–18. But even that’s pretty simple. It adds a new condition to the Persistent Spam rule and then sets the parameters for that rule. Boom.

I disabled the old Keyboard Maestro macro and created a new one: a single step that runs this AppleScript. Unlike the old macro, it runs instantaneously—no windows appearing and disappearing, no pauses.

I’m not sorry about the time I spent making the complicated Keyboard Maestro macro. It got me thinking about the logic of building and modifying a Mail Rule, and I probably wouldn’t have found the AppleScript commands for rules as easy to understand as I did if I hadn’t had that experience. I am embarrassed for falling into the most common automation trap: having the computer mimic what a person would do instead of working directly on the problem. But it’s not the first time I’ve made that mistake, and I’m sure it won’t be the last.

Regardless of how I got here, I now have a fast and simple way to do the one aspect of Hey I envied its users for.


  1. Some of it was even about Hey itself, instead of its developers