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.
Completely unrelated, this security release also includes a fix which should make MailMate run on macOS Big Sur.
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%).
Maintenance releases are important, but they are also a bit boring. Here we’ll focus on a small useful change related to 2 existing features you might not already know. They are not enabled in MailMate by default and they are not easily discovered. The first one is the thread arcs view and it can be found in the “View ▸ Layout” menu. The other one is colored messages which is currently a low level hidden preference (it requires some text file tinkering). The small change in this release is that the thread arcs view now draws colored circles for any colored messages.
All other changes and fixes are listed in the release notes
This is a maintenance release of MailMate which includes some important bug fixes. This is likely to be the last update of MailMate in 2018 since I’ll be on an extended vacation ending January 9th. Thanks to all users of MailMate and especially thanks to all of the MailMate patrons. I’m looking forward to continuing my work on MailMate in 2019.
As always, details can be found in the release notes.
Version 1.12.2 is yet another improvement of MailMate, in particular, for Mojave (macOS 10.14), but it also includes a lot of general fixes and improvements. Details can be found in the release notes.
It’s a minor version bump, but there are lots of changes to MailMate in this update. In particular, this release should work much better on Mojave — and it is quite likely that you are on Mojave. It seems MailMate users have upgraded faster than ever before and more than 49% of MailMate users are now on Mojave. This is just 6 weeks after its release. High Sierra (10.13) is down to 35%, Sierra (10.12) at 9%, El Capitan at 5% (10.11) , and the rest (10.6-10.10) is just 2%. Oh, and a few users appear to be on 10.15…
The new dark mode in Mojave has required a lot of work, but I don’t consider this work to be complete yet. Most notable is the out of place looking status bar in the Composer window.
As usual, you can read the detailed release notes, but here are some of the highlights:
- New: Completely reimplemented the mailbox list. This fixes issues on both both Mojave and earlier macOS releases.
- New: Mailboxes status bar updated for Mojave.
- New: Mailboxes status bar now includes a quota level indicator if supported by the currently selected IMAP account.
- New: Hidden preferences for detailed control of the new quota display:
- New: Basic AppleScript support to access the selected messages of the front-most window and getting its header values.
- New: The
mlmt:URL scheme now supports selecting a specific mailbox.
- Changed: Improved the default guesses for IMAP/SMTP hostnames based on the email address provided. This should often make adding new accounts much simpler.
MmDefaultBccHeadernow accepts a dictionary-mapping in order to be more flexible.
- Fixed: Bug which caused MailMate to create a wrong Date header when close to changes in daylight savings time.