Just like MailMate is an alternative to the macOS Mail app, BusyContacts is an alternative to the macOS Contacts app. One of its popular features is that it can show related emails to the currently selected contact. This used to work with both Mail and MailMate, but currently it only works with MailMate (since the release of macOS Sonoma).

In this post I’ll describe how it works, what might be wrong if it doesn’t work, and I’ll provide a few debug hints to help both you and me to debug any issues in the future — most likely in relation to future macOS updates.

How it works

The MailMate app includes a plugin which enables macOS to parse and index metadata from any .eml files found (these are raw emails in the message/rfc822 format). The metadata can then be searched by other applications such as the BusyContacts, HoudahSpot, and the macOS Finder. The metadata includes email subject, date, received date, author (sender), recipients, and text content.

By default, MailMate does NOT index the .eml files in its own cache. You need to enable the “Indexed for Finder/Spotlight” setting in the General settings pane of MailMate. Technically, this renames an internal folder from Messages.noindex to Messages which implicitly triggers macOS to start indexing the files in the folder.

The indexing performed by the Spotlight plugin is not related to the internal indexing done by MailMate itself (although it naturally shares some code).

(Note that the “Custom location” feature does not need to be enabled. This is only needed if you want emails to show up in the Spotlight search interface. This is an ugly hack, but I haven’t found a better solution — and it doesn’t even seem to always work for me. Searching using the Finder appears to be more stable.)

Why it might not work

The following is a check list in case this feature does not work for you:

• Make sure your copy of BusyContacts is the website version and NOT the AppStore version.
• Go to “System Settings ▸ General ▸ Login Items & Extensions ▸ Spotlight” and click on the ⓘ to see if MailMate is enabled.
• Go to “System Settings ▸ Spotlight ▸ Search Privacy…” to see if anything problematic is disabled.
• Go to “MailMate ▸ Settings… ▸ General” to see if “Indexed for Finder/Spotlight” is enabled.

Debugging tricks

Using a Terminal window, the following commands might be helpful to learn more if something does not work as expected.

Assuming you have located a specific .eml file then you can do the following to explicitly parse it:

mdimport -t -d1 example.eml

In particular, you will get the location of the Spotlight importer used. Switch to -d2 to see the parser results. Use man mdimport to learn more about the command.

Test-import all emails cached by MailMate:

find ~/Library/Application\ Support/MailMate/Messages -iname "*.eml" -print0 | xargs -0 -n1 -I{} mdimport -t -d1 {}

If the emails are located elsewhere then you need to change the search path. The command above is also useful if you need to find a message which makes the Spotlight indexer hang or fail.

The following will force re-indexing of all emails in a specific folder:

mdimport -i ~/Library/Application\ Support/MailMate/Messages

Finally, you can test searching in the Terminal window:

mdfind "kMDItemAuthors == 'Benny Kjær Nielsen'"

Other values to play with are kMDItemAuthorEmailAddresses, kMDItemRecipient, kMDItemRecipientEmailAddresses, kMDItemSubject, kMDItemDisplayName, kMDItemTextContent, and kMDItemContentCreationDate.

Again, use man mdfind and man mdimport to learn more.

I’m back! Or to be more precise, the homepage is back. Almost two years since the previous blog post and more than 4 years since the latest public release. I’ve been very quiet here, but I’ve actually been working on MailMate during all that time — which should be obvious based on the other blog post today about the latest beta and its release notes. For years now, the main focus has been on improving/maintaining MailMate and that is great for existing beta/test users of MailMate, but obviously it’s not great for generating revenue from new users.

The long time between public releases is also related to my personal uncertainty about how to best move forward with developing and monetizing MailMate. I will try to convey some of the thoughts involved further below, but the result is the new license key setup described on the pricing page. You can go directly to that if you don’t care about the “why”.

