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 withtypeApplicationBundleID
ortypeApplSignature
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
andosascript
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.