AppleScripts for Marking Messages as Read in Mac Mail

At the request of MacSparky, I've put together a few AppleScripts for Mac Mail users, to mark messages as read...

Script 1: Mail • Mark All Inbox Messages Read

tell application "Mail"
     set read status of every message of inbox to true
end tell

Script 2: Mail • Mark All Messages Read

display alert "Please note!" message "This script may take a while if you have a ton of mailboxes. Do you want to continue?" buttons {"Cancel", "Yes"} cancel button "Cancel"

with timeout of  600 seconds
     tell application "Mail"
          set read status of every message of inbox where its read status = false to true
          set read status of every message of every ¬
               mailbox where its read status = false to true
          set read status of every message of every mailbox ¬
               of every account where its read status = false to true
     end tell
end timeout

Script 3: Mail • Mark Selected Mailbox Messages Read

display alert "Please note!" message "This script may take a while if you have a lot of mailboxes selected. Do you want to continue?" buttons {"Cancel", "Yes"} cancel button "Cancel"

set processSubMailboxes to (button returned of (display alert "Would you like to scan all submailboxes too?" message "Again, if you have a lot of selected mailboxes and submailboxes, this may take a while." buttons {"Yes", "No"})) = "Yes"

tell application "Mail"
     tell front message viewer
          set theSelectedMailboxes to selected mailboxes
          repeat with a from 1 to length of theSelectedMailboxes
               set theCurrentMailbox to item a of theSelectedMailboxes
               processMailbox(theCurrentMailbox, processSubMailboxes) of me
          end repeat
     end tell
end tell

on processMailbox(theMailbox, processSubMailboxes)
     tell application "Mail"
          if processSubMailboxes = true then
               set theSubMailboxes to every mailbox of theMailbox
               repeat with a from 1 to length of theSubMailboxes
                    set theCurrentSubMailbox to item a of theSubMailboxes
                    processMailbox(theCurrentSubMailbox, processSubMailboxes) of me
               end repeat
          end if
          set read status of every message of theMailbox to true
     end tell
end processMailbox


You can download these scripts here.

You can quickly and easily run them from the system-wide AppleScript menu.  This menu is not enabled by default.  To enable it and install the scripts...

  1. Launch AppleScript Editor in /Applications/Utilities
  2. Select AppleScript Editor > Preferences from the menu bar
  3. Under General, click the Show Script Menu in the Menu Bar checkbox
  4. Bring Mail to the front
  5. From the script menu, choose Open Scripts Folder > Open Mail Scripts Folder
  6. Copy the scripts into the folder.  They will now be available from the script menu when you're working in Mail



What not to do in Mac Mail

Here's a handy data loss prevention tip.  With a Mail message selected, do not press either of the secret undocumented keyboard shortcuts Option+Control+H or  Command+Option+Control+H.  That is, unless you want your selected message irretrievably deleted.  Not moved to the trash.  Deleted.  Permanently.

Tested in Mac OS X 10.7.3. Bug report filed.

Note: If you're backing your Mac up with Time Machine, as you should be, then you may be able to restore the vaporized message.

Mac OS X Lion: The Missing Manual Details Services, Automator, and AppleScript

From the Acknowledgements page...

"Ben Waldie… did a beautiful job updating the Automator/AppleScript material in Chapter 7"
- David Pogue

"Thank you, David, for the opportunity to contribute to such a complete resource on the world's greatest operating system!"
-Ben Waldie

Looking for a great comprehensive book on Mac OS X, which covers everything including powerful built-in automation tools such as Services, Automator, and AppleScript? Look no further. Get your copy today!

Mac OS X Lion: The Missing Manual
David Pogue

With Lion, Apple has unleashed the most innovative version of Mac OS X yet—and once again, David Pogue brings his humor and expertise to the #1 bestselling Mac book. Mac OS X 10.7 completely transforms the Mac user interface with multi-touch gestures borrowed from the iPhone and iPad, and includes more than 250 brand-new features. This book reveals them all with a wealth of insight and detail--and even does a deep dive into iCloud, Apple's wireless, free syncing service for Macs, PCs, iPhones, and iPads.

  • Perfect for newcomers. Get crystal-clear, jargon-free introduction to the Dock, the Mac OS X folder structure, Safari, Mail, and iCloud.
  • Go in-depth. Learn how use key new features such as full-screen apps, Mission Control, the new Mac App Store, Launchpad, Resume, Auto Save, Versions, AirDrop, and more. Are you even more of a power user? Learn to set up a network, make a Lion flash drive, and even learn the basics of Lion's underlying Unix.

