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.
If you are like me then the version number, 1.10, feels a bit weird because it’s not just single digits. That doesn’t make any sense, but it’s actually the only reason that MailMate has been using 1.9.x version numbers since March 2015. It took longer to get from version 1.9 to 1.10 than it took to get from 1.5 to 1.9. Theoretically, this shouldn’t matter much, but in practice small changes of the version number means that updates are going to be considered to be minor updates. Unfortunately, this also means less publicity when updates are released.
You might wonder why I don’t just bump it to 2.0, but I’m saving that for when it really feels like 2.0 to me. That might also not make sense and, who knows, maybe that’ll never happen. Just remember, it’s just numbers.
The following are some of the notable items when comparing 1.10 with the first 1.9.7 release. Some of them were part of a public release which did not involve a version bump at all (r5425). You’ll need to dig into the release notes to get the full story, in particular, if you haven’t tried MailMate since version 1.9.
- New: Improved handling of a spoofed email address in the name part of the “From” header. Also fixed bugs related to mailsploit.
- New: Hidden preference to always launch in an offline state:
- New: Key binding for toggling all accounts offline/online:
- New: Hidden preference for sending without using the
- New: Bundle commands can request attachments (or any other message parts) to be provided as files.
- New: Bundle commands can return attachments to be included in created emails (both new ones and replies).
- New: Bundle commands can return actions in the JSON format.
- New: The primary dock badge counter now looks the same as in other applications.
- New: Hidden preference
MmCommandsIncludeCollapsedMessageswhich changes the behavior when running a command on collapsed message threads. This is likely to become default behavior.
- New: Hidden preference
MmOpenMessageURLInContextto tell MailMate to handle
message:URLs by opening a window with the IMAP mailbox of the message selected.
- Changed: Added script for more easily creating a new bundle (
- Changed: Collapsed thread still shows attachment icon in message list if any attachments exist in the thread.
- Changed: An outlined flag is now shown when a collapsed thread contains one or more flagged messages.
- Changed: Optimized some date related computations (this should make date-based smart mailboxes much faster).
- Changed: Undo/Redo now works for attachments added in the Composer.
- Changed: Added a warning sheet when pasting in the Composer results in attaching one or more files.
- Changed: Disabled dragging attachment file names on High Sierra since I cannot make it work correctly. Drag the icon instead.
- Fixed: Some layout and coloring issues in the mailbox editor (High Sierra).
- Fixed: Group names (from Contacts) in the Composer were forgotten if closing/sending without first hitting return.
- Fixed: Some issues with auto-scrolling the preview related to code/math segments.
- Fixed: Spotlight and the custom location feature now use relative paths. The previous approach would lead to problems if the username of the account was changed.
- Fixed: Some issues with the Spotlight importer and the sharing extension on High Sierra.
MmOpenMessageURLInContextalso works when opening
- Fixed: The sharing extension is now a bit better at handling text input, e.g., when sharing a note in the Notes app. (Only plain text handled for now.)
- Fixed: Enabling/disabling some types of mailbox/search conditions would clear the text field or fill it with some old value.
A few days ago several MailMate users made me aware of the mailsploit.com site. The site describes a type of phishing attack known as email spoofing and it provides some examples which makes numerous email clients1 fail to display the real email address of the sender — as given in the “From:” header of the email.
If you are in a hurry then all you need to know is that MailMate did fail on some of these examples (although for different reasons than other email clients) and that I have fixed it in the latest test release of MailMate. Hold down ⌥ when clicking “Check Now” in the Software Update preferences pane to try it out. You should get revision 5441 or newer. Note that revision 5440 also fixes the issue, but in practice this doesn’t help much in terms of making spoofing harder. More on that below if you have time for some more details.
The technical part of an exploit based on “mailsploit” is described well at the web site. In short, it tricks some email clients into finding the wrong email address within an email address header like “From”. The email client would then display the wrong sender. The definition of “wrong” here is based on RFC5322.
It is important to understand that spoofing a “From” header has always been easy and, in my opinion, it is still easy. One attempt to change this is DMARC and this is where “mailsploit” shows that such an attempt is doomed to fail if email clients are not improved.
After I fixed the “mailsploit” related bugs in MailMate I realized that it didn’t really fix a more basic problem in MailMate. This is because many parts of the interface only display the name part of an address header. The email address is only shown if there is no name part. This makes it easy to spoof a sender like this:
From: "email@example.com" <firstname.lastname@example.org>
You can even make it more believable like this:
From: "Donald Trump <email@example.com>" <firstname.lastname@example.org>
In MailMate, you’ll only see the first part in the message list “From” column, but both are shown in the message view (although not in the compact headers mode). The same is true for both Apple Mail and Gmail (I didn’t check any other email clients). Apple Mail won’t even show you the real address in the message view unless you open a context sensitive menu.
Nothing here is new, but most email client users might not be aware of how little they should trust a “From” header. Bugs or no bugs.
In the most recent test release of MailMate I’ve added the following improvement: Whenever the name part of an address header contains a
@ then it’s replaced with a skull (💀). That should at least make the user aware of simple attempts to spoof an address header.
The reason so many email clients have parser bugs is likely because it’s ridiculously hard to parse an email address header. An entire book could be written on this subject. Once again I’ll emphasize that an email client should be able to parse any email generated by any (buggy) version of any email client/generator ever used. ↩