Recipe for Trouble: OS X 10.8.2, MailMate, and SpamSieve

The Problem

Since Apple released the 10.8.2 update for Mountain Lion I have received several reports about MailMate being slow and unable to detect spam. The problem turns out to be that the AppleScript communication between MailMate and SpamSieve breaks down. Each request sent by MailMate to SpamSieve hangs for 2 minutes before failing with a timeout error. This happens for every incoming message. See further below for more technical details and a bit of insight into the detective work some times needed in the software development process.

The Solution

If you think you have this problem with MailMate/SpamSieve then you should fetch the current test version of MailMate by holding down ⌥ when clicking “Check Now” in the Software Update preferences pane of MailMate (note that, in general, test versions are not always stable versions of MailMate and they may include incomplete features).

If you have a Mac App Store license then you cannot update to a test version. Instead you should contact me directly.

You can also temporarily fix the problem by killing a process named appleeventsd. You can find and kill it in the Activity Monitor or you can paste the following in a Terminal window (requires a password):

sudo killall -KILL appleeventsd

The Technical Details

The time line of an investigation of this problem can be seen in this ticket. In short, Michael Tsai (SpamSieve developer) joined the discussion and we found a workaround involving a different approach to the AppleScript communication between MailMate and SpamSieve. But a much better understanding of the problem and a better workaround came about when Michael was contacted by Brian Webster. You can read about Brian’s findings here.

This is what is currently “known” about the problem:

  • The problem is related to the OS X 10.8.2 update.
  • The problem is related to the use of the AESendMessage/AESend functions used with typeApplicationBundleID or typeApplSignature for the target type.
  • Using typeKernelProcessID for the target type still works (thanks goes to Brian Webster for this crucial fact). This is what is used for the workaround in MailMate.
  • NSAppleScript and osascript are not affected by the problem.
  • Killing the appleeventsd daemon fixes the problem temporarily (Antonin Hildebrand discovered this fact).

The above indicates that the problem is likely to be some kind of stale cache used by appleeventsd for mapping bundle ids and 4-letter application signatures to process ids. It also indicates that triggering this problem involves relaunching the target application (in order to give it a new process id). This has been confirmed by a user (Torsten Grust) in the context of MailMate/SpamSieve.

Thanks to everyone who helped track down this problem. Note that I am still not able to reproduce the problem myself which means that feedback on the solutions above is still appreciated.

Post a comment.

The Press

Macworld wrote:
  • MailMate’s here to help you bend your email to your will, to tame the chaos of even the most cluttered and sprawling account. And MailMate doesn’t mess around.
  • But MailMate’s true, jaw-dropping power lies in its ability to search and filter messages via Smart Mailboxes.

The Users

Crowd Funding Campaign