There's something new on practically every page of this new edition, and David Pogue brings his celebrated wit and expertise to every one of them. Apple's brought a new cat to town, and Mac OS X Lion: The Missing Manual is the best way to tame it.

About David Pogue

David Pogue is the personal-technology columnist for the New York Times. Each week, he contributes a print column, an online column and an online video. His daily blog, "Pogue's Posts," is the Times's most popular blog. David is also an Emmy award-winning tech correspondent for CBS News and a frequent guest on NPR's "Morning Edition." His trademark comic tech videos appear each Thursday morning on CNBC. With over 3 million books in print, David is one of the world's bestselling how-to authors. He launched his own series of complete, funny computer books called the Missing Manual series, which now includes 60 titles. David graduated summa cum laude from Yale in 1985, with distinction in Music, and he spent ten years conducting and arranging Broadway musicals in New York. He's been profiled on both "48 Hours" and "60 Minutes."

About Ben Waldie

Ben Waldie is president of Automated Workflows, LLC, a company offering AppleScript, Automator, and workflow consulting services to Mac-based businesses. For years, Ben has developed professional automated solutions for companies such as Abercrombie & Fitch, Adobe Systems, Apple Inc., CNN, Microsoft, NASA, PC World, and Time Magazine. Ben is the author of “Automator for Mac OS X: Visual QuickStart Guide" (Peachpit Press) and “AppleScripting the Finder" (Automated Workflows, LLC), has written content for, Macworld, MacTech,, and more, and is the host of the “Mac Automation Made Simple" video podcast series (Peachpit Press). Ben is also the author of an AppleScript training CD for the Virtual Training Company, and is a frequent presenter at Macworld and other industry events.

Sandboxing a Cocoa-AppleScript (AppleScriptObjC) Application

If you're a Mac developer, then you are probably aware that Apple will soon be requiring all applications submitted to the Mac App Store be sandboxed.  A sandboxed AppleScript-based application is kind of an oxymoron. Sandboxing denotes that an application will run in its own isolated environment, for security reasons.  Meaning that it doesn't have access to other applications on your Mac.  However, this goes against the nature of AppleScript, which is designed as an inter-application scripting language.  By writing AppleScripts, you can intertwine your various applications together to form complex workflows and automate time consuming things you would otherwise need to do manually.

So, how can you, an AppleScript developer, deal with sandboxing and get your app into the Mac App Store?  You can request temporary entitlements (translation: may not be supported in the future) for the apps and processes with which your app interacts.  Here are the general steps, which will vary depending on the actual function of your app:

1. Use Xcode to create your Cocoa-AppleScript app (AppleScriptObjC app)

2. In the Project Navigator, select your project

3. In the Project Editor, select your app's target

4. In the Summary tab, configure the following settings:

click to enlarge

- Enable Entitlements - Select this checkbox to turn entitlements on for your app

- App Sandbox - Select this checkbox to turn sandboxing on for your app

- File System - If you plan to use file/folder user interaction commands, such as "choose file", "choose folder", and "choose file name", then set this dropdown to "Read/Write Access".  Do the same if you plan to use commands such as "open for access" and "write".

5. In the Project Navigator, select the .entitlements file that should have been created automatically

6. Add an entry for "".  If you will have multiple entitlements, set this to be an array. Otherwise, set it to a string.  Add UTI entries for each application your app needs to target. For example, for the Finder, add "". For iTunes, add "". If you don't add a temporary Apple Events entitlement and the necessary UTIs, then your app will produce errors when attempting to target external applications.

click to enlarge

7. If your app will write to a directory in the user's home folder, add an entry for "".  Set this to be an array, and add paths to any folders you will write to, beginning each with a slash. I.e. /Desktop/ represents the user's Desktop.

That should do it.  Build and run your project, and check Xcode's debug console for problems.

Download an example of a sandboxed Cocoa-AppleScript Xcode project here.

Official documentation for sandboxing an app can be found on Apple's developer website.

Note that sandboxing doesn't affect strictly AppleScript applications.  Other applications could potentially be affected, as well, including Automator* and numerous popular third-party applications.  Well, to be fair, these applications could still work.  They just couldn't be submitted to the Mac App Store once Apple's sandboxing requirement goes into effect, at least not without employing temporary entitlements.

For more on the growing controversy regarding sandboxing and inter-application communication, check out:

* In theory, Automator actions contained within a sandboxed application should not need to be sandboxed themselves.  This is because they would technically fall under the scope of the application that loads and runs them - in this case - Automator.  So, their capabilities should be governed by Automator's sandbox, which, due to the nature of Automator, should allow them to run unimpeded.