MailMate 1.9.7 brings a long list of improvements and fixes as documented in the detailed release notes. Here follows a short list of the most notable highlights:
- Improved single message window behavior. It is now “connected” to the main window such that undo/redo behavior is better and features (key bindings) such as “Move to Mailbox…” work as expected.
- The “Apply Rules” menu item is now a menu which allows applying rules to either selected messages or the entire mailbox.
- “Export ▸ Copy to Folder” command which exports
.emlfiles into a folder hierarchy matching the original accounts. Duplicates are automatically avoided and the command can be used as an action in mailbox rules.
- Internal changes to provide an action for bundles which allows changing header values of existing emails. This feature is currently used to implement “Command ▸ MailMate ▸ Change Subject”.
- Email addresses can now be blacklisted such that they are not used for completions in the Composer.
- Low-level, the message list supports coloring and styling lines. This feature is described in more detail here.
- Numerous new hidden preferences for users that like to tinker with the details.
- Manual pages updated to include some of the previously undocumented features.
- Improved behavior for various problematic IMAP servers including Gmail and Exchange IMAP.
- Uses the IMAP
RENAMEcommand when an IMAP mailbox is renamed (also when a hierarchy is involved). This is both more robust and more efficient than before.
- Now doing Gmail “OAuth2” authorization through an external browser.
- Improved composer text view including fixing various display issues.
- Improved autoscroll in the composer preview
- Improved and fixed S/MIME handling which now also allows separate certificates for signing/encrypting.
- Improved behavior for window tabs on Sierra and later macOS versions.
- Fixed various issues on High Sierra.
Note that ScreenCastsOnline is a membership based service, but you can also see the tutorial as part of a free trial period. See more on the preview page.
Alternatively, there is a ScreenCastsOnline monthly magazine available on the iTunes App Store. This also includes a free trial period, allowing you to download this month’s issue, including the MailMate video tutorial. If you like, you can cancel the free trial after downloading this months issue.
A while ago Apple announced that they are going to require that all applications accessing iCloud data (including emails in iCloud email accounts) must do so using a so-called application specific password. This happens a week from now, that is, on June 15.
I’m expecting this to be a surprise for some MailMate users and therefore I’m, preemptively, going to answer what is likely to be frequently asked questions:
Can I still use MailMate for my iCloud account(s)?
In most cases, the answer is yes.
MailMate is rejecting my password, what can I do?
You need to enable two factor authentication and then setup an application specific password for MailMate. Update: The great people at BusyMac made a video which shows how to do this. It’s mostly the same for MailMate.
What if two factor authentication is not available to me?
Sorry, I don’t know. As far as I know Apple has not provided a solution, but we’ll have to see what shows up next Thursday. Maybe some accounts are excluded from the new “rule”. If there is no solution and if your license key is not very old then I’ll refund your purchase.
Why don’t you just do like Apple Mail, it works fine with my iCloud account?
Apple uses an authentication method only available to applications created by Apple. All third party applications are going to require an application specific password if they need to access an iCloud account.
But security is much better now, right?
It’s certainly safer to use two factor authentication when possible, but the current implementation of application specific passwords is a bit of a hack. They are not much better than the main iCloud password since they cannot be limited to access specific parts of iCloud data.
Do you think Apple could have done it differently?
Well, let’s just say I’m sure Apple would have done it differently if the change affected their own applications…
Use “Help ▸ Send Feedback” within MailMate if you have other iCloud related questions or maybe corrections to the above. (I’ll add any frequently asked questions to this blog post.)
As described in the previous blog post, a very dedicated MailMate user, Matt Petrowsky, has created a series of screencasts about how he uses MailMate. Last week I commented on the first two episodes and today I’ll comment on episodes 3 and 4.
Here’s a link to the entire list of screencasts: MailMate: The Killer Email App for Mac OS.
Note that since last week, Matt also created an additional screencast covering a specific new (minor) feature of MailMate.
I don’t really have much to comment on for this one. It might be interesting to know that the red link indicator that Matt mentions is triggered whenever a textually displayed link address does not match the actual page linked to. For example, it would be triggered by HTML like this:
Matt applauds the ability to display multiple messages in the message view, but he also notes that it does not work well for HTML messages. I completely agree with that. Ironically, a fix to this problem would very likely break the ability to select the text of all displayed emails in one go.
Matt mentions Xcode, but it’s not really needed for editing custom key bindings. A plain text editor is fine since the property list files used by MailMate are mostly in a readable and easily editable plain text format. (After using the property list editor distributed with Xcode to save the file then this has likely changed to an XML format.)
Another detail is that Matt disables the default
Gmail key bindings file. He doesn’t really need to do that. He could have put his additions/changes into a file named, e.g.,
Matt and then configured key bindings (in the General preferences pane) with a comma separated list of files like this:
Matt, Gmail. This is not very important, but it would ensure that changes I do to the default Gmail file are not ignored.
If anything, this screencast illustrates that it would be very nice if MailMate had an embedded editor for changing custom key bindings.
Matt also mentions the powerful HTML features of MailMate. Here I’d like to emphasize that even though MailMate can do a lot of things with HTML then most users are still going to experience that MailMate has a very basic plain text composer. The rationale for this can be found in the manual. I’m primarily mentioning this, because it’s likely to be a deal breaker for many trial users of MailMate.
That’s it for today. Thanks again, Matt!
One of the MailMate patrons sent me (and you) a special New Years gift. Matt Petrowsky decided to make a series of screencasts about how he uses MailMate. The screencasts are high quality and they cover a lot of aspects of MailMate. It is, by far, the most detailed general visual introduction available for MailMate.
And here’s the big surprise: He made 13 episodes totalling more than 2 hours of video.
I’m simply amazed by this effort and it is greatly appreciated. Thanks Matt!
I should have shared it a month ago, but I first wanted to look through all of it myself to see if I had any important comments — and then a month passed. Shame on me! I’ve now decided to split this task into smaller subtasks. Today, I’m commenting on the first 2 episodes.
Here’s a link to the entire list of screencasts: MailMate: The Killer Email App for Mac OS.
Update February 10th: Matt created an additional video which can be found here.
Note that MailMate has been updated to revision 5344 (it’s version number is still 1.9.6). See the release notes for the quite long list of details.
Matt previously used the Gmail web interface and this is his starting point. Therefore he didn’t notice that if he had accounts configured in Apple Mail or Thunderbird then MailMate would have automatically triggered “File ▸ Import Accounts…”. It is, by the way, quite a hassle to make this work since there is no standard way to obtain settings from other email clients and Apple, in particular, keeps on changing how they save account settings. This is not a complaint, but it helps explain why this feature tends to be broken on a regular basis.
My favorite quote of the introduction is that “MailMate is an application that you really must configure based on how you work”. That might also be a nice way to say that MailMate has a somewhat steep learning curve.
Matt compares MailMate with the Gmail web interface which also makes this a nice introduction to the differences between webmail and desktop email clients. Desktop email clients use IMAP, POP3, or Exchange to access emails. MailMate only supports IMAP (and Exchange when IMAP access is enabled on the server).
It is clearly described how to enable IMAP access for a Gmail account, but I’m pretty sure this is actually not necessary. I tried to disable IMAP, but I was still able to access my Gmail account from MailMate. I believe this is because the setting is ignored when using OAuth2 to authenticate an account. The OAuth2 setting is also described by Matt and this is certainly recommended for Gmail accounts, because otherwise all kinds of issues may arise. My thoughts on OAuth2 for desktop email clients can be found here.
There’s a very nice description of using multiple email addresses for a single IMAP account. With respect to Gmail you need to be careful though. If Google does not like the “From” address of an email (when using their SMTP server) then it doesn’t reject the email, it just rewrites the “From” header. I cannot find this documented anywhere, but Google describes how to add additional email addresses on this support page.
Some minor comments:
- Never ever disable SSL. This setting only exists for the few users needing it for, e.g., a local IMAP server, but I’ve considered hiding it by default. If you have an email provider which does not support SSL (or does not enforce it) then it’s time to consider an alternative.
- Matt is nice to say that it’s really easy to add an account. Just for the record, I do think it could be a lot easier.
That’s it for now. Thanks again Matt!
To mark the end of 2016 I sent out an email to all those subscribing to be notified about news about MailMate (notice the “Keep Me Posted” text field available on this page). This is the first time I’ve done this even though it’s almost 2 years ago that the first people registered for these emails.
I created the emails using MailMate with the use of some still undocumented and incomplete features. I created a draft in MailMate with some template values and then used a bundle command to create a personalized email for each subscriber in my database. The personalized parts were the recipient address, the month/year of subscribing to the emails, and the optional comment/request registered with the address. The last part was only included if I had a reply/comment to that comment. Yes, some of those replies are coming with almost 2 years of a delay. There are probably better (and certainly faster) ways to create such emails, but it was an interesting learning experience.
I also wrote a private “thank you” email to all of the MailMate patrons in a similar way. If you are a registered user then you can learn more about being a patron using the “MailMate ▸ Registration ▸ Become a MailMate Patron…” menu item.
It was interesting going through all the subscriber comments which were mostly feature requests. In particular, some things were requested more often than others. These could be divided into two groups:
- Requests I really would like to implement/do, but I keep on postponing:
- A “simpler” 1-level threading mode, e.g., grouping all emails belonging to the same thread, optionally based on the subject of the messages.
- Message list with multiline entries (previewing message text).
- Correspondence view (multiple emails in a single message view).
- Documentation for the creation of custom bundles.
- Requests I’m not going to implement:
- A WYSIWYG HTML editor.
- Local (“On My Mac”) mailboxes and/or POP3 support.
- Native Exchange support.
Somewhere in between is variations of “make MailMate prettier”, but that’s subjective and I don’t intentionally make MailMate ugly. I do think it got a little prettier in 2016, but I admit that I’m usually more concerned about the look (and adherence to standards) of the emails that MailMate sends (something which seems to be a bit unorthodox among email client developers).
Finally, there are always requests for MailMate 2.0 and this was my standard answer: “Don’t put too much into version numbers. Version 1.9.6 is more than I originally expected 2.0 to be. Also, MailMate is iteratively updated. Bumping to 2.0 would just mean version 3.0 would be getting closer (which would be a paid upgrade).”
The release notes is always the best resource for figuring out exactly what has changed in MailMate.
Happy New Year!
MailMate 1.9.6 is primarily a maintenance release. Here are the most notable items of the much longer and detailed release notes:
- New: “Edit ▸ Add Link” menu item (⌘K). Inserts Markdown code to create a link based on the current word. Also inserts a URL if it’s on the pasteboard.
- New: URL scheme for doing toolbar-like searches:
- New: “New Message With Attachment” and “Copy Attachment” in the context sensitive menu for an attachment.
- Changed: Generation of the HTML alternative for plain text (non-Markdown) messages is now handled using a dedicated script. For compatibility reasons this uses
<div>. This should resolve various issues when corresponding with Outlook users.
- Changed: Undoing move actions now re-selects messages if they exist in the current mailbox.
- Fixed: Saving a search as a smart mailbox frequently failed.
- Fixed: Various issues with HTML embedding when forwarding HTML messages with attachments.
- Fixed: Issue with the choice of Drafts mailbox (and implicitly SMTP server) when an identity could not be derived and an explicit one had not been configured.
- Fixed: Drag’n’drop emails to the Finder on Sierra.
It’s a minor version bump, but it’s not a minor update. MailMate 1.9.5 is a major update as documented in the detailed release notes. Here follows a short list of the most notable highlights:
- Embed arbitrary HTML when replying/forwarding.
- MailMate icon replaced (designed by Eli Schiff).
- Toolbar icons added (designed by Eli Schiff).
- Style outgoing messages using CSS.
- Code styling using Pygments.
- Math styling using ASCIIMath or TeXMath (converted to MathML which is not supported by all recipient email clients).
- Numerous additions to the Composer preferences pane to control the HTML related features above.
- Fixed various issues with macOS 10.12 (Sierra).
- Support for tags and colored flags in the toolbar.
- “Format ▸ Bold/Italic” menu items which inserts/removes Markdown syntax to emphasize text.
- Network code now uses CFNetwork instead of OpenSSL. This implicitly means proxy support (System Preferences), IPv6 support, and TLS 1.2 support.
- Redesigned headers view.
- Fixed an issue with sleep mode and/or being offline. MailMate failed to send all pending messages in Drafts (until relaunching MailMate).
If you are a happy MailMate user then also note this addition:
- Added “MailMate ▸ Registration ▸ Become a MailMate Patron…” menu item (only enabled for registered users).
This release includes a lot of small improvements and bug fixes. The most interesting changes are various new hidden preferences, including
MmSMTPUTF8Enabled. More information in the manual and in the detailed release notes.
MailMate now supports the OAuth2 authentication method for Gmail (and Outlook) accounts. This is a good thing for MailMate users with Gmail accounts, but I don’t really feel good about it… More about that further below.
How does it work?
A bit simplified, it works like this: Using an embedded web browser in MailMate, the user is sent to a hardcoded Google address (using a secure connection). The user is then asked by Google to allow MailMate to access the emails of the Gmail account. If accepted then MailMate receives a special code. Using this code MailMate can then obtain a so-called access token. This access token is then used when authenticating via IMAP or SMTP. In other words, the real password is never known to1 or used by MailMate itself. It is naturally also not stored by MailMate. An access token expires, but MailMate can obtain a new one when needed without interrupting the user. The access token only provides access to emails and the user can revoke the access at any time on this page. That part is a nice feature of OAuth2.
Note that the above is just one of many ways to implement OAuth2 in a desktop email client — none of them being perfect.
What’s the problem?
The main problem is that OAuth2 requires me to register MailMate with the service provider (Google/Microsoft). If the provider stops supporting other authentication schemes (which is almost true for Google) then the provider has the power to decide which email clients are allowed to access Gmail. I’m probably too old to trust big companies, but it also reminds me of what happened to third party Twitter and (more recently) Instagram clients.
In other words, after implementing OAuth2 I’m now part of the problem. I’ve made it a little bit easier for Google/Microsoft to stop supporting other authentication schemes and if they do that they can hit the kill switch on MailMate whenever they want to. They might even have a good reason to do so since a desktop email client cannot protect its so-called client identity. An evil app can easily pretend to be MailMate when requesting access to an account.
Of course, a niche email client like MailMate doesn’t really matter in the big picture, but it’s not the only email client feeling the pressure to support OAuth2.
What about Apple? Well, iCloud has an authentication scheme similar to OAuth2 (I assume), but it can only be used by Apple’s own email clients. I’m not sure if that is better or worse…
Why support OAuth2?
Google continues to push for the adoption of OAuth2 via the XOAUTH2 protocol. In my opinion, they do that using a lot of FUD as seen in this support article, but that does not mean that OAuth2 is necessarily a bad thing to use. Especially not for something like Google for which a single password provides access to all kinds of services.
And I don’t really have a choice here. When using other authentication methods then Gmail users are often rejected. The exact behavior appears to depend on how long the Google account has existed and whether it has been accessed via IMAP in the past. In particular, I believe new Gmail accounts are rejected by default if not using OAuth2. The best user experience is simply with OAuth2 enabled.
This is what it boils down to: MailMate supports Gmail (and Outlook) and I’ll do whatever I can to make it work well. This already includes working around the highly non-standard behavior of Gmail and the many bugs of Outlook IMAP. I do recommend though that all desktop email client users consider the alternatives.
Since MailMate embeds the web browser itself then this is not strictly true. This also shows that OAuth2 doesn’t provide as much security for desktop applications as it does for web services. ↩