Also note, I’ve added an End User License Agreement ((EULA)[https://freron.com/eula]) to MailMate (presented on launch whenever it has changed). I’ve done this to more clearly state what users can and cannot expect from MailMate – and just a bit about what I expect from users of MailMate. As many other things in MailMate, it’s a work in progress.

In the new license key setup, a MailMate license key is obtained by starting a subscription ($10 every 3 months). An active subscription means that MailMate will run in its “Paid Mode”. An inactive/cancelled subscription means that MailMate will run in its “Free Mode”. These modes are (almost) identical. Essentially, this means the price of a MailMate license key is now $10, but it is strongly encouraged to continue the subscription and for many users it is, in principle, required.

Why do it this way? First of all, paid upgrades are not a realistic option for me. It requires working on two versions of MailMate at the same time and I’ve clearly proven that I’m not able to do that. The first license key was sold more than 14 years ago and it is still valid!

The past 8 years, some users of MailMate have also been patrons of MailMate. Most of them paying $10 every 3 months — just like the new subscription model. This has never surpassed the revenue from license key sales, but it is the main reason MailMate is still under development.

An option would be to make patronage a strict requirement (explicitly putting MailMate into the subscription software category), but this also has some obstacles. Most importantly, I’ve made promises in the past about free upgrades, in particular to the elusive version 2.0. That might be forgiven, but it wouldn’t feel right to me.

My solution is a somewhat voluntary subscription setup similar to the old patronage option. The details can be found on the pricing page. Essentially, the initial payment is symbolic, but you have to explicitly cancel your subscription to avoid further payments. If you do that, then MailMate will eventually switch into its “Free Mode”. In this mode, a header line is added to every outgoing email revealing the free mode usage to your correspondents. Most of your correspondents will never see this, but it might be enough to nudge some users/businesses to continuously support the development of MailMate.

It’s a huge gamble because I will no longer be selling any $50 license keys, but it’s also an opportunity to redefine what users are paying for. Or more precisely, “emphasize” what users are not paying for. Users support development and maintenance of MailMate. Users are not paying me for providing support by email or any other way. When I do that, it’s a bonus and not part of the deal. It simply has to be like this, because I’ll never get anything done if I spend too much time answering emails. Also, in practice it’s already like this. Users will often wait a long time for a reply and far too often never get one. That said, I don’t mind feedback. This will still be how bugs are fixed and new features are born.

There’s also another issue often on my mind. I’d like users to understand that they are paying for what MailMate is doing for them today (or the past few months) and not for what it might be doing for them tomorrow. This might sound strange, but I simply do not feel that I can give the user any assurances about the future. Most users have at least 1 account with one of the big email providers (Google, Microsoft, Apple) and all of them have a “kill switch” for MailMate. This is not just a theoretical issue although I’ve only had serious problems with Gmail.

Time will tell if the switch to subscriptions is a good or bad idea with respect to increasing revenue. In any case, I’ll have a more steady predictable income making it easier for me to prioritize my time. I might need to do freelance work or get a “real” part time job and if that’s the case then it’s ok. I’ll be fine. Most likely, I’ll also be able to keep MailMate running in the future.

Updated 23 December, 2024: The first version of this post, and the homepage in general, used the term “Support Mode” instead of “Paid Mode”. This change was done for simplicity/clarity – it’s still about supporting the development of MailMate.

It has been a long time since the latest beta release of MailMate, but that changes today. The beta has also had its version number bumped to 2.0 (r6067) — this is both to indicate that it is a major upgrade and because it introduces a new license key model. For more about that, see the other blog post.

This beta is now also the primary download of MailMate available from the main page. It is the 5th and hopefully last beta before updating the latest public release (r5673, September 2020).

All intermediate test release notes since the latest beta release (r5937, January 2023) have been reorganized/rewritten in the release notes of the beta.

For Big Sur (macOS 11.x), Monterey (macOS 12.x), and Ventura (macOS 13.x), it is strongly recommended to use the latest beta release of MailMate, but it should also work for users on macOS 10.12-10.15. Here is a direct link. It can also be fetched via the Software Update preferences pane within MailMate. At the time of writing, it’s revision 5937. See detailed release notes here.

I’ll continue my work on making the beta an official public release and then hopefully I’ll get back to a more stable public release schedule — and maybe even some blog posts. (It’ll still require some work and a lot of it is not related to the application itself.)

As always, thanks to the MailMate patrons. They are the ones keeping MailMate afloat.

I have previously recommended that Big Sur users upgrade to a test release of MailMate since it fixes various Big Sur related issues. Some Big Sur users are also the lucky owners of an M1-based computer (Apple Silicon) and they should know that the latest test releases of MailMate are also so-called universal releases which support both M1-based and Intel-based machines using native code.

Here is a direct link to the latest recommended release for Big Sur. It is also possible to upgrade by holding down ⌥ when clicking “Check Now” in the Software Update preferences pane. At the time of writing, the release number should be r5798.

Update: For both Big Sur and Monterey, it is now recommended to use the latest beta release of MailMate as linked above. It can also be fetched via the Software Update preferences pane within MailMate. At the time of writing, it’s revision 5852. See releases notes here.

The caveats mentioned in the previous blog post are still true, but macOS users are upgrading faster than ever before. More than half of current MailMate users are now on Big Sur and it’s a bit strange recommending a test release for a majority of MailMate users. I’ll be working hard on making it a public release, but there are still a lot of issues left to fix and a lot of changes to document.

Note that the test releases require macOS 10.12 or later (the current public release requires 10.10 or later).

The current public release of MailMate (r5673) mostly works on the latest macOS release (Big Sur). One of the known issues is that printing doesn’t work at all. Apparently, this is used quite a lot by MailMate users (most often to do “Save as PDF” I assume) since I believe I’ve received more feedback on this than any other MailMate issue – ever.

For now, I recommend that Big Sur users upgrade to the latest test release of MailMate. At the time of writing, the latest test release is revision 5757 and it can be fetched by holding down ⌥ when clicking “Check Now” in the Software Update preferences pane of MailMate. Alternatively, here is a direct download link. Update: The link has been changed to fetch the latest recommended test release for Big Sur.

The test release does include other Big Sur related changes, but it also differs from the public release in many other areas. For example, both the message view and the composer window have been almost entirely re-implemented. Note that not all of these changes are 100% complete or even documented and this is why it’s not a public release for all users. Users on earlier macOS releases might want to wait until I’m ready to make it a public release.

Thanks to all users and supporters of MailMate! I’m looking forward to continuing my work on MailMate in 2021.

The short version of this blog post: If you rely on using S/MIME in MailMate then make sure you have updated to version 1.13.2 (or later).

It has been quite a while since MailMate had a public update (December, 2019). This is kind of a good thing, because the reason is that I’ve been working hard on replacing some parts of MailMate which were long overdue for a replacement. Most importantly, I’m working on replacing the part of MailMate used to display emails. Since the first release of MailMate, this has been handled by a single interface element displaying a single HTML document. Originally, this seemed like a good idea, but over the years it became apparent that it’s a horrible idea with all sorts of problems — including security issues. The new message view is going to be both safer and far more flexible, but it’s not ready for a public release yet. When it’s ready I’ll write a blog post about the many ways it works differently from the old one.

The reason I’m releasing an update now is a security problem in version 1.13.1 (and some earlier releases). I strongly recommend all users of S/MIME to update as soon as possible. Now, if you follow security related email news then you might have seen this paper, but it’s actually not the reason for this security update. Nevertheless, I’ll be reviewing the issues described in the paper in a section below.

From my perspective as a developer, there are 2 basic types of security issues. There’s the smart ones where someone cleverly combines email software features to reveal that something that seemed to be safe behavior really isn’t. An advanced email client (like MailMate) is more likely to have such issues than a simple one, but I’m still somewhat embarrassed when I think I should have been more careful when implementing some specific feature. I learn every time and, for example, I’m constantly thinking about security related issues while implementing the new message view. The other type of security issue is what I can only phrase as “Sh*t-for-Brains” issues. That may seem like vulgar language, but nothing less can match the embarrassment felt when discovering such an issue. It’s the result of careless programming and a sad lack of proper testing.

The mailto: paper

As noted above then this paper is not the reason for the MailMate 1.13.2 update, but the paper does highlight some important issues and I’ll use this opportunity to go through them in relation to MailMate.

First of all, the paper does not state the version of MailMate used for the tests and the public release of MailMate does not behave exactly as described in the paper. The paper describes 3 issues labelled A1-A3:

• A1: This one is about S/MIME certificates. By default, MailMate has never auto-added S/MIME certificates to the keychain, but there was a hidden preference to do it (version 1.9.7) and later it also got a GUI setting (version 1.11), but the latter happened after fixing the issue in MailMate. Auto-adding a certificate is, in particular, a problem when a certificate already exists in the keychain since it allows a MITM (Man-In-The-Middle) attack in which an existing certificate can be replaced without the user noticing. Subsequently encrypted emails would then quietly use this certificate.

• A2: This is a MITM attack in which the attacker needs access to the IMAP account of the victim and the attacker needs the victim to click an “evil” mailto: link. The attack takes advantage of any email clients uploading incomplete drafts to the server. MailMate has not (for a very long time) uploaded drafts before the draft has been saved and the composer has been closed. MailMate is still vulnerable to the attack, but in practice the user should have time to realize if the draft contains anything unexpected after clicking an “evil” mailto: link. Nevertheless, version 1.13.2 explicitly ignores OpenPGP content in a mailto: link. In addition to this, MailMate no longer uploads drafts which are signed and/or encrypted. (If you do not want to upload drafts at all then you can explicitly take the Drafts mailbox offline in each of your accounts.)

• A3: This is the worst issue described in the paper, but fortunately MailMate is and never has been vulnerable to this attack. (The attack uses an “evil” mailto: link to attach arbitrary files to a new message.)

The “Sh*it-for-Brains” issue

I cannot share the details of this issue yet (users need time to update), but it’s the kind of issue that makes me think that I have “Sh*t-for-Brains” and maybe it was better if MailMate didn’t support S/MIME and OpenPGP at all (this particular issue only affects S/MIME). Ironically, this issue was introduced while I was working on the A1 issue described above.

If you use S/MIME in MailMate then please update to version 1.13.2 as soon as possible.

A special thank you to Heike Knobbe for making me aware of this issue! The only thing worse than discovering this type of issue in MailMate is not knowing when such an issue exists.

Big Sur

Completely unrelated, this security release also includes a fix which should make MailMate run on macOS Big Sur.

Version 1.13.1 of MailMate is a maintenance release which includes various important fixes for Catalina (macOS 10.15). A detailed list of the changes and fixes since the latest public release can be found in the release notes.

If you are new to MailMate then read more about it on the about page.

Version 1.13 of MailMate adds support for macOS 10.15 (Catalina) and removes support for macOS 10.8 and 10.9. In other words, MailMate now requires macOS 10.10. It is unknown exactly when Apple is going to release macOS Catalina, but it’s likely to be fairly soon.

There are no major new features in this release of MailMate, but there has been some important major internal changes to MailMate in preparation for some future changes/features.

A detailed list of the changes and fixes since the latest public release can be found in the release notes.

If you are new to MailMate then read more about it on the about page. The release of Catalina could be a suitable occasion to try a different kind of email client.

This is the first public release of MailMate with a so-called “hardened runtime”. It is also the first release “notarized” by Apple. In short, this means that this and every future release of MailMate has been scanned by Apple before being released (this includes beta/test releases). Apple documentation currently states they they scan for malicious content and code-signing issues. If you would like to know more about this then you can take a look at the developer documentation.

Once again, the minor version bump “hides” the fact that this release includes a lot of improvements to MailMate. All of the new features, changes, and fixes are listed in the release notes.

Note that the next public release of MailMate will most likely not support macOS 10.8 and 10.9, but this should affect very few users (less than 0.5%).