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.
A detailed list of the many changes, fixes, and new features can, as always, be found in the release notes. Most importantly, MailMate 1.12 includes better handling of smart mailbox and searches based on dates. MailMate is (finally) able to do searches relative to the current day, week, month, and year (also minute and hour if anyone should find that useful). Smart mailboxes, for example, can be created which only shows the emails of today instead of the emails of the past 24 hours. For convenience, the “Message is” menu in the conditions editor includes shortcuts to creates searches for messages received “Today/Yesterday/This Week/This Month/This Year”, but all date headers allow any kind of date relative search if something more specific is needed.
Most importantly, the toolbar search field supports a new modifier to do date based searches. The details are in the manual, but here are a few of the examples:
||Received in year 2005|
||Received April 1st 2005|
||Received before April 2005|
||The most recent day 7 (this or previous month)|
||The most recent April 7th (this or previous year)|
||Received on April 7th 2005|
||Received this year|
||Not received within the past 3 days|
||Received 2-5 years ago|
||Received 2005 or 2007 or within the past 2 years|
The search syntax is also available via the “View Search Syntax” menu item in the toolbar search field menu.
It’s a minor version bump, but there’s a lot of changes and fixes — including a few new features. As always, the details can be found in the release notes. In particular, it is now possible to configure any mailbox to show the messages of its submailboxes. Any early macOS Mojave users should also appreciate the many changes done to make MailMate work better in the new macOS dark mode (this is work-in-progress).
You might have read about the EFAIL project today and you might wonder what my thoughts are on the subject. Or more precisely, you want to know whether or not MailMate is affected.
The short answer is that MailMate is affected, but that MailMate 1.11 (released mid March) includes the fixes and workarounds needed. That is, if I didn’t miss something. This doesn’t mean that all email encryption is then safe, because that depends on both the sender and the recipient(s). I should also note that the EFAIL paper only tests MailMate 1.10 (released mid December). As far as I know, test results for MailMate 1.11 or later versions do not exist.
The long answer is on the mailing list since I also wanted to provide an open forum for this subject when/if issues are reported that I might not have fixed.
Two weeks ago MailMate 1.11.1 was released, but it was primarily a maintenance release. MailMate 1.11.2 released today includes some new features. Most of them are related to the Rules pane in the mailbox editor, but there are also other new features and some changes/fixes. As always, the details can be found in the release notes:
- New: Rules can be reordered and dragged to other rule lists. Hold down ⌥ to copy.
- New: Rules can be hierarchical (use drag’n’drop to make subrules or use the new actions menu).
- New: Rules work with cut/copy/paste.
- New: Undo/redo works for rule reordering/dragging/cutting/pasting/deleting.
- New: Actions menu in the rule editor which includes “Duplicate” and “Add Subrule…” menu items.
- New: Boolean setting
includeSubmailboxMessages = 1;can be used by manually editing
Mailboxes.plist. A GUI for this feature is going to be added later.
- New: Hidden preference
- New: Hidden preference
Also note that a new bundle is now available: Brian Reiter added support for using VS Code as an external editor. The other editors supported are Atom, BBEdit, MacVim, Sublime Text, and TextMate. Instructions for using an external editor can be found here.
This is mainly a maintenance release. Details are in the release notes.
The release is particularly interesting for users preferring the original IMAP approach to deleting emails, that is, marking emails as deleted and then expunging them (permanently) at a later time:
- New: Hidden preference
- New: Hidden preference
- New: An Expunge toolbar button (which reuses the trash icon).
- New: Accounts can be given their own
deleteBehavioroverriding the global default.
The MailMate 1.11 release has many new features, improvements, and fixes. As always all the details can be found in the release notes. I’m particularly happy about some non-visible “under the hood” changes which are going to make it easier for me to work on new features and optimizations in the future.
Here follows a short list of the most notable highlights:
- New: The conditions pane (also in rules) now have a “Message is” menu and a “Message is not” menu. These have submenus to easily match the “read” state, (colored) flags, and various other frequently used search conditions. It is not new that these searches can be made, but they should be much easier to do now.
- New: GUI setting for automatically adding trusted S/MIME certificates to the keychain. This includes telling the user when it happens and warning if a certificate already exists for the same email address.
- New: A dedicated “Two Panes” layout with no message preview (see the “View ▸ Layout” menu).
- New: The context sensitive menu of an IMAP account displays the exact storage quota usage and limit. If multiple so-called quota roots exist then they are shown in a submenu. This only works for IMAP servers with QUOTA support as described in RFC2087.
- New: The
MmQuotaWarningLevelhidden preference can be used to control when the used quota percentage is shown for IMAP accounts in the mailbox list itself. The default is 80.0.
- New: Forwarding (as an attachment) is now available as a rule action.
- Changed: Major refactoring of all so-called rule editors (mailboxes pane, conditions and rule actions). This should make it much easier to add features to these in the future.
- Changed: Major refactoring of the internal query system (used by smart mailboxes and many other parts of MailMate). This includes bug fixes and simpler (more robust) code.
- Changed: Improved support for tags in the Composer window (including a toolbar popup button).
- Fixed: Several security related issues.
- And much more…
MailMate has a very flexible plugin-system available via so-called bundles. There’s already a large set of bundles available, for example, for various task managers and text editors, but you can also create your own bundles with your own personal features.
Bundles have existed for MailMate for a long time, but the creation of bundles has been largely undocumented. This changed recently when I created a documentation page for bundles. This should make it easier to create personal bundles, but you are also very welcome to create bundles to be shared with other MailMate users. Companies with multiple MailMate users might also want to create their own company-wide bundles which could, for example, integrate with local issue tracking systems or provide easy creation of standard replies. If there’s something you would like to do which is not possible using bundles then let me know. I’d like to make it even more flexible than it already is.
Here’s a quote from the documentation which is related to the work MailMate has to do to help you avoid having to know anything about how to parse an email:
Parsing emails is really hard. You need to handle MIME parts, encrypted parts, various encodings like quoted-printable, base64,
format=flowed, header encoded words, and various non- or semi-standard formats like
winmail.dat). But much worse, you also have to work around numerous bugs and legacy types of behavior. Ideally, you need to be able to parse any email created by any version of any email client since the early 1970s.
If MailMate only allowed you to get the raw data of an email then it would be very hard to do anything useful and it would be close to impossible to make it robust. Fortunately, MailMate allows you to get the data you need after it has been decoded and after MailMate has worked around all the bugs and legacy stuff of the past.
On a more philosophical note, the main goal of MailMate is to provide input which takes care of as many of the existing email intricacies as possible before handing over data to commands or other parts of the interface. The many problems concerning the conversion of headers and bodies to any kind of canonical data should be handled by MailMate to keep everything else as simple as possible. In other words, canonicalization is to be MailMate’s side of the fence.
Implicitly, this also means that if you have an email which MailMate cannot parse as you would expect it to do so (even if it’s a buggy one) then let me know and I’ll look into yet another workaround.