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%).

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: MmShowQuotaLevelIndicator, MmQuotaWarningLevel, MmQuotaCriticalLevel.
• 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.
• Changed: MmDefaultBccHeader now 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:

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 MmAutomaticallyExpandThreadsEnabled (experimental).
• New: Hidden preference MmAutomaticallyExpandOnlyWhenCounted (experimental).

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 MmDeleteBehavior: moveToDeletedMessages, markAsDeleted, expunge, archive.
• New: Hidden preference MmAutomaticExpungeBehavior: mailboxSwitch, never.
• New: An Expunge toolbar button (which reuses the trash icon).
• New: Accounts can be given their own deleteBehavior overriding 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 MmQuotaWarningLevel hidden 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 tnef (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: MmInitialOfflineStateEnabled
• New: Key binding for toggling all accounts offline/online: toggleOnlineStateOfAllAccounts:
• New: Hidden preference for sending without using the X-Mailer header: MmStripXMailerBeforeSending
• 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 MmCommandsIncludeCollapsedMessages which changes the behavior when running a command on collapsed message threads. This is likely to become default behavior.
• New: Hidden preference MmOpenMessageURLInContext to 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 (SharedSupport/bin/create_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.
• Fixed: MmOpenMessageURLInContext also works when opening .eml files.
• 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 clients¹ 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: "potus@whitehouse.gov" <evil@example.com>

You can even make it more believable like this:

From: "Donald Trump <potus@whitehouse.gov>" <evil@example.com>

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.

I recently wrote about a frustrating issue with Yahoo IMAP and I was quite surprised (and a bit embarrassed) when I actually got into contact with someone at Yahoo working on fixing it. Now I’m thinking it would be nice if I could get the same result if I write about another frustrating server issue.

But first I’ll have to quote myself from my previous blog post:

All software is buggy and it’s always a bit hypocritical for a developer to complain about bugs. I’m certainly aware that MailMate has many bugs and some of them are incredibly frustrating for some users. For those users it might be a comfort to know that an email client developer has to deal with one of the most frustrating types of bugs: IMAP server bugs.

The target of this rant is Exchange IMAP which has an annoying habit of rejecting uploaded messages without any information about why it happens. In the past I’ve seen this happen for emails with one or more very long lines. In that case, the error message is:

BAD Command Error. 10

I was able to work around it by detecting this particular response and then re-encoding its MIME parts before retrying the upload. The subject of this blog post is a slightly different error message:

BAD Command Argument Error. 11

A MailMate user reported this issue when trying to upload a sent message (created by MailMate). This message included another message forwarded as an attachment. Fortunately, I was able to reproduce the issue with an outlook.com account and I could start debugging. I simplified the message step by step and in the end it appears to require two things to happen:

• A message including a message forwarded as an attachment.
• The attachment includes an encoded header line which Exchange cannot parse.

Here’s an example:

From: Test@example.com
To: Test@example.com
Subject: Test message pushing Exchange to fail
Message-ID: <54259AAF-8FE0-44A4-8DCE-032F020A7C13@example.com>
Content-Type: multipart/mixed; boundary="=_MailMate_1C634E1D-F7F7-4E44-BD38-1E95A63DE5B6_="


--=_MailMate_1C634E1D-F7F7-4E44-BD38-1E95A63DE5B6_=
Content-Type: message/rfc822

Subject: =?UNKNOWN?Q?n=E9cessaire?=

Body of forwarded message.

--=_MailMate_1C634E1D-F7F7-4E44-BD38-1E95A63DE5B6_=--

The UNKNOWN charset used in the “Subject” line doesn’t make sense and was probably introduced or caused by some other buggy email software. It’s a minor issue, but apparently it’s a major issue for the Exchange IMAP implementation.

After spending a lot of time to track down the source of the problem, I now have to figure out how to work around it. You might wonder why a workaround is needed at all since the bug is clearly in the server implementation, but if I chose this path for every IMAP server bug encountered then many MailMate users would quickly consider MailMate to be unstable. Most users just need things to work. Furthermore, users might not have the option of switching to a more robust IMAP server.

The workaround I chose was to let MailMate re-encode all header lines in all MIME parts of the email before retrying the upload. This only happens for the uploaded copy. The worst part of this is that the user is not notified about the problem. (Some day I would like to add a feature which allows the user to review all the workarounds taking place while using MailMate.)

Now, I’d like to quote my previous blog post again:

An IMAP server bug can often be characterized as follows:

• It only affects IMAP email clients and not a webmail client or some proprietary email client for the IMAP service involved.
• It makes the email client seem like it has a bug.
• There’s no way to report it.
• It is probably not hard to fix.
• It is never fixed.

Yahoo proved me wrong on the above. It’ll be interesting to see if Microsoft can do the same. In practice (for me), it doesn’t matter much because Microsoft is not in control of all installations of Exchange IMAP. Even if a bug is fixed then servers with the bug will exist many years into the future.

Some times I like to state that an email client must be able to handle any email ever generated by any kind of email software at any time of the history of emails. I should probably add that it should also be able to work around any bug that exists in any live IMAP server.

Oh, and I promise that my next blog post won’t be rant :)

All software is buggy and it’s always a bit hypocritical for a developer to complain about bugs. I’m certainly aware that MailMate has many bugs and some of them are incredibly frustrating for some users. For those users it might be a comfort to know that an email client developer has to deal with one of the most frustrating types of bugs: IMAP server bugs.

An IMAP server bug can often be characterized as follows:

• It only affects IMAP email clients and not a webmail client or some proprietary email client for the IMAP service involved.
• It makes the email client seem like it has a bug.
• There’s no way to report it.
• It is probably not hard to fix.
• It is never fixed.

(Even in the rare case of a fix, old versions of the IMAP server continue to be used.)

Most users (understandably) see no difference between email client bugs and server bugs. The email client takes the blame. Whatever the problem is I must either fix a bug in MailMate or add some workaround for an IMAP server bug.

UPDATE: Well, apparently I owe Yahoo an apology. I reached out to Yahoo on Twitter and I was then contacted by email. Apparently, they fixed some issues last week which they believe fixes the UID mismatch issues described below. I really hope the issue is fixed, but I remain a bit skeptical. The first time a MailMate user reported a UID mismatch issue for Yahoo was more than 2 years ago. But for now: I’m really sorry, Yahoo, for believing that this issue would never be fixed.

Some IMAP servers are worse than others. Today, I’m writing about Yahoo IMAP, but it could just as well be Exchange or some other buggy IMAP implementation. In any case, if you are searching for a new IMAP server then please consider some of the alternatives.

Yahoo IMAP has many problems. The inbox is incorrectly named Inbox instead of INBOX as required by the RFC, it can more or less randomly reject authentication making it seem like the password is incorrect, and it can suddenly become unavailable (not a bug but a stability issue) with various types of temporary errors. Most of these problems are handled gracefully by MailMate. The bug driving me mad is what is best described as “schizophrenic emails” — emails with more than 1 identity.

An IMAP mailbox has two different ways of enumerating emails. There’s a sequential way where emails are numbered 1 to N if the mailbox contains N messages and there’s so-called UIDs which stay the same even when messages are added or removed from the mailbox. The latter is very important for email clients caching emails (which means almost all desktop email clients).

Unfortunately, Yahoo IMAP has a bug where it messes up the mapping between sequence numbers and UIDs. The following is the relevant parts of an example of this happening:

06:32:51 C: C17 SELECT Trash
06:32:51 S: * 1381 EXISTS
...
06:32:51 S: C17 OK [READ-WRITE] SELECT completed; now in selected state
...
06:32:53 C: C21 UID FETCH 1:211045 (UID FLAGS)
06:33:07 S: * 1 FETCH (FLAGS ($Junk) UID 209612)
...
06:33:07 S: * 8 FETCH (FLAGS (\Seen) UID 209619)
06:33:07 S: * 9 FETCH (FLAGS (\Seen $NotJunk) UID 209665)
06:33:07 S: * 10 FETCH (FLAGS (\Seen $NotJunk) UID 209666)
06:33:07 S: * 11 FETCH (FLAGS (\Seen $NotJunk) UID 209667)
06:33:07 S: * 12 FETCH (FLAGS (\Seen $NotJunk) UID 209668)
06:33:07 S: * 13 FETCH (FLAGS (\Seen $NotJunk) UID 209669)
...
06:33:07 S: C21 OK UID FETCH completed

At this point everything is fine. In particular, note that message number 12 has UID 209668.

...
06:33:15 C: G23 UID FETCH 209612:209666 (UID BODY.PEEK[] RFC822.SIZE)
06:33:16 S: * 12 FETCH (UID 209665 RFC822.SIZE 3848 BODY[] {3869}
...
06:33:16 Error: Detected mismatch in UIDs received from server (previous value: 209668, new value: 209665).
06:33:16 Ignored mismatch to work around Yahoo server bug. Using previous UID value.

What? Message number 12 has UID 209665. We can even see that this UID belongs to message number 9. MailMate detects the issue and, as an experimental workaround, MailMate ignores the change and keeps the old UID. Yes, this is a bit risky.

06:33:16 S: * 13 FETCH (UID 209666 RFC822.SIZE 67708 BODY[] {67731}
...
06:33:17 Error: Detected mismatch in UIDs received from server (previous value: 209669, new value: 209666).
06:33:17 Ignored mismatch to work around Yahoo server bug. Using previous UID value.
06:33:17 S: G23 NO [UNAVAILABLE] UID FETCH Server error while fetching messages
...

It happens again, message 13 is now mapped to UID 209666 which actually belongs to message 10. MailMate ignores it again, but now the server bails completely with an UNAVAILABLE error. I suspect that something crashed…

At this point I’m thinking that the server might have forgotten to tell MailMate about some deleted messages and in that case the experimental workaround (ignoring the UID mismatch) would be a bad idea, but this is not the case. The retry attempt shortly after reveals that the UIDs are back to “normal”.

06:33:21 S: * 9 FETCH (UID 209665)
...
06:33:21 S: * 13 FETCH (UID 209669)

And while we’re at it. Here’s another example of weird Yahoo IMAP behavior:

06:33:00 C: G3 SELECT "Bulk Mail"
...
06:33:00 S: G3 OK [READ-WRITE] SELECT completed; now in selected state
06:33:00 C: G5 UID FETCH 1:* (UID)
06:33:00 S: * 1 FETCH (UID 209538)
06:33:00 S: * 2 FETCH (UID 209567)
06:33:00 S: * 3 FETCH (UID 209568)
06:33:00 S: * 4 FETCH (UID 209569)
06:33:00 S: * 5 FETCH (UID 209570)
06:33:00 S: * 6 FETCH (UID 209571)
06:33:00 S: G5 OK UID FETCH completed
...
06:33:01 C: G7 UID FETCH 1:209571 (UID FLAGS)
06:33:01 S: * 1 FETCH (FLAGS ($Junk) UID 209538)
06:33:01 S: * 2 FETCH (FLAGS ($Junk) UID 209567)
06:33:01 S: * 3 FETCH (FLAGS ($Junk) UID 209568)
06:33:01 S: * 4 FETCH (FLAGS ($Junk) UID 209569)
06:33:01 S: * 5 FETCH (FLAGS ($Junk) UID 209570)
06:33:01 S: G7 OK UID FETCH completed
06:33:01 C: G8 UID FETCH 209538 (UID BODY.PEEK[] RFC822.SIZE)
06:33:01 S: G8 OK UID FETCH completed

Can you spot the problem? The server claims the existence of 5 messages. When MailMate asks for the data of the first one then nothing is returned. Sigh…

I’ve had various variations of this bug reported by several users and I’m pretty tired of it. Some of these reports also indicate that it’s not always safe to ignore the sudden UID changes (I’ve attempted to improve the workaround to make this less likely to be a problem). In order to better handle future “bug” reports, I’ve written a wiki page such that I can quickly provide users with more information.

I would of course very much like to report these issues to Yahoo, but I cannot find any way to do that. The closest I’ve found is this help page which states:

What if my account is working outside of the app? This means there’s something wrong with the app. You can download the Yahoo Mail app from the app store and use that instead […]

I guess that means I shouldn’t feel bad about recommending users to find a different IMAP provider.

Yahoo, please prove me wrong and fix these issues. Consider this my bug report since I couldn’t find anywhere else to put it.

(I repeat, MailMate is also buggy and I do see the double standard in play here. That said, I’m pretty sure Yahoo is not spending any time implementing workarounds for MailMate bugs…)

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 .eml files 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 RENAME command 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.

ScreenCastsOnline has published a tutorial for MailMate. It’s 45 minutes covering the basics of MailMate. Thanks to Mike Schmitz for taking the time to create it.

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.

Episode 3: Working with Messages (8:12)

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:

<a href="http://example.com/potentially_bad_hidden_link">http://example.com/the_displayed_link</a>

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.

Episode 4: Key Bindings (9:31)

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.

As Matt mentions, the main resource for key bindings is the manual page. I’d like to also emphasize the list of available key binding selectors.

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.

Episode 1: Introduction (7:39)

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.

Episode 2: Account Setup (7:29)

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.

You can see the raw message as I wrote it here and you can see a generated one here. It’s mainly a review of what is new in MailMate in 2016.

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: mlmt:quicksearch?string=s%20mlmt
• New: “New Message With Attachment” and “Copy Attachment” in the context sensitive menu for an attachment.
• New: MmSMTPFixedHostname
• Changed: Generation of the HTML alternative for plain text (non-Markdown) messages is now handled using a dedicated script. For compatibility reasons this uses whitespace:normal and <p> instead of <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 MmSMTPAlternativeEnabled and 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 to¹ 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.

This release is mainly focused on bug fixes and stability issues. The most notable new features are manual ordering of IMAP accounts/mailboxes and OAuth2 support for Gmail and Outlook accounts. Note that OAuth2 is enabled by default. If you have any issues then please report them and note that you can disable OAuth2 in the IMAP account settings. I’ll write more about OAuth2 and why it’s enabled by default in a separate blog post.

Note: This blog post is relevant for users of any third party email client on OS X.

A few days ago I was contacted by a MailMate user reporting that he could not switch default email client using the popup provided in the General preferences pane of MailMate. It seemed to work, but after a short while the setting was reverted to its previous state. My initial thought was that this had to be some kind of local issue with Launch Services. This is the service taking care of binding file types and URL schemes to applications. In particular, it can bind the mailto: URL scheme to an application and this is what happens when switching default email client.

I was a bit surprised when I realized it didn’t work for me either. We quickly established that it was a problem on El Capitan only and that it didn’t matter if Apple Mail or MailMate was used to switch default email client. Further experimentation revealed that the problem was most likely not related to MailMate at all.

It still seemed a bit unlikely to be a problem affecting all El Capitan users since googling for the problem didn’t reveal much. There had to be some common denominator. Therefore I searched for users not having this issue via the MailMate mailing list and via Twitter. But I didn’t find anyone.

I currently believe it is a general issue on El Capitan. I’m not quite sure why it hasn’t gotten more attention, but it’s probably a combination of the following:

• The delayed reversion to the previously default email client.
• Most often the switch reverts, but it appears that some times the switch does stick.
• The first switch (clean install or after resetting the Launch Services database) seems to always work.

So, a workaround does appear to be to reset Launch Services, but it’s a bad workaround since it resets all of your custom file type and URL scheme bindings. I don’t currently know any other workarounds other than to keep on trying until it sticks. A special case is if you are trying to switch back to Apple Mail. In that case it also works to uninstall your current email client.

I’ve reported the issue to Apple (rdar://23123392) and hopefully it’ll be fixed soon. I won’t do more than that unless someone comes up with a workaround which I can use to make the popup in the MailMate preferences pane work reliably. If you want to experiment then it might be useful to use the command line hack I created for my mailing list post.

Update November 23rd: A user reports that the workaround described here worked for him. I haven’t tested it myself.

With the forthcoming release of OS X 10.11 (El Capitan) it is also a good time for a MailMate update.

This release is compatible with El Capitan, but it also includes numerous other new features, changes, and fixes. As usual, all the details can be found in the release notes.

One new feature deserves extra attention. MailMate now includes a Spotlight importer for .eml files (standard email format). This feature is enabled in the General preferences pane and it allows searching for MailMate emails using the Spotlight interface. It also allows searching emails stored elsewhere which means that a local archive of emails (stored in the .eml format) is now also searchable if MailMate is installed. (Don’t tell anyone, but this works even if MailMate is not registered.)

Note that the answers provided for frequently asked questions in my previous blog post are still valid.

Update April 2nd: MailMate 1.9.1 has been released with a few important fixes. Most importantly, the new Bundles preferences pane was not available for all users.

As explained in the previous blog post I’ve been working on making MailMate a 64 bit application. This change is now complete and it involved numerous optimizations making MailMate faster while also making it use much less memory.

The migration to 64 bit is far from the only thing I’ve been working on. As always, the release notes are ridiculously long. Note that some of the listed features were also available in earlier releases as experimental 2.0 features enabled in the General preferences pane.

The following are just some of the most important highlights:

• Bundles preferences pane which allows you to enable/disable integration with various applications. Currently, 19 bundles exist providing support for BBEdit, BusyCal, Due, EagleFiler, Evernote, OmniFocus, TextMate, Todoist, and more.
• Rules pane in the mailbox editor for any mailbox.
• Toolbar search field activated using ⌥⌘F. Note the search field menu and its options.
• Correspondent/Identity added as special header transformations. This is, e.g., used for the new “Correspondent” column available for the messages outline.
• Each tag can be assigned an emoji and a new tags column can be used to display them. Note that ⌘⌃+space opens an emoji keyboard on Yosemite.
• Enable composer header fields by holding down ⌥ when hitting Return. For example, hit ⌥↩ to add a “Cc” header when focus is in the “To” header.
• Numerous other new features, changes, and fixes. You really do need to read the release notes to know it all.
• MailMate should now work with even more buggy IMAP servers than it already did. Remember, good alternatives do exist.

Enjoy the new release and rest assured that I’ll continue to work on improving MailMate.

Here are answers to what I expect to be the most frequently asked questions (with a few replays from previous posts):

• Any new graphics in version 1.9?

  Only a few details, but I do expect some improvements for version 2.0. In particular since some of you were so kind to contribute to the somewhat discreet mini crowd funding campaign.

• When is MailMate 2.0 released?

  I don’t know, but it probably matters more to me than to you. I need it for marketing purposes. You need it for the features. The development of MailMate is an open process and you can use the betas if you like (enabled in the Software Update preferences pane). If feeling adventurous, you can even fetch cutting edge test releases by holding down ⌥ when clicking “Check Now”.

• When are you going to support feature X?

  I have no idea, but if you want to be notified about major new releases of MailMate then you can now subscribe. If you do that then you also get a chance to state your “most wanted feature”.

• Are you going out of business soon?

  No.

You might not have noticed this, but MailMate is still a 32 bit application. The main reason for that is not that it is technically hard to switch to 64 bit. The main reason is that memory usage would increase considerably if doing it naively. MailMate indexes a lot of data using data structures with a lot of address pointers. In fact, the first experimental 64 bit build of MailMate used almost twice the memory of the 32 bit build.

It is quite rare that users “complain” about MailMate being a 64 bit app, but there are many reasons that staying 32 bit is not a good idea. One of them is the fact that if MailMate is the only 32 bit app on your system then it uses a lot more memory than you might realize. This is because a 32 bit app triggers the system to load 32 bit system frameworks. On my system, MailMate, Spotify, and SpiderOak are the only 32 bit apps (Google Chrome very recently switched to 64 bit)¹. Having MailMate on that list is becoming a bit of an embarrassment.

Now, you might have noticed the lack of beta/test releases of MailMate in the past month. This is because I’ve been working on a 64 bit release of MailMate. Most of that work has been focused on optimizations regarding both speed and memory. It’s hard to measure this in general, but on my system MailMate now launches 2-3 times faster than the 32 bit release and it uses less memory.

The 64 bit releases are on a separate auto-update system and I’ll keep it that way until I’m relatively sure it’s at least as stable as the latest 32 bit release. You can help me reach that milestone by switching to 64 bit now. Initially, it’ll require a manual install of this download. If needed, you can switch back to the 32 bit release.

Although the 64 bit release primarily features optimizations, it also includes a few new features, changes, and fixes. Here are some of the most interesting:

• New: “Default Account” setting for new messages in the Composer preferences pane.
• New: Completion of email addresses works for any contacts with a company name (and email address).
• New: Added perform command to the AppleScript API. Its argument is a list of strings identical to what would be used to define a custom key binding. The frontmost window of MailMate is the target even if MailMate is not in focus (activated). Example: tell application "MailMate" to perform {"toggleFlag:"}
• New: “Distortion Mode” now also works for HTML messages and attachment descriptions.

If you are new to MailMate then don’t miss the FAQ part of the previous blog post. Related to that, I really appreciate that the (somewhat low-key) mini crowd funding campaign has reached 25% of my initial goal.

The list of changes since version 1.7.2 (r3905) is very long and all the details can be seen in the release notes. Version 1.8 is best described as a major maintenance release including numerous bug fixes, stability improvements, and minor feature enhancements. The following are some of the most interesting new features:

• New: Redirection of a message using “Message ▸ Redirect” (⌥⌘E) or the redirectMessage: key binding. This opens a special composer window which only allows editing a fixed set of headers. MailMate also adds a $Redirected flag to any redirected messages.
• New: Support for using an external editor to write emails (built-in support for TextMate, Sublime Text, and MacVim).
• New: HTML signatures can be configured in the “Signatures” preferences pane. They work in both plain text and Markdown mode. (More details in the manual.)

At the time of writing, Apple has not yet released Yosemite (OS X 10.10), but I do expect this version of MailMate to be compatible.

Here are answers to what I expect to be frequently asked questions (some duplicates from an older post as well):

• Any new graphics in version 1.8?

  No, but it’s funny that you ask. I have just setup a page in the MailMate store to allow users to explicitly contribute to the purpose of making me hire a graphics designer to change that. Read more about that here.

• Is a license key bought in the store today also valid for version 2.x?

  Yes.

• When is MailMate 2.0 released?

  I don’t know, but it probably matters more to me than to you. I need it for marketing purposes. You need it for the features, but the development of MailMate is an open process and you can use new features in the betas/releases of MailMate 1.x by enabling 2.0 features in the General preferences pane. If feeling adventurous, you can even fetch cutting edge test releases by holding down ⌥ when clicking “Check Now” in the Software Update preferences pane.

• What happened to the crowd funding money?

  I still have most of the (post-tax) money and they ensure that I’ll be able to continue working on MailMate full time for at least another 6 months. Probably much more than that, but this depends on the daily sales and I don’t want to make promises I cannot keep.

Thomas Borowski recently did an interview with me and this is now available in the most recent episode of his “Think, Make, Sell” podcast. This is actually the first interview I’ve given about MailMate and it’s also my first podcast appearance. Time will tell if it’s also my last podcast appearance – it turns out I’m the kind of person who cannot listen to myself and therefore I’m not sure exactly what I said in the podcast. If you have any questions related to the interview then you can leave them in the comments of this blog post.

On the subject of questions, I’m frequently answering the following two questions related to MailMate 2.0:

• Is a license key bought in the store today also valid for version 2.x?

  Yes.

• When is MailMate 2.0 released?

  I don’t know, but it probably matters more to me than to you. I need it for marketing purposes. You need it for the features, but the development of MailMate is an open process and you can use new features in the betas/releases of MailMate 1.x by enabling 2.0 features in the General preferences pane. If feeling adventurous, you can even fetch cutting edge test releases by holding down ⌥ when clicking “Check Now” in the Software Update preferences pane. Teaser: The test release from today includes an experimental solution for users having to use HTML signatures due to company policy (which is a problem since MailMate is plain text/Markdown only).

Background

Late October I faced a financial ultimatum. I had to soon start making more money working on MailMate or I would have to stop working on MailMate full time. Before starting to look for other jobs I decided to do a crowd funding experiment primarily aimed at the existing users of MailMate. This was fairly successful since more than $13,000 was pledged, but it was quite a bit less than my (unofficial) estimate of $50,000 needed to be able to work on MailMate in all of 2014.

Indiegogo

Nevertheless, I decided to create a “real” crowd funding campaign at indiegogo. I changed the goal to be “MailMate 2.0” which corresponded to a minimum of 6 months of development in 2014. This also allowed me to set a goal of $25,000 instead of $50,000 which I now considered as unrealistic. Using “2.0” in the goal description made it an easier “sell” (I’m a bit worried that it also sets unrealistic expectations).

This campaign was a huge success. The goal was reached within a week and more than $42,741 were raised in total. Even more importantly, MailMate gained a lot of exposure and new users. In retrospect, it has been a bit of a marketing stunt.

The numbers

As noted, the total amount raised was $42,741. The following table shows which perks were selected by the 677 contributors:

Note that the numbers do not add up. This is because a contributor can pay a larger amount than required for the perk selected. Also, $3,383 were contributed without selecting a perk (though some times by error).

By far, the most popular perk was the license key for MailMate 2.0. This alone would have been enough to reach the $25,000 goal.

For those interested (probably other crowd funders), there are several fees to be paid. After Indiegogo (4%) and PayPal have taken their share then around $38,100 is left and PayPal takes another 2.5% just to convert to Danish kroner. The remaining amount is about what corresponds to $37,150. Then comes the Danish income taxes. Note that I’m not complaining. Just laying down the facts.

The future

As promised in the campaign, the contributed amount ensures that I can work on MailMate for at least 9-10 months of 2014. It might be more if regular sales are better than they were in 2013. I have no release date for 2.0, but in practice it is not of major importance. MailMate is updated regularly and this currently includes features intended for version 2.0. Right now you can enable preliminary versions of some of these features in the General preferences pane of MailMate.

Now, what happens when/if I run out of money again? Well, then it’s back to square one. I might even try the crowd funding approach again.

Only a few hours left of the very successful crowd funding campaign and as a small “thank you” I am releasing version 1.7.2 of MailMate. It is mostly minor changes and fixes, but there is also a few new features:

• Integration with Calendar/iCal, BusyCal, and Fantastical.
• Integration with Evernote, Things, and The Hit List.
• Support for SmartyPants when using Markdown with HTML generation.
• Drag’n’drop email/mbox files to a mailbox to trigger importing.

The integration with other applications require that you enable the experimental 2.0 features in the General preferences pane of MailMate.

Go to the release notes to get all the details.

Over the weekend the crowd funding campaign reached its primary goal of $25,000 and it has since increased to more than $27,000. Yet again, thanks to everyone who helped make this happen! Development of MailMate is now guaranteed for the first 6 months of 2014. Maybe more if regular daily sales increase. If you never read about the background for this campaign then you can see it here.

It only took 6 days to reach the goal, but the campaign continues for another 30 days (I cannot stop it even if I wanted to). The rule of thumb is that for every additional $5,000 I can work full time on MailMate for a month. If you wonder about development speed then look at the existing release notes. I would call it steady.

I’ve promised to start distributing license keys to contributors as soon as possible. It appears I only have the email addresses of contributors (and a fake/anonymous name), but a license key is based on the real name of its owner. Therefore, the distribution requires first sending emails forth and back to get the required user details. I need to automate this (using MailMate, of course), but it might take a few more days. Ironically, I am also currently swamped by emails. Be patient.

I didn’t quite know what to expect from the crowd funding campaign when I launched it Monday. I knew I would get contributions from my existing users, but I didn’t know whether or not I would be able to spread the word about the indiegogo campaign. It was quite clear that my existing user base was not sufficient.

You see, I’m really bad at marketing — or maybe that’s not the right way to put it. It’s more like, I’m really bad at marketing something that is not perfect. I am my own worst critic. I see all the flaws, the bugs, the non-optimal workflows. I see all the missing features including those I have planned without anyone asking for it. My to-do list is a mile long.

This is why it has been great to see other people write about MailMate. They can do what I cannot do. Write about the good things without caring too much about the bad things. They can express the enthusiasm that I drown in notes about problematic corner cases.

Therefore, I would like to thank anyone who has ever written anything about MailMate in articles, blogs, comments, or Twitter posts. A special thank you to Macdrifter, Macstories, AppStorm, RunAroundTech, and aptgetupdate.de for writing about MailMate and the campaign. It made a huge difference. I would also like to thank those who have “sold” MailMate to friends, family, or colleagues.

This burst of gratitude was motivated by the more than $21,330 now contributed to the campaign by 295 backers. Most of the contributions have been $50 pledges, but maybe you noticed a substantial spike in the contributions yesterday:

The price of the perk was $2,000, but the actual contribution was $3,000 (the price of a perk can be increased by the backer). This contribution was made by long-term user of MailMate, Apparent, makers of Doxie. They deserve a special thank you.

I may be bad at marketing, but I’m very good at honesty. If you have any questions about the crowd funding campaign or the future of MailMate then you are welcome to ask in the comments.

A few weeks ago I launched a crowd funding experiment and I already wrote about the results. The conclusion was that it was worth a shot to launch a campaign on a real crowd funding site.

Help me get a flying start by going to indiegogo. Please also help me spread the word wherever you think it is appropriate. The short link for the crowd funding page is simply http://igg.me/at/mailmate.

Compared to the crowd funding experiment I’ve changed a few things. The goal is now to fund the time needed to finish version 2.0 of MailMate. This requires a minimum of 6 months of 2014 and therefore I’ve set the initial fixed goal to $25,000. A fixed goal means that I get nothing if the goal is not reached. Anything beyond $25,000 increases the period I am guaranteed to work full time on MailMate. The exact period depends on daily sales, but a rough estimate is an additional month for every $5,000.

I am also releasing MailMate 1.7.1 today. See the release notes for the details. The highlights are:

• New: Added option in the General preferences pane for enabling experimental 2.0 features (rules and commands).
• New: A Gmail label column is shown in the Tags preferences if the user has any Gmail accounts. Any tag with a Gmail label defined is not fetched as an IMAP mailbox.
• New: Hold down ⌃⌥ when selecting a message in the message list to select all related messages. The result depends on the column selected (the selection matches the search conditions for double clicking).
• New: The selectWithFilter: key binding has been changed to accept a format string. This can be used to select messages related to the current message. For example, here is the definition for a shortcut (⌃⌥D) to select all messages from the same sender and delete them: "^~d" = ( "selectWithFilter:", "from.address = '${from.address}'", "moveToMailbox:", "trash" );

I also added a replyMessage action for bundle commands (undocumented 2.0 feature) since I needed it to be able to generate “canned” replies for all the emails I’ve received as part of the crowd funding experiment. Based on a simple 7-line property list file (no GUI yet), a reply can be generated with a prefixed thank-you-note including a “Dear”-string based on the From header. With a single keystroke I can now generate these messages in the Drafts mailbox and then, if I need to, edit some of them before sending. How is that not worth a contribution?

On October 17th I launched an experimental crowd funding campaign and I promised to share the results. This is what I’ll do in this blog post.

First of all, I didn’t reach my (unofficial) goal, but I also didn’t expect to do so since MailMate has a small user base and I only used the blog, Twitter, and the mailing list to spread the word. I didn’t push all the buttons possible. Publicity has been fairly limited, but it has been sufficient to both increase download numbers and sales considerably during the two crowd funding weeks.

The results

At the time of writing I have received emails with pledges to contribute a total of $13,430. This is from 131 individual contributors which corresponds to a very nice average of a little more than $100. The most popular amount contributed is $50 as seen in the following table:

The 78 contributions of $50 or less amount to 26.5% of the total amount. This is less than what is contributed by the top 3 contributors (30%), but this is only because of the single major contribution of $3000 (22.5%). The 40 contributions of $100 also amount to 30% of the total amount.

Another interesting fact is which email client the contributors used:

Almost half are existing MailMate users (48.8%) and another 14.5% are trial users. In addition to that several known (to me) MailMate users are in the Unknown/iOS groups. All contributions of $150 and above are from current MailMate users.

The most wanted features

In the contribution email I also asked for the 3 most wanted “features” among a list of known popular requests. There were quite a few requests for features not on the list as well, but none of them were requested by multiple contributors.

Almost 1 out of 2 users would like to have rules. Fortunately, items number 1 and 3 are already experimental features for version 2.0 of MailMate. Item number 2 is already one of my high priorities. The only surprise on the list is that the least popular item is an HTML editor, but this probably reflects the fact that these are the features wanted by existing users and not what others need to start using MailMate.

Many of the emails also contained some wonderful comments about MailMate and statements of support. Some contributors stated that they wanted to contribute even though they could hardly afford it. I am deeply thankful for that kind of generosity.

Now what?

The crowd funding page is still online and newcomers are welcome to use it. I am currently preparing a “real” crowd funding page (including a stated goal) which I plan to launch next week and I’ll notify anyone who has sent me a crowd funding email. When this happens then I’m going to push all the buttons I can to direct attention to the crowd funding site and I’ll appreciate all the help I can get to spread the word.

Thanks for all the emails. I am deeply impressed!

Mavericks and Apple Mail

Mavericks (OS X 10.9) has been released and I’ve just read a very interesting article (TidBITS) about how Apple Mail has changed behavior with regard to how it handles Gmail accounts. Apparently this has, so far, not been a great success. Having been through the same implementation problems as the Apple developers I would like to share some of my thoughts on the issue of handling Gmail accounts.

I have a love/hate relationship with Gmail with an emphasis on the latter and I’m sure the same is true for the Apple Mail developers. Both Apple Mail and MailMate have tried to treat Gmail accounts as if they used the IMAP standard, but this is tricky since it is very non-standard — and I only use the term “non-standard”, because Google does this on purpose. Objectively, when they claim to provide IMAP access then the correct wording should be “extremely buggy”.

Nevertheless, Gmail is here to stay and both the Apple Mail developers and I know that we have to do whatever we can to allow Gmail accounts to nicely co-exist with standard IMAP accounts (yes, alternatives to Gmail do exist).

Duplicate messages

The main problem with Gmail is that labels are mapped to IMAP mailboxes. This means that any message with multiple labels is present in multiple IMAP mailboxes. A standards-compliant (offline) email client is going to handle that by fetching the message multiple times. Bandwidth is wasted, space is wasted, and weird things can happen when you move or copy messages. The worst Gmail mailbox is the “[Gmail]/All Mail” mailbox. This contains all messages not located in the trash or spam mailboxes. In MailMate (and previously in Apple Mail) it was best to ignore this mailbox and that is what happens by default in MailMate. If all messages have at least one label then all messages are still available in MailMate. Unfortunately, this is not always the case. I’ll get back to this issue further below.

Ignoring “All Mail” does not solve the problem with messages with multiple labels. Some users never use multiple labels and simply move messages as if the labels were simple mailboxes. This works fine in both Apple Mail (earlier versions) and MailMate, but it’s not a general solution working for all users.

Multiple labels in MailMate

Recently, I implemented a workaround in MailMate for the problem of multiple labels. It is currently an experimental solution and you can enable it following the instructions in the release notes for version 1.7. In short, MailMate can be told to handle specific Gmail labels as if they were tags. If a label is handled as a tag then MailMate automatically ignores the corresponding IMAP mailbox. Tags are already supported by MailMate (no integration with Mavericks yet) and uses IMAP keywords on standard IMAP servers. An added benefit of this is that you can move messages between Gmail accounts and other IMAP accounts and the tags are preserved. This is great if you are planning to migrate…

The “All Mail” problem

The remaining problem in MailMate is the “[Gmail]/All Mail” mailbox. It might contain messages which are not present in any other mailbox. Such messages are not available in MailMate. The only workaround is if the user makes sure that no such messages exist — and this can be tricky when using other email clients than MailMate (such as iOS Mail).

Apple Mail has now “solved” this problem by fetching all these messages and then identify duplicates across mailboxes to make sure they only store each message once. They are essentially trying to make Apple Mail behave like Gmail itself does. Personally, I think this is a dangerous path. Gmail IMAP behavior is non-standard, largely undocumented, and controlled by a single company. In other words, handle with care.

I’ve been bitten by sudden Gmail behavioral changes in the past and I won’t go down the same path as Apple Mail (and other email clients), but I’ve got an idea as to how to solve this remaining problem without major changes in MailMate.

An untested theoretical solution

When fetching a message, Gmail also allows the email client to fetch all the Gmail labels for the message. This would allow MailMate to identify the messages which are present in any other mailbox(es). If the IMAP code treated these messages as non-existing then the “All Mail” mailbox could become a mailbox containing the exact set of messages not present in any other mailboxes. The only minor problem would be that “All Mail” is not really “all mail”, but MailMate already has the “All Messages” virtual mailbox.

Maybe I’ll have time to implement and test this idea in the future. It might require a bit of funding. For now, I just wanted to share my thoughts on the issue.

Update October 27th: I implemented this solution in the latest test version of MailMate. Handle with care: You can fetch the test version by holding down ⌥ when clicking “Check Now” in the Software Update preferences pane. After that you need to subscribe to “[Gmail]/All Mail”. Details are provided in a mailing list message.

An often overlooked feature of MailMate (based on user feedback) is the flexible handling of multiple identities. In this blog post I’ll try to describe this feature in more detail. You might find it useful even if you do not have or think you need multiple identities.

In this context, an identity is an email address and, optionally, an associated name. A simple example of multiple identities is when you have multiple IMAP accounts with a single identity for each account. This can be handled by most email clients and mainly requires that an identity can be selected in the composer window.

It is more interesting when you have multiple identities for a single IMAP account. You might be forwarding messages from several POP3/IMAP accounts to a single IMAP account or you might be generating numerous email addresses to avoid spam, but the example I’ll use here is based on my own primary use: Wearing many hats when running a one-person business.

I’ll use example.com instead of freron.com in the following examples to avoid email harvesting, but other than that it is very close to my own use of multiple identities.

Here are some examples of email addresses for which all messages are going to the same IMAP account:

mm-info@example.com, mm-feedback@example.com, mm-sales@example.com, mm-support@example.com, mm-bugs@example.com

Using different email addresses for different purposes makes it easier to filter incoming email, but it also makes it easier for a business to grow, for example, if ever needed it would be easy for me to redirect all sales related questions to a different IMAP account and let someone else answer them.

The mm- prefix is used to avoid directory harvest attacks, but I don’t always remember to use that. For example, I also have mailinglist@example.com.

All of the addresses listed above are, in various ways, publicly available, but I also have a huge number of addresses which I do not share publicly. Nevertheless, my IMAP account settings are quite simple:

I use my own name as the default “Full Name”, but I could also have chosen to use “Freron Software”. The only explicitly listed email addresses are the ones I use to write new emails from the account (as opposed to replies for which I need most of my addresses). The list of email addresses could also contain explicit names for individual addresses:

mailinglist@example.com, Freron Software <mm-support@example.com>

The explicitly listed email addresses are the ones included in the “From” popup list in the composer window. More importantly, this also means that all of my other email addresses are not shown in the popup list. This helps keep the list short and clean.

MailMate still needs to know all addresses in order to handle replies properly and this is where it gets tricky and difficult to handle for most email clients. To some extent, it is possible to derive the correct “From” address for a reply using the information provided in the headers of a message. For example, here are some of the headers of a message sent to mm-info:

X-Original-To: mm-info@example.com
Delivered-To: mm-info@example.com
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25])
	by example.com (Postfix) with ESMTPS id 2BD4C76004
	for <mm-info@example.com>; Fri, 11 Oct 2013 01:30:17 -0400 (EDT)

Earlier versions of MailMate tried to automatically use such headers to derive the “From” address, but despite many subtle improvements it never worked for all users. In the end I replaced it all with the “Address Pattern” setting. This is a regular expression describing all email addresses which belong to the account owner (see the manual for examples). If such a pattern is provided then MailMate uses it for comparing with addresses found in the X-Original-To, Delivered-To, X-Delivered-To, and Received headers of any replied message.

The address pattern for my IMAP account is .*@freron\.com which simply means that any email address containing @freron.com is one of my email addresses. When replying then the “From” header automatically uses any such address found in the replied message (and the “Full Name” provided for the corresponding account). Furthermore, MailMate also uses the “Address Pattern” to automatically generate a follow-up message if I reply to one of my own sent messages.

Whenever you need to send a new message from an email address which is not explicitly listed in the account settings then you can use the “Customize…” option in the “From” popup in the composer window. The text field shown even offers to complete your address using known addresses from your previously sent messages.

The final thing to note is not directly related to the above, but it is a useful feature when dealing with a lot of email aliases. The “Sent Messages” mailbox automatically includes a set of dynamically created mailboxes. One mailbox for each “From” address found. This is done using the “Submailboxes” feature:

This is an honest and personal description of my current situation and how it affects the future of MailMate. In short, it is very likely that I’ll soon have to change my priorities. MailMate is not abandoned, but development is very likely to slow down.

Personal background

When someone asks me what I do for a living then I usually tell the truth. It goes something like this: “I’m a software developer working on an email client for advanced users on Mac OS X, but I’m not really making enough money to say that I do it for a living.” If people are willing to listen then I try to explain why I do it despite the fact that it makes absolutely no financial sense. It boils down to this: It’s my dream job.

I love working on MailMate. I love the technical challenges involved. I love helping the users of MailMate to solve their problems. I love the freedom of being an independent software developer. I even love studying the latest RFCs published about the handling of emails. And of course, I love it when someone pays for a license key essentially telling me that he/she likes what I’ve done.

Unfortunately, that last part does not happen often enough. Current sales are about 1/4 of what I would need to say that I’m really doing this for a living — and then I would still earn less than I would with a regular job. The only reason I have been able to work on MailMate for so long is because I’ve had a very generous sponsor: My wife.

The time has come to pay back on that generosity. Starting February, 2014, my wife is going back to school (well, University) to get a masters degree in Health Science. For the following two and a half years I hope to be the sponsor of her dream.

The future of MailMate

How does this affect the future of MailMate? First of all, I’ll continue to work on MailMate and provide support for existing and future customers. Development will slow down depending on the kind of job I’ll hopefully find before February, 2014.

Now, I know that for many of my users, MailMate is worth much more than its price tag. Some users spend hours in their email client every day and being able to do that efficiently is extremely important. Therefore I’m taking this opportunity to do a bit of an experiment. I’m going to try to crowd fund development of MailMate in 2014. This is a bit of a long shot since it corresponds to the regular users of MailMate contributing an average of more than $100 (based on update check statistics). Nevertheless, it’s an interesting experiment and I’ll share the results. You can help by spreading the word. Just link to this page or the crowd funding page.

Update: The experimental crowd funding has ended and a real crowd funding campaign has been launched at indiegogo.com. Read about the results of the experimental crowd funding here.

Starting Monday, the price of a MailMate license key is going to be $50. This change is independent of the success of the crowd funding experiment. This may seem counter-intuitive, but this was the original price of MailMate. With regards to competition it makes little difference whether the price is $30 or $50 since the general app price “race to the bottom” has now reached $2 for an email client (if ignoring the free alternatives). I consider MailMate a niche product and the future price is going to reflect that, but I’ll make sure I provide a substantial academic discount. Also, starting today, any license key sold is also valid for any future version 2.0 of MailMate.

The future for me

Since it’s very likely I’ll be looking for a new primary job soon I’ll take this opportunity to note that I am welcoming any links/suggestions/contacts you might have. As described on the About page I live in Copenhagen, Denmark, and unfortunately I cannot relocate. My one line CV: I have a PhD in computer science and I know a lot about algorithms, optimization, and emails.

As usual you should go to the release notes to get all the details, but make sure you notice the special section which describes how you can access (and test) early implementations of some of the features which are planned for MailMate 2.0.

I am increasingly often asked if I can recommend any IMAP email providers — usually as an alternative to Gmail. Although I have no affiliation or experience as a customer I have most often replied that Fastmail seems to be a good alternative. They still seem to be in good shape, but my answer was primarily motivated by the fact that I didn’t really know any other IMAP email providers. Well, I didn’t know any providers that had not added support for IMAP as an afterthought (Gmail, Yahoo, GMX, and now Outlook), and although free most of them were either primitive or buggy.

Recently I became aware of a couple of alternatives. This happened when a MailMate user was not satisfied with my standard Fastmail reply. Among his most interesting findings were Cotse.Net and LuxSci. They are interesting, because they use two of the most reliable IMAP server implementations. They use Dovecot and Panda, respectively. Dovecot is my personal favorite and it’s running on my own server. Panda was created by the inventor of IMAP, Mark Crispin.

In the future I’ll link to this blog post when someone asks for alternative email providers. You are welcome to add your favorite in the comments.

You really should consider taking a look at the detailed release notes for version 1.6 of MailMate since a lot has happened since version 1.5.4. Just in case you are in a hurry then here are the condensed highlights:

• “Send Later” feature added, for example, write “2 hours” to delay a message or “friday at 12.00” to send at a specific time. Read more here.
• New mailbox editor with multiple panes including “Submailboxes” for configuring automatically created submailboxes. Read more here.
• New view showing tips about some of the less obvious features of MailMate.
• Live preview in the Composer window (no longer just updated on Save).
• Improved the (extended) mailto: scheme.
• Built-in support for decoding TNEF files (winmail.dat).
• Support for decoding the x-uuencode transfer encoding. Important for attachments in messages generated by certain older email clients.
• Now showing the URL target of a tooltip when hovering over a link.
• Added a “Reply All” toggle to the composer toolbar. It works as both a toolbar button and as a shortcut (both ⌘R and ⇧⌘R works).
• De-obfuscation of email addresses when pasting text in a recipient header, for example, user at example dot com becomes user@example.com.
• Markdown support includes footnotes.
• Much faster at displaying long text messages.
• Various IMAP fixes including a workaround for a problem with Gmail causing sent messages to have duplicates in the drafts folder.
• Numerous other fixes making MailMate even more robust than it already was.

The main subject of this blog post is the “Re:” prefix used in the “Subject:” header line of most email replies, but the implicit subject is how MailMate handles the huge gap between theory and practice when dealing with many email headers. The story of the “Re:” prefix is in many ways a typical email header story. What may seem like a simple problem quickly becomes very complicated when 40 years of email history has made its mark. The Devil is in the details.

History

The first attempt to standardize email headers can be seen in RFC 561. This is September 1973, the document is 2 pages long, and not surprisingly it does not mention the “Re:” prefix. Note that this does not mean that the “Re:” prefix was not in use at the time. Many RFCs have been written after the fact and simply document what is already the prevailing behavior of implementations. This is emphasized by the first use of “Re:” in an RFC in 1977 where it is only present as part of an example of an email reply. This example lives on in RFC 733 (1977) and the classic RFC 822 (1982). It takes almost 20 years before RFC 822 is updated, but for the first time the “Re:” prefix is explicitly described in RFC 2822:

When used in a reply, the field body MAY start with the string “Re: “ (from the Latin “res”, in the matter of) followed by the contents of the “Subject:” field body of the original message.

It even includes an explanation of what “Re:” means although I’m with this guy on that one, but the Latin interpretation serves a purpose as we’ll see further below. For the sake of completion, the meaning of “Re:” was changed (corrected?) to be from the Latin “in re” in RFC 5322.

Ok, that was a nice bit of history and it actually started before I was born which means I don’t have to feel so old today. A similar history exists for many other of the standard email headers, but in the special case of the “Re:” prefix you might ask: Why standardize it at all? I hope that is going to be evident at the end of this blog post.

Theory

Originally, the “Re:” prefix served the simple purpose of making it easy to see when a message was a reply to another message. The use of it might even pre-date the introduction of the “In-Reply-To” header which could be seen as an alternative solution. In retrospect, it should have been standardized with the following rules:

• Add “Re:” to the subject of replies and replies only.
• Do not add another prefix when replying to a reply.

As we’ll see further below then the following clarification would also have been nice: Do not use any localized variants of “Re:”.

Practice

It might not have helped if the reply prefix had been standardized, but the lack of standardization certainly did not help. Variations of the prefix were invented and they resulted in various problems. I’ll describe 3 prefix related problems below.

The first problem is how to handle a reply to a reply. The naive solution is to just add another “Re:” prefix, but this is ugly and it can quickly increase the length of a subject line. A better solution is to only add the prefix if one does not already exist. Some email clients decided to do better than that and they introduced a counter in the prefix:

Re[4]: This correspondence now involves 4 messages.

That is not a bad idea, but since not all email clients supported it then a reply would often look like this:

Re: Re[4]: This correspondence now involves 4+1 messages.

The “smart” email client might be able to merge the prefixes when replying and therefore the above could be an acceptable side effect until all email clients supported the counters, but this now seems unlikely to ever happen. It does not help that this has never been standardized.

The second problem is localization. Some email clients (none mentioned none forgotten) insert a localized prefix instead of “Re:”, for example, in Danish this could be “Sv:” as an abbreviation of “Svar” (Reply). The result is predictable:

Re: Sv: Re: Sv: I don't think we are using the same email clients...

This is probably why it was decided that “Re:” is a Latin abbreviation.

The third problem is mailing list subject prefixes, for example, the MailMate mailing list prefixes subject lines with “[MlMt]” (I’ll use “blob” to refer to it as done in RFC 5256). This can confuse both email clients and mailing list software, in particular, if combined with the other problems described. The result could be a subject line like this:

Re: Sv: Re: [MlMt] Re: This is starting to get silly...

Things get even more complicated when also considering forwarding related prefixes and other semi-standard conventions. Now, the question is, what can MailMate do about this?

The heuristic solution

No perfect solution exists for this problem. The following is an excerpt from RFC 5256 where the suggested solution is to simply ignore most of the variations described:

Translations of the “re” or “fw”/”fwd” tokens are not specified for removal in the base subject extraction process. An attempt to add such translated tokens would result in a geometrically complex, and ultimately unimplementable, task.

I agree with the sentiment of this, but MailMate tries to be a little bit more pragmatic. The heuristic solution in MailMate is simple: A regular expression is used to identify the prefix of a subject line. This regular expression and many others can be found in the specifiers.plist file within the MailMate application bundle. The essence of the regular expression is as follows:

((?:\s*\p{Alpha}{2,3}(?:\[\d+\])?[:：])+)

Update October 6th, 2016: Too many false positives means that this is going to be replaced with an expression including a specific list of known prefixes. It’s also going to be configurable.

This is geek language for a (possibly repeated) sequence of two or three Unicode letters followed by an optional counter and a mandatory colon. The colon can actually be one of two kinds of colon. The usual one and a so-called full-width colon. The latter is used in the Chinese prefix “回信：” and possibly by other languages as well.

Why MailMate needs to know the prefix

MailMate is quite liberal with respect to what it identifies as a prefix. It is therefore also important that the prefix is handled with care. As we’ll see below it is mostly used for improving the display and sorting of subject lines. An exception is the generation of a subject line for a reply for which MailMate tries to never add more than a single “Re:”. This strategy adheres to Postel’s law: “Be liberal in what you accept, and conservative in what you send”.

The identification of the prefix, the blob, and the body of a subject line is used for the following purposes in MailMate:

• Display all subject lines with the same order of elements and without extraneous whitespace between these elements. The blob and, in particular, the order of the prefix and the blob is not standardized and therefore varies a lot.
• Proper sorting of messages by subject.
• Only compare the body of a subject when trying to determine whether or not the subject has changed between a message and its reply (MailMate warns about such a change before sending a reply).
• Only prefix a subject line with a single “Re:” when generating a reply.
• Allow searches for messages with a particular subject blob or subject body.

The behavior of MailMate is far from perfect, but the solution to this and similar header parsing problems is very general and flexible. For example, the sorting of the messages outline by subject is handled by defining the following sortKey for the subject column of the messages outline (outlineColumns.plist):

sortKey = "subject.blob,subject.body,subject.prefix";

And the display of the subject line in the messages outline is handled by the following format string (outlineColumns.plist):

formatString = "${subject.prefix:+${subject.prefix} }${subject.blob:+[${subject.blob}] }${subject.body}";

If you don’t like that (and you feel adventurous) then you can create your own columns or override the existing ones using low-level customizations.

This post became much longer than I anticipated and it didn’t even cover all the details. Now, please don’t get me started on the intricacies of the address related email headers…

A few new features, various behavioral tweaks, and numerous bug fixes. Detailed release notes can be seen here. The highlights are:

• Supports inline images in Markdown mode. Markup for referencing an attached image is inserted when adding an image to the textview (dragging or pasting).
• Opens links in the composer when hitting the enter key.
• Now derives a name from other headers if a Reply-To header does not include the name of the recipient.
• Added “Reply List” menu item (⌥⌘R).
• Added hidden preference (MmMessagesOutlineMoveStrategy) to control how the message selection changes when moving messages out of the currently selected mailbox.
• Handles (removes) Re:-prefixes in Chinese and other languages when generating the subject line for a reply.

This is primarily a bug fix release. The only new feature is a hidden preference to customize the “On … John Appleseed wrote:” string inserted for replies. Detailed release notes are available here.

Mac OS X Snow Leopard is supported, but you should still expect version 1.6 to require Mac OS X Lion.

The minor bump of the version number hides the fact that a number of small features have been added to MailMate in the passing month (see the list below). This release supports Mac OS X Snow Leopard, but, as previously noted, you should expect version 1.6 to require Mac OS X Lion.

Here are the most interesting changes since version 1.5.1:

• New “Synchronization Schedule” submenu for the Mailbox menu to configure how often individual mailboxes are synchronized.
• “Send and Archive”, “Reply All”, and “Flag” are now available as optional toolbar buttons.
• Inlined images are now rotated according to EXIF data in images (Mountain Lion only).
• Added “Reply to …” to the context sensitive menu of addresses in the headers view.
• Now respects the first/last name ordering of individual contacts in the “Address Book” (“Contacts” on Mountain Lion).
• Automatic handling of winmail.dat (TNEF) files. This is an experimental feature for expert users. Feedback is welcome.
• Low level feature can be used to add custom email headers to outgoing messages.
• Improved handling of OpenPGP and S/MIME. Now MailMate properly handles signed/encryped body parts in multipart/mixed MIME messages.
• Various IMAP fixes/workarounds including a number of fixes to handle ‘\’ and ‘"’ correctly.
• SMTP code now correctly handles lines prefixed with one or more dots.
• And more…

Detailed release notes can be seen here.

The Macworld site has posted a really good review of MailMate by Nathan Alderman awarding it 4 out of 5 mice. I couldn’t have written it much better myself. For comparison, Thunderbird got 3.5 of 5 mice and Apple Mail got 4.5 of 5 mice, but take into account that the “cons” of MailMate were “no POP or Exchange support” and “designed for power users”.

The review on the subject of searching/smart mailboxes:

As email search abilities go, this seems less like bringing a gun to a knife fight, and more like thundering into that particular duel at the controls of a helicopter gunship.

As any software developer I most often receive feedback from users with problems, so this was nice to read:

Needless to say, the program never crashed, glitched, or gave me any sort of trouble during my tests. MailMate does not know weakness.

It’s a minor bump of the version number, but the latest release of MailMate includes a major new feature: Tags.

The implementation of tags is based on IMAP keywords which means that they are easily and efficiently synchronized with an IMAP server (some servers may have limited support). The user interface is an unobtrusive token based text field shown when hitting a simple shortcut. It is very similar to the recipient address fields of the composer including automatic completion of tag names. It is easy to create new tags and a new preferences pane allows you to review and edit existing tags and their IMAP keyword equivalents. Read more about tags in the manual.

Other changes include:

• When failing to encrypt (OpenPGP) a message to an untrusted recipient then “Trust Once” is now provided as an option (when trying to send).
• Untrusted S/MIME certificates are now editable (via the “Show Details” button), that is, the trust settings can be changed within MailMate.
• Holding down ⌥ can be used to expunge (delete) selected messages immediately (instead of moving them to the trash mailbox of the IMAP account). An alert is shown which can optionally be suppressed.
• Improved line wrapping of headers of outgoing messages (standards compliant behavior).
• Various IMAP related fixes and workarounds.
• Fixed problem when using mailto: with attachments (only possible via AppleScript).

This release also includes a workaround for a problem under 10.7.5 which would make MailMate and the authorization interface to the system keychain hang when changing the trust settings of a server certificate. The problem is an Apple bug related to code signing.

It’s been a while since the latest public update of MailMate was released, but this does not mean that development has slowed down. The main reason for the unusual amount of time between updates is that MailMate has not yet been sandboxed and this is now a requirement for distributing through the Mac App Store. MailMate is still not sandboxed and a consequence of this release is that MailMate is no longer for sale in the Mac App Store. Don’t worry, if you have the App Store version of MailMate then you can send an email using the “Help ▸ Send Feedback…” menu item in MailMate (the App Store version) and I’ll make sure you’ll soon receive a regular license key. It is not yet decided when (if ever) MailMate returns to the Mac App Store.

Version 1.5 is likely to be the last major release with support for Mac OS X Snow Leopard (10.6). Expect version 1.6 to require Mac OS X Lion.

As usual detailed release notes are available. Here are some of the highlights:

• Support for S/MIME and OpenPGP.
• Updated to use Growl Framework 2.0 for notifications. This means MailMate now supports Mac OS X Notifications on Mountain Lion with or without Growl installed.
• Codesigned with a Developer ID certificate from Apple making MailMate work with Gatekeeper (Mountain Lion security feature).
• Support for searching LDAP servers when autocompleting names/addresses in the composer. Currently no GUI for this feature. Read more about it in the manual page about “Hidden Preferences”.
• Using AppleScript it is now possible to create (and optionally send) messages with attachments.
• Numerous IMAP fixes including several workarounds for buggy IMAP servers.
• Workaround for a bug in OS X 10.8.2 triggered when using AESendMessage to send AppleScript events. This affected users of SpamSieve. Every message sent to SpamSieve would hang and then time out (after 2 minutes) making MailMate seem extremely slow.
• HTML body parts in emails are now properly indexed for searching.
• Numerous performance optimizations.

The Problem

Since Apple released the 10.8.2 update for Mountain Lion I have received several reports about MailMate being slow and unable to detect spam. The problem turns out to be that the AppleScript communication between MailMate and SpamSieve breaks down. Each request sent by MailMate to SpamSieve hangs for 2 minutes before failing with a timeout error. This happens for every incoming message. See further below for more technical details and a bit of insight into the detective work some times needed in the software development process.

The Solution

If you think you have this problem with MailMate/SpamSieve then you should fetch the current test version of MailMate by holding down ⌥ when clicking “Check Now” in the Software Update preferences pane of MailMate (note that, in general, test versions are not always stable versions of MailMate and they may include incomplete features).

If you have a Mac App Store license then you cannot update to a test version. Instead you should contact me directly.

You can also temporarily fix the problem by killing a process named appleeventsd. You can find and kill it in the Activity Monitor or you can paste the following in a Terminal window (requires a password):

sudo killall -KILL appleeventsd

The Technical Details

The time line of an investigation of this problem can be seen in this ticket. In short, Michael Tsai (SpamSieve developer) joined the discussion and we found a workaround involving a different approach to the AppleScript communication between MailMate and SpamSieve. But a much better understanding of the problem and a better workaround came about when Michael was contacted by Brian Webster. You can read about Brian’s findings here.

This is what is currently “known” about the problem:

• The problem is related to the OS X 10.8.2 update.
• The problem is related to the use of the AESendMessage/AESend functions used with typeApplicationBundleID or typeApplSignature for the target type.
• Using typeKernelProcessID for the target type still works (thanks goes to Brian Webster for this crucial fact). This is what is used for the workaround in MailMate.
• NSAppleScript and osascript are not affected by the problem.
• Killing the appleeventsd daemon fixes the problem temporarily (Antonin Hildebrand discovered this fact).

The above indicates that the problem is likely to be some kind of stale cache used by appleeventsd for mapping bundle ids and 4-letter application signatures to process ids. It also indicates that triggering this problem involves relaunching the target application (in order to give it a new process id). This has been confirmed by a user (Torsten Grust) in the context of MailMate/SpamSieve.

Thanks to everyone who helped track down this problem. Note that I am still not able to reproduce the problem myself which means that feedback on the solutions above is still appreciated.

MailMate received a 4 out of 5 star rating in the French magazine VVMac (Vous et Votre Mac). The review is part of a large special feature about emailing on OS X and it is, of course, written in French. It is possible to skim an (unreadable) online version of the magazine here (using Flash), but I have also been allowed to provide a readable PDF of the page with the MailMate review. VVMac is one of two printed French magazines on the subject of OS X. It is distributed in France, Belgium and Switzerland.

Speaking of reviews, MailMate has also received a few user reviews in the Mac App Store (in the American and Australian stores). At the time of writing this, they are all positive 5 star reviews except for a single 1 star review. The exception is a good example of why Apple should provide some way to contact unhappy app store buyers (it could work anonymously). I don’t mind negative reviews, but in this case, a buyer has an “out-of-the-box” problem and I cannot do anything to help. Others have written wise words on this subject.

You are very welcome to provide a review/rating in the Mac App Store, but if you have some specific problem then please write a feedback email first (use the “Help ▸ Send Feedback” menu item). I may not be able to help you, but feedback is never ignored.

The following question was asked by dmorel on Twitter:

@mailmateapp Any chance we can permanently tag an email address as ‘not junk’ so as not to be forced to click that button every time?

It is a good question and it deserves more than a 140 character answer.

Image blocking

By default, MailMate does not display external images for any messages arriving in the inbox of any account. This is a security feature which ensures that no one can track if or when you read a given message. When viewing a message it is possible to allow loading external images once or allow it permanently by explicitly marking the message as “Not Junk”.

Image blocking can be configured in the Security preferences pane. Most importantly, it is possible to change the set of messages for which image blocking is enabled. This brings in all the power of smart mailboxes to the configuration of image blocking and we can use this to “implement” an answer to the Twitter question above.

The Answer

We need to create two smart mailboxes. The first one simply matches all messages marked as “Not Junk”. Base it on “All Messages” and give it the following condition:

The other mailbox is more interesting. We’ll name it “Image blocking” and we’ll make the smart mailbox above a child of this mailbox. This is not important, but it emphasizes that the two mailboxes are related.

The “Image blocking” mailbox can be based on any mailbox (the universal Inbox would be a natural choice) and it only needs a single condition:

In other words, this mailbox matches any message for which the sender’s address does not match any sender’s address in the set of messages marked as “Not Junk”.

Finally, we need to change the setting in the Security preferences pane to block images for messages in the smart mailbox named “Image blocking”.

The end result is that whenever a message is marked as “Not Junk” then all other messages from the same sender are treated as if they were marked as “Not Junk” as well.

This may all seem a bit complicated and it certainly could be made easier to enable something like the above, but the beauty is in the flexibility. You can make image blocking behave in almost any way you can imagine.

@dmorel: I hope this answers your question.

April 17th discount on MailMate. Help me celebrate my birthday. Half price all day.

Buy here or in the Mac App Store.

MailMate 1.4.2 has been released and this happens just one week after version 1.4.1 was released. The main reason for this is a performance bug which already affects some users and over time the bug would affect more users. It is highly recommended to update as soon as possible. This release also includes other changes. A short list follows below and more details can be found in the release notes.

• Fixes a performance bug in version 1.4.1 which under certain circumstances could make MailMate practically unusable (high CPU and disk usage).
• Improved derivation of default “From” address when using email aliases.
• Introduced key bindings for changing keyboard focus.
• Improved headers editor for recipient addresses in the composer.
• Smoother scrolling in the mailboxes outline for users with a large number of IMAP mailboxes.
• Bounces “Download” folder instead of opening it when saving an attachment.
• Fixed “Edit ▸ Find ▸ Mailbox Search” menu item to behave correctly when selecting it using the mouse (previously it switched to “All Messages”).

Leopard note: This release of MailMate also works for Mac OS X Leopard. The software update mechanism was disabled in version 1.4.1 for Leopard users, so in order to update you have to download version 1.4.2 here. This is expected to be the final version of MailMate working for Leopard.

MailMate 1.4.1 has just been released both on the homepage and in the Mac App Store. Currently, the only difference between the App Store version of MailMate and the version available via the “Download” link above is that the latter has its own Software Update mechanism (which includes optional access to beta builds of MailMate if you like to be on the cutting edge).

Note: This is expected to be the last release of MailMate working on Mac OS X Leopard (10.5).

The minor change in version number does not reflect the large number of improvements in this update of MailMate. The following is a list of some of the changes. You can see all the details in the release notes.

• Option to automatically mark messages unread (see the “Composer” preferences pane). In particular, automatically marking unread can be disabled.
• Added support for named alternative email addresses which is useful when you do not want to use the same name for all addresses specified for an account (see IMAP account settings).
• Trackpad gestures are now supported by MailMate. For example, swiping can now be used to navigate, archive, or mark messages. Combined with modifier keys, it is possible to configure numerous swiping shortcuts.
• It is now also possible to bind keys (or swiping gestures) to expand/collapse messages/threads, or explicitly set or remove tags.
• Updated and specialized the included Markdown converter (sundown). It is now better at handling changes in quote-level although this is non-standard Markdown behavior. Also fixed handling of quoted code blocks which would often fail when indented code blocks were in use.
• Improved detection of whether Markdown can be used for replies. Markdown is now enabled whenever the text replied to is known to be Markdown or does not contain any Markdown markup.
• Added the use of an external script to convert HTML to plain text (Markdown) when needed for replies or forwarded messages.
• Improved handling of links in the composer. No longer opened on single click. Hold down command to open a link or use the menu item.
• Added “Reset Usage History” button in the Signatures preferences pane. MailMate now also automatically uses the first configured signature (if any exists) when a signature cannot be derived otherwise.
• Significantly improved performance for large message stores.
• Improved IMAP code for handling servers which do not include the UIDPLUS extension.
• Improved performance of deleting accounts/mailboxes/messages.
• Improved handling of address-only messages when completing addresses.
• Improved derivation of default “From” address for replies.

Markdown in MailMate

MailMate 1.4 is the first version of MailMate capable of using Markdown to generate rich text (HTML) messages. How it currently works is documented in the manual. The main purpose of this blog post is to provide some of the thoughts behind the implementation.

HTML in emails

The main reason that MailMate only supports plain text in its composer is that I’m really not a big fan of HTML in emails. I can live with the size of HTML emails, the privacy/security issues (since MailMate can handle that), and the ugliness of a raw HTML email, but it is difficult to accept the visual appearance of many HTML emails.

Depending on the email client used to write an email, the look of quoted paragraphs, the font used, the font size(s), and even the font color are under the control of the originating email client. At its extreme, I’ve seen an email client insert images of correspondents in a redundant recap of all correspondence in a message thread, but it is bad enough when someone thinks that the recipient of an email is going to appreciate a blue Comic Sans font. Reading through email can some times feel like browsing through a set of amateur web pages, each with its own unique visual appearance.

Essentially, I would like the visual appearance of an email to be under the control of the recipient and not the sender. The typical workaround when viewing emails is to configure the email client to ignore the HTML body part of a message when possible (we’ll get back to how that works further below). In MailMate, you can do it by enabling the “Prefer Plain Text” option in the “Preferences ▸ Viewer” pane.

The problem, for me, with preferring plain text for both composing and viewing is that I do like rich text formatting as long as it is related to the semantics of the message. For example, when using emphasized words, bullet lists, tables, or verbatim text (code) with a non-proportional font. A nicely emphasized word does look better and is easier to read than the traditional starred *word*.

So, the question is, if MailMate is going to support rich text formatting when composing an email then how should it work? The end result has to involve HTML in order for it to work in most email clients. And it should also work well in email clients with no support for HTML. The answer is Markdown.

Markdown

Markdown is a plain text formatting syntax created by John Gruber in cooperation with Aaron Swartz. Gruber also created a Perl-script for converting Markdown to HTML, but this is no longer the important part of his creation since numerous (and better) implementations now exist. Markdown is based on the traditional use of simple markup in plain text emails such as using asterisks to emphasize a *word*. John Gruber expanded and (loosely) formalized the syntax of such “readable” markup thereby allowing it to be parsed and then converted to HTML. Even though Markdown was designed for conversion to HTML, it could be used for other formats as well (disregarding the use of inlined HTML). If you do not know Markdown then I encourage you to try the “dingus” provided by Gruber.

Using intuitive simple plain text markup symbols Markdown allows you to easily emphasize words, write outlines, use headers and subheaders, quote text, make code blocks, link to URLs, embed images (no floating images), and little more than that. It’s all about semantics. At the same time Markdown does not encourage you to do any styling such as using custom fonts and colors.

The best (and essential) aspect of Markdown is that the definition of quoted text is also based on the style traditionally used in emails. This means that quoting Markdown text works as expected. It does not ruin lists, headers, code blocks, or anything else. Markdown can therefore be just as useful for replies as it is for new messages.

Even though Markdown was inspired by email plain text syntax it has not been used much in that setting. The primary use has been for writing web content. For example, I am writing this blog post in Markdown. A Google search did reveal a few examples though.

I found MarkdownMail for iOS which allows Markdown to be used for the creation of HTML for use in both emails and blog posts, and I found hacks for Emacs and Mutt on how to create both plain text and HTML for an email (more examples are welcome in the comments).

The structure of a raw email

In order to discuss the implementation of Markdown in MailMate, we need a quick crash course on the structure of a raw email. You can skip it if you already know about MIME body parts.

Originally, an email only had two parts; an envelope (from, to, subject, etc.) and a body (the message itself). When the need for attachments arose the problem was solved by encoding them in plain text and making them part of the body with some plain text barriers to indicate the start and end of these attachments. This approach evolved over the years and finally became the MIME standard. MIME is an acronym for “Multipurpose Internet Mail Extensions” and it is described in a series of RFCs, the first one being RFC 2045. Note that the first (and now obsoleted RFC) describing MIME is from June 1992 (RFC 1341) and almost 20 years seems to have been enough to make MIME widely supported (well, maybe not for newsgroup clients).

Using MIME an email can be constructed as a tree of body parts in which each body part has its own set of headers. There are numerous advantages. An attachment is a separate body part, an email can be embedded as a body part, a digital signature can be put in its own body part, and so forth.

The type of each body part is specified in a header named Content-Type. A simple plain text message has the following header (actually the header is not needed in this case since the values are the defaults):

Content-Type: text/plain; charset=us-ascii

Note that text is denoted as the type of the message and plain is the subtype.

A message with multiple body parts could have a “root” body part with the following header:

Content-Type: multipart/alternative

In this case the subtype alternative (RFC 2046) means that the body parts in the message should be interpreted as alternatives for message display with the last body part being the best one. In practice this is almost only used to provide two alternatives; a text/plain alternative and a text/html (or multipart/related) alternative. The latter is shown by email clients which support HTML (unless configured otherwise) and all other email clients can show the plain text alternative.

Markdown is not an alternative

It may be tempting to introduce a new subtype and then use a MIME type named text/markdown, but this would miss the point of Markdown being designed to be simple readable plain text. In particular, a text/plain alternative to the Markdown text would just be the Markdown text itself. It would be redundant. Markdown is more like an attribute of plain text. A better way to convey this information would be to use a content type parameter:

Content-Type: text/plain; charset=us-ascii; markup=markdown

This is similar to the format=flowed parameter introduced in RFC 3676 (which is also supported by MailMate).

You may wonder why this parameter is needed at all since an HTML body part is already generated and that is what most receiving email clients are going to display. This parameter is useful when replying to a Markdown message since it tells the receiving email client that it is safe to assume that the reply can be written using Markdown as well. Of course, MailMate is currently the only email client able to use this information.

Taking it one step further

Now, I’m still not a big fan of including HTML in emails which are essentially plain text. The solution outlined above is acceptable, but there is still going to be issues with how other email clients display the HTML generated and how it is handled in a reply (there is a lack of standardization in this area). Currently, MailMate generates simple HTML with no styling, but it is likely that this is not going to be good enough in practice. At least not for quoted text.

We could take it all one step further if we either know that the recipient has a Markdown-capable email client or if we simply don’t care. When MailMate displays a plain text email (or body part) with the markup=markdown parameter/value then it automatically converts the plain text to HTML before displaying it. The beauty of this is the simplicity of a raw message. Here is an example:

From: "Freron Software" <mm-feedback@freron.com>
To: "Freron Software" <mm-feedback@freron.com>
Subject: Taking it one step further...
Date: Wed, 21 Dec 2011 13:35:00 +0100
Message-ID: <DB451A45-1077-4C4D-90A2-44A18EEE68C9@freron.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.4r2651)

# Markdown in [MailMate][]

Note that *this* message has no HTML body part. Based on the
`Content-Type` header, the receiving email client could do the
conversion, but if it is not able to do so then this is still readable
plain text.

In the eyes of an email client developer, this is a beautiful raw email.
Nicely sorted headers and no hideous quoted-printable encoding (or
base64) even though long lines and non-ASCII like &aelig;&oslash;&aring; is used.

[MailMate]: https://freron.com

The responsibility of generating the HTML is now on the receiving email client. The obvious disadvantage is that it would not be supported by most email clients, but Markdown is also perfectly readable as plain text. Nicely formatted messages can be sent this way without using more space than normally used for a simple plain text message, but email clients recognizing Markdown can both display these messages nicely and create nicely formatted replies using Markdown as well.

Note that the use of Markdown does not exclude the possibility of a WYSIWYG editor, but it does require that the features of such an editor should be limited to what can be expressed as basic Markdown.

Generating an HTML body part is optional in MailMate. If you want to play with the Markdown settings in MailMate then note that the composer has a custom layout (see the “View ▸ Layout” menu) which makes previewing easy. If you do this make sure you also use the “View ▸ Show Raw Message” (⌥⌘U) and “View ▸ Show HTML Source” (⌃⌘U) menu items.

Standardization

When receiving a Markdown message MailMate uses sundown (a Markdown converter) to generate the HTML displayed. For now, HTML in the Markdown text is stripped, but the Markdown extensions fenced code and tables are allowed. Most importantly, sundown has been configured to respect newlines. This is different than the typical use of Markdown, but it ensures that email clients with no knowledge of Markdown can still handle paragraphs correctly. It also avoids problems with the concept of lazy blockquotes.

The choices above (made by me) illustrate the need for standardization if this feature should ever go beyond the small community of MailMate users. In particular, when HTML is not generated the sending and receiving email clients must agree upon the style of Markdown used. Essentially, 2 specifications are needed:

• A specification of the markup parameter for the Content-Type header.
• A specification of the Markdown language as used in emails.

The first one is fairly straightforward while the second one looks like a can of worms due to the many existing variations of Markdown and the current lack of strictly formal specification.

To properly introduce a markup parameter, it has to be registered and approved by IESG as described in section 3.1 in RFC 4288:

Registrations in the standards tree MUST be
approved by the IESG and MUST correspond to a formal publication by a
recognized standards body.

In the same RFC there is also the following relevant comment about parameters in section 4.3:

New parameters SHOULD NOT be defined as a way to introduce new
functionality in types registered in the standards tree, although new
parameters MAY be added to convey additional information that does
not otherwise change existing functionality.  An example of this
would be a "revision" parameter to indicate a revision level of an
external specification such as JPEG.

Time will tell if markup=markdown has a future beyond MailMate. For now, MailMate is a proof-of-concept which can be used to examine any practical problems which needs to be considered if standardizing either the markup parameter or Markdown.

Random thoughts and open questions

• Inlining images works fine with external resources, but it could be made to work with embedded images as well by using content ids (cid:).
• Should embedded HTML be allowed?
• Should a default embedded CSS stylesheet be allowed?
• It would be great if the editor had syntax highlighting, shortcuts for common actions, and so on.
• MailMate currently does not handle replying to HTML-only messages very well. These could be converted to Markdown text before replying.

You are welcome to continue the list in the comments.

We are proud to announce the release of MailMate 1.4. It is the first version of MailMate to appear on Apples App Store. We celebrate this with a substantial price reduction which is also available at our own store. Currently, the only difference between the App Store version of MailMate and the version available via the “Download” link above is that the latter has its own Software Update mechanism (which includes optional access to beta builds of MailMate if you like to be on the cutting edge).

The major new changes in version 1.4 are:

• Markdown support (more about that in a future blog post)
• Reorganized and extended preferences
• Various IMAP and SMTP improvements

But there are numerous other big and small changes. You can get all the details in the release notes.

With the release of MailMate 1.3.1, the so-called Help Book available within MailMate is now also available online at https://manual.mailmate-app.com.

It is worth noticing that two new chapters have been added. One is about custom key bindings and another is about hidden preferences.

Custom key bindings can be used to introduce simple keyboard shortcuts for your most frequent actions. For example, you can bind keys to jump to specific mailboxes or toggle IMAP keywords. MailMate is distributed with an example keybindings file which shows how to create most of the key bindings available when using Gmails web interface (if you have key bindings enabled in Gmail). Other webmail clients have different key bindings. One example is fastmail. If you create a key bindings file for your webmail client then I encourage you to share it by letting us include it in a future update of MailMate.

The chapter about hidden preferences is a collection of all the features which can currently only be enabled using the Terminal. Previously these preferences were only described in the release notes. There are simple preferences such as for enabling alternating row colors and there are preferences for advanced experimental features such as rudimentary support for OpenPGP. I encourage you to look through the list yourself.

See the release notes within MailMate or online.

With this release MailMate now officially supports Mac OS X 10.7 (Lion). The release notes for are extensive and can be seen within MailMate. Here is a shortlist of highlights:

• Full screen mode in Lion (⌃⌘F).
• New look for attachments which includes a button for “Quick Look” and drag’n’drop of the file icon.
• New flexible system for custom key bindings including an example to obtain Gmail-inspired key bindings.
• Undo/redo supported for moving messages.
• Improved replying to messages in the Sent mailbox (such replies are handled as follow-up messages instead of replies).
• Preferences option to use a bold font style for unread messages.
• Fixed account importer to work for Apple Mail on Lion.
• And numerous other improvements and bug fixes.

See the full (and long) release notes within MailMate. Here is a short list:

• New look and functionality for attachments including proper dragging behavior and an “Open With” menu item.
• Improved HTML generation and default stylesheet for the message view making it easier to create a custom stylesheet.
• Added submenu items for the menu items in the status bar counters: “Archive”, “Move to Junk”, “Delete”, “Reply”, “Forward”, and “Mark as Flagged/Read”.
• Added “Empty Mailbox” menu item for “Deleted Messages” and “Junk”.
• Support for the IMAP XLIST command (used to automatically identify standard mailboxes). This is particularly important for localized variants of Gmail.
• New experimental feature: Markdown for writing emails…

Today the old MailMate Store was replaced by a new store based on FastSpring as reseller. The old store was based on PayPal only. This means more payment options, proper handling of VAT, and a much more pleasant user experience. The main motivation for the change is the handling of VAT, but I have also been pleasantly surprised by the quality of the service provided by FastSpring. Kudos to them.

To “celebrate” the switch there is a 25% discount on MailMate the first week (ending May 18). That, by the way, only took a few minutes to set up in FastSpring.

See the full release notes within MailMate. Here is a short list:

• Improved mailbox search. Most importantly, you can now store a default set of search conditions.
• Improved completion of addresses in the composer.
• Support for SMTP authorization via the LOGIN method (important for SMTP servers which do not support PLAIN).
• Fixed bug related to deletion of spam. Make sure you read the release notes if you use SpamSieve.
• Various other changes and bug fixes.

The complete release notes for version 1.1.1:

Autosave

When composing a message, a copy is autosaved every 30 seconds (but only if changes exist). When launching MailMate, any autosaved messages are detected and the user is asked to either discard or import. This should never result in more than 2 versions of a draft: The autosaved version and the most recently explicitly saved version.

Other changes

• Reordering of standard mailboxes is now allowed.
• “Save Attachment…” now shows and allows changes to the default filename.
• More information provided when importing messages.
• The Flag column in the messages outline is now used to display an exclamation mark for high priority messages (only when message is not flagged).
• Improved replying to messages in “Sent Messages”. It previously failed when the message was not sent from the first identity of an account.
• Removed maximum width for a couple of integer columns in the messages outline in order to better handle custom font sizes.
• Only applying SpamSieve to messages without the $NotJunk flag. This is needed, for example, if running SpamSieve on two machines when trying to move a message from the Junk mailbox back into the Inbox.
• Now using “MIME-Version” instead of “Mime-Version” in new messages. Details matter.
• Workaround for Gmail for a problem resulting in sent messages ending up in the trash. How to reproduce the problem is unresolved but it is likely related to Googles alternative interpretation of the IMAP standard.
• Workaround for servers wrongly providing EXISTS responses before EXPUNGE (Yahoo, MS Exchange 2007, and probably others).
• Fixed various other IMAP issues.

The complete release notes for version 1.1:

MailMate for everybody

Several improvements allow MailMate to work with most (if not all) IMAP servers. Send some feedback if you have an IMAP account which does not work with MailMate.

The most important improvements are:

• No longer requiring the UIDPLUS extension. Servers with the UIDPLUS extension are still recommended since it is both more robust and more efficient when utilized by an offline IMAP client such as MailMate.
• Better handling of IMAP servers with limited support for IMAP keywords (such as MS Exchange IMAP).
• Handles when the INBOX on the server is not in uppercase (such as Yahoo IMAP).

Image blocking improved

The default in MailMate is now to always block external references, but the user has detailed control of the behavior using some new preferences (currently under General). The most important setting is “Block external references for messages in …” which allows the user to define a mailbox containing the messages for which blocking should be enabled. The default is “All Messages”, but it could be any smart mailbox, for example, a smart mailbox excluding messages which have been identified as being safe. This could be based on headers inserted by server-side spam detection software (like “X-Spam-Score” or “X-Spam-Flag”).

For convenience, the preferences also include a checkbox for “Load external references for messages marked Not Junk” (this could also be done using a smart mailbox as described above). This is especially useful when combined with a new SpamSieve option which allows you to automatically mark messages as Not Junk if they have a low spam score.

Go to the General preferences and play with these new settings and send some feedback if it somehow cannot handle your preferred use of image blocking.

Note that blocking is always enabled for messages in “Junk” or “Deleted Messages”. It is also always enabled for attached messages (occurs when using something like “Forward as Attachment…” has been used to construct an email). This allows one to safely receive forwarded spam.

Composer related changes

When completing addresses, MailMate now looks in all Address Book sources. Technical note: This is done using a private API and therefore this feature may be removed again in future versions of MailMate. Feedback on both success and failure of this feature is welcome.

When pasting in the composer, text is preferred to images (pasting an image makes it an attachment). This was necessary since otherwise pasting text from some applications would instead result in the attachment of an image.

Also note:

• Email address completion now works for Address Book groups including distribution list identifiers.
• Improved splitting/merging of quoted paragraphs.

Other changes

MailMate now enforces a 30-day trial period. It is measured as days of active use measured by the number of days on which messages have been sent. When the trial period has expired, you can still use MailMate, but you can only send 2 messages per launch.

Interesting minor changes:

• Separate search shortcuts: Search All Messages (⌥⌘F) and Mailbox Search (⌃⌥⌘F).
• The Search button in the toolbar now keeps MailMate in the current mailbox if holding down ⌥.
• Allows renaming of standard mailboxes.

Various (less interesting) fixes:

• Fixed bug in saving attachments using “Message ▸ Save Attachments…” triggered when focus was in the message view (nothing was saved).
• Fixed rare crash bug related to a message being deleted while in the process of being displayed in the message view.
• Fixed problem triggered when an IMAP connection was reused to select a second mailbox just after a message was expunged from the first mailbox (server-side).
• Fixed crash bug which was triggered when a new IMAP mailbox was registered and a popup button with mailboxes was in use at the same time.
• “Move Out of Junk” is no longer greyed out in the messages menu when messages are selected in the Junk.
• Fixed bug in the filter editor (Mailbox Search) which would make it ignore parts of the query if an any/all expression existed with a single child.
• Removed toolbar button in the Preferences window.

The past couple of weeks, several users have reviewed MailMate at the MacUpdate site. It is very much appreciated when users take the time to share their thoughts about MailMate and it is even better when it is accompanied by 5-star ratings. The following are some favorite excerpts:

David Levy:

MailMate is, in my view, the first serious power-user IMAP email client. The power is tremendous in terms of configuring your mail viewing and display exactly as you would like. Second, almost everything can be done from the keyboard. including filing messages and moving to arbitrary mailboxes. The application is lean and fast and, in my view, saves time. It is also a new codebase with proper Cocoa underpinnings so it works well with other apps.

When Mail.app came out in OS X 10.0 and 10.1 it was a great application. Now it seems slow, inefficient to use at times and too much aimed at very ordinary mail use. You have to trick it out with extensions from indev to get enough power.

[…]

Try it out, give it a good long run, because the power will become more apparent over time.

[…]

Sherman Wilcox:

[…] if you take MailMate for a test spin, spend some time with it. You’ll immediately see some power and flexibility, but after several hours of using it you’ll also discover remarkable conveniences and efficiencies that aren’t obvious at first. And by all means email the developer. He’s quite responsive and helpful.

If you’re a heavy email user, this is an application to keep your eye on. It’s missing some features I’d like, but even at 1.0 it will make your workflow much more efficient. It has the power features to match your work style and make it better.

Macmath17:

I’ve always liked Mail.app, but in the past year or two it has become slower than I’d like and it doesn’t work with GMail as well as I’d like. So I’ve been on the lookout for another email application when last summer I saw MailMate. I tried it a bit and although it was a work-in-progress, by September I had purchased a license. It was shortly after the first of this year that I finally went to using MailMate full-time and leaving Mail.app closed, but I wish I had made the switch earlier. The email applications that I’ve been using all these years, have essentially the same paradigm. Now that I’ve been using MailMate full time I found that I’ve been moving away from that paradigm to a more efficient way of viewing, writing, and navigating my email. Every now and again I’ll discover something new and useful about MailMate and become yet more efficient in how I do things.

[…]

The author (who is a responsive as they come) adds thoughtful features from a fresh view and does them well. Then he moves on to another feature and gives it a fresh look. So MailMate might not have all of your favorite features yet. Some of those will be coming over time, and some you might find will be replaced by a better (but different and related) feature he’ll add.

Added March 25:

Sam Smolk:

MailMate is the answer to my dreams.

[…]

Mailmate is fast, reliable, clean, and has a strong search engine which is as customizable as that of PowerMail, only of the 21th century. It supports Unicode. It is still actively developed—with a responsive author—which bodes well for the future. It is also written for Intel machines and OSX, which means a cleaner code than most, if not all.

[…]

The complete release notes for version 1.0.2:

The SpamSieve support can now be enabled in the preferences. This includes the choice of a mailbox in which SpamSieve should be used to check new messages. By default, this mailbox is the unified Inbox, but it could be any smart or real mailbox.

The handling of messages outline columns has been improved. Submailboxes automatically inherit the settings of parent mailboxes unless explicit changes are made and it is now possible to select the outline column (the column with a triangle) which is useful if the order of columns is changed.

Composer related changes:

• Improved the default choice of identity (from-address) for new messages.
• Fixed handling of signatures such that “No Signature” is remembered for future messages.
• Fixed quoting level color when removing the last quote level character.
• The various settings in the Substitutions menu (in the context sensitive menu) are now saved. In particular, Text Replacements can be enabled (see Language and Text in the System Preferences).

IMAP related changes:

• Fixed issue where subscribed mailboxes under a private namespace were not found (due to a missing delimiter in the namespace prefix).
• When creating a mailbox with the same name as an unsubscribed mailbox, the mailbox is automatically subscribed (instead of failing).
• Added alternating row colors in subscriptions sheet.

Other changes:

• Added “Common Headers or Body” to make it easier to search addresses, subject, or unquoted body text.
• Fixed encoding of long header lines with non-ASCII and no spaces (for example, a subject line in Japanese).
• Now allows whitespace around “=” in Content-Type parameters (in order to handle a bug in at least some versions of PHPMailer).

Heinz Tschabitscher from About.com has written the first review of MailMate giving it 4 out of 5 stars.

Strictly speaking, it is not the first review since several users have written reviews at MacUpdate.

The first update of MailMate after the 1.0 release is now available. See the detailed release notes within MailMate. The most important points are:

• Improved Reply / Reply All functionality (never do the wrong thing again)
• Experimental support for SpamSieve
• Fixed memory leak in Activity Viewer (especially bad during an initial synchronization)

Bonus: A “hidden” option for alternate row colors in the messages outline (see the release notes).

A milestone has been reached: The first non-beta of MailMate has been released. The homepage has also been redesigned although functionally it is the same. Now it is time to work on all of those postponed-for-1.x features.

There has been quite a few changes since beta 0.9.10. Read about them in the release notes within MailMate.

The following is the press release sent out via prMac:

Summary: MailMate is an ambitious powerful email client for Mac OS X. It is designed for and only supports IMAP while still working in full when offline. MailMate has state-of-the-art searching capabilities and correspondingly advanced smart mailboxes. Extensive keyboard control and dynamic signatures ensure a highly efficient workflow when reading and answering emails. Alternative message viewer layouts and a browser-inspired design ensure easy and rapid access to related messages.

FOR IMMEDIATE RELEASE

Copenhagen, Denmark - February 16, 2011 - Freron Software is proud to release version 1.0 of a new Mac OS X email client. Aimed at power users, MailMate optimizes the workflow when dealing with large amounts of email. MailMate has state-of-the-art searching capabilities which is also used to provide advanced Smart Mailbox features. The encouraged workflow in MailMate is to handle each incoming email by either archiving or deleting it. Smart mailboxes can then be used to automatically organize emails based on any message header of any message body part.

MailMate includes a set of alternative layouts for the main view. For example, a widescreen layout with the message view to the right of the messages outline and a correspondence layout which allows one to immediately see any messages in any existing email correspondence related to the currently selected message(s).

Other features of MailMate include:

• Universal mailboxes: One Inbox for all of your IMAP accounts.
• Extensive keyboard control: Switch mailboxes or move messages using the keyboard only.
• Advanced smart mailboxes: Make any/all combinations of other (smart) mailboxes and use any/all combinations of matching conditions.
• Link-searching: Search for related messages using search links.
• Dynamic signatures: Default signature based on the history of sent messages.
• Notifications: Multiple dock/menu bar counters and Growl notifications.
• Mailing list support: Mailing list messages are automatically organized in smart mailboxes.

Minimum Requirements:

• Mac OS X Version 10.5
• IMAP server(s) with support for the UIDPLUS extension

Located in Copenhagen, Denmark, Freron Software was founded in 2010. Freron Software is a small software company developing and selling MailMate, a Mac OS X email client for IMAP.

MailMate now supports creating, deleting, and renaming IMAP mailboxes. IMAP does not support mailbox renaming which means that in practice it is implemented by creating a new mailbox, moving the messages, and then deleting the old mailbox. The same strategy is used to support drag’n’drop move/copy of IMAP mailboxes.

Important: The support for local files will soon be removed completely. If you have any messages in mailboxes under “SOURCES/Local” then you should move them to IMAP locations as soon as possible.

New features and changes include:

• Images and files pasted in the composer are attached to the message.
• “Forward as Attachment” implemented.
• When replying to a message sent from yourself, the from/to/cc fields are left unchanged.
• Scrolling using space now works when the message view is in focus. Skips to next message when scrolled to the bottom of a message.
• Improved completion in address fields. In particular, the handling of commas now works correctly.
• Numerous other changes and fixes which can be seen in the detailed release notes within MailMate.

The focus continues to be on making MailMate ready for a 1.0 release, but new features are still being added. See the detailed release notes within MailMate. Here is a short overview:

• New interface for importing messages.
• Configurable default set of columns for the messages outline.
• Added “is not within last” as a new date comparison method (for example “Date is not within last 3 days”).
• Added “Any Address” as a shorthand for making comparisons with any address (from, to, cc, bcc).
• Mailbox outline font is now (also) configurable.
• …and a slew of minor additions, changes, and bug fixes.

Detailed release notes are included with the latest update. Most of the changes are minor features or bug fixes. Note the new application icon and the new widescreen layout (previously described in a blog post).

MailMate has entered the final phase before the 1.0 release. Please report any serious issues with the current version of MailMate. Do not expect any new features until after the 1.0 release where development will continue with regular updates (similar to the 0.9.x updates).

Update 12/2011: The manual has a short updated chapter on this subject.

The latest version of MailMate is the first one to support automatically inserted signatures. This includes configurable top/bottom placement of signatueres. In the following, I will describe how it works in MailMate which is not how it works in most email clients.

Automatically inserted signatures is one of those features which sounds really nice on paper, but rarely works well in practice. I never continued to use this feature in other email clients and the main reason was that I most often replaced the inserted signature with something else. One problem was that my default signature was a relatively long signature which was appropriate for a new email or a first reply. In practice, most of my emails were to people I knew very well where I did not want to include an impersonal signature, but I did not even use the same signature for all of these people. In the end, it was easier to have no signature inserted and then use a text expander instead.

How it usually works

In many email clients, a selection of signatures can be configured. For example, Thunderbird supports a single signature for each identity/account and Apple Mail supports multiple signatures for each account. A signature is inserted into new emails and it may then be possible to manually select a different signature (Apple Mail). The placement of the signature (top or bottom) is a separate preference option.

How it works in MailMate

MailMate takes a different approach to the problem. The choice of default signature is based on the main recipient of the email rather than the account/identity used. MailMate simply looks for the most recent email to the same recipient and reuses the choice of signature. The same is done for the choice of top or bottom posting. Changing these choices will then affect any future emails to the same recipient since the email will become the new most recent email. If no previous email exists (with a choice of signature) to the recipient then MailMate falls back to choosing the most often used signature sent using the same identity.

Example: After using this system for a while, I’ll be able to have my preferred signature and signature placement chosen by default in all of the following cases (using a single identity) as long as older messages to the same recipients exist:

• An email to a family member has a short, personal signature, and uses bottom posting.
• An email to a business relation has a formal signature and uses top posting for those who insist on such usage.
• An email to the MailMate bug-tracker has no signature and uses top posting.
• An email to a recipient of Danish origin (and therefore written in Danish) has a signature in Danish.

The list could be much longer and it does not involve any configuration other than explicitly selecting a signature and top/bottom placement for any emails where the default choices are not desired.

Auto-learning features as the above can be difficult to implement such that it works as expected for all users. Therefore, feedback is very welcome on the subject of improving the choice of default signature.

Note that MailMate does handle the following caveat: If you change one of your existing signatures, for example by updating a phone number, then this will work as expected even when the signature is used in a new email where previous emails to the same recipient uses a signature with the old phone number.

Detailed release notes are included with the latest update (and automatically shown at startup). Here is a very condensed version:

• Redesigned composer window.
• Advanced support for signatures and top/bottom posting.
• Support for Growl notifications.
• Crash reporter added which offers to send MailMate related crash reports on startup (anonymously if preferred).
• Numerous minor features and bug fixes.

Please report any bugs you find (especially crash bugs). MailMate is closing in on a 1.0 release.

MailMate now uses $Junk and $NotJunk IMAP keywords to control when resources (most often images) are allowed to be fetched from external URLs. When fetching is blocked, a special view is shown stating the reason and the number of resources blocked. Various options are then available including fetching the external resources once (“Load Once”). By default MailMate is quite restrictive. External references are blocked for a message if one or more of the following is true:

• It is in a junk mailbox
• It is marked $Junk
• It is in an Inbox or in a mailbox for deleted messages without the $NotJunk keyword.

Moving a message in/out of a junk mailbox automatically enables/disables the $Junk keyword.

Note that various email clients use variations of the $Junk/$NotJunk keywords. MailMate uses the keywords which have quite recently been formalized. For more information:

• IMAP Keywords
• Description of junk flags

Other changes in this update:

• Files can now be attached using a file panel (⇧⌘A).
• Added the special IMAP Recent state to the default set of counters.
• Various IMAP related bug fixes. See the release notes in MailMate (shown when updating).

Some important bugs were fixed in the latest release of MailMate. If you have ever used MailMate to edit and send messages then you must update MailMate and run it once. Your local cache of sent messages may contain messages which were not correctly uploaded to the IMAP server. Beta 0.9.4 ensures that all messages edited by MailMate are up-to-date on the server.

Other bugs were fixed as well including one which prevented many users from sending messages. Read more in the release notes shown when launching MailMate.

Changes include an experimental general Show/Hide system for layouts. Defaults have been added for the mailboxes view and the message view. In other words, it is possible to reduce MailMate to an outline of messages (and still change the current mailbox or move messages using the keyboard shortcuts ⌘T and ⌥⌘T). Look in the “View ▸ Layout” menu for this feature.

Also note:

• New column for the messages outline with the “state” of a message. Turned on by default for the Drafts mailbox. When sending a message, the state is a progress indicator. Moved the now functionally obsoleted Outbound mailbox to the set of default example mailboxes.
• New General preference option for selecting the default email composer (for “mailto:” links).

The standard look of plain text messages in MailMate is quite simple. White background, black unquoted text, and bluish colors for quoted text with vertical lines on the left to show the quoting level. The font can be changed using the font panel (“Format ▸ Show Fonts”), but this is the only customization available in the graphical user interface. Just like Apple Mail and many other email clients, MailMate uses HTML to display messages – even when the messages are plain text. The HTML generated by MailMate uses a stylesheet (CSS) and this is where the fun starts, because MailMate also looks for additional styling in a user provided stylesheet. This stylesheet must be located at the following path:

~/Library/Application\ Support/MailMate/Resources/MmMessagesWebView/stylesheet.css

To get an idea of what can be done in this stylesheet, you should take a look at the basic stylesheet in the resource files of MailMate:

MailMate.app/Contents/Resources/MmMessagesWebView/stylesheet.css

In particular, you should note how to customize the various quoting levels. Also note the separate style sheet (rawStylesheet.css) used for displaying raw messages (⇧⌘U) or generated HTML (⌃⌘U). This stylesheet can be augmented as well.

The following image shows what can be easily done using a custom stylesheet with very limited CSS skills. I encourage you to experiment yourself and then please share it with us.

Now, if you are like me, you are going to be annoyed by messages which are basically plain text, but for some reason still contains an HTML variant. The HTML is unlikely to look as good as messages shown with your own brand new custom stylesheet. Fortunately, most messages adhere to the standards and also contain a plain text variant. By default MailMate shows the HTML variant of a message if it exists, but you can change this by going to the Terminal and write:

defaults write com.freron.MailMate MmPreferPlainText -bool YES

The downside of this is when you would really like to see the HTML variant. Therefore it is important to know that you can always shift between the alternatives manually using ⌥⌘[ and ⌥⌘] (“View ▸ Message Body Parts”) – and note that your choice is remembered.

Digression: While experimenting with custom stylesheets I created a custom layout for the composer window which contains a message view as well as the editor. The message view is updated whenever the message is saved and works as a previewer for the composed message. Read more about custom layouts in the blog post about a widescreen layout.

Update 14/12-2010: The custom layout has been updated to work with the current version of MailMate.

It is now possible to keep an eye on MailMate using Twitter. New releases and blog posts are going to be advertised on Twitter. Questions are also answered, that is, answered as well as possible within the character limit.

An issue tracker for reporting bugs or for making feature requests is now available for MailMate. The “simple” URL is https://tracker.mailmate-app.com/tickets, but it is going to redirect to a page hosted by Lighthouse.

Version 0.9.2 of MailMate has just been released. You could try it out now and then report any problems by creating tickets in the issue tracker.

If you are looking for a simple bug/issue-tracker for public and/or private usage, you should definitely take a look at Lighthouse. It is even free to use for small projects. And while you are at it, also take a look at their sister product Tender Support. Both of these services can be controlled via email which is of course perfect for a developer of an email client.

Recently, a beta tester asked whether a widescreen layout had been considered for MailMate. A widescreen layout has the message view to the right of the messages outline instead of below. The short answer would be no, but the long answer is better: It is possible to create such a layout yourself.

Unfortunately it is mostly undocumented and creating layouts is only going to be for expert users for now. The following should be considered a very short description of how it works for those who would like to experiment with layouts themselves. If you just want to know how to get a widescreen layout in MailMate then jump to the bottom of this post.

MailMate currently has 3 kinds of windows which can have custom layouts:

• Mailboxes: The main window of MailMate (⌥⌘N). Currently there are 4 layouts available which can be seen in the “View ▸ Layout” menu. One of these is the default three-pane layout which is how most email applications are designed.
• Message: The window used to display a single message (⌘O). Currently no alternative layouts available.
• Composer: The window used when editing a new message (⌘N, ⌘R or ⇧⌘F). Currently no alternative layouts available.

The existing layouts are specified using the property list format and they are all located in the following folder:

MailMate.app/Contents/Resources/Layouts/

Each type of layout has its own subfolder. If you want to try to make a custom layout you should base it on one of these files. They are the only real documentation of the format for now.

Custom layouts must be placed at the following location (using the appropriate subfolder):

~/Library/Application Support/MailMate/Resources/Layouts/

In short, a layout is specified as a tree where each node corresponds to a view controller which is created by MailMate based on the viewerType specified for the node. Various key/value pairs can be specified for the nodes. Some are supported by all kinds of nodes and some are only supported by specific nodes. In particular, the only nodes which can have children are MmSplitView and MmBoxView.

Note that all of the above may change in future versions of MailMate. It should be considered an experimental feature. That said, if you make any interesting custom layouts, you are most welcome to share them with us and the rest of the world.

Now back to the initial question. To get a widescreen layout (as an option in the “View ▸ Layout” menu) you should download this file and copy it to the following location (creating the folders as necessary):

~/Library/Application Support/MailMate/Resources/Layouts/Mailboxes/

You must restart MailMate to make the layout available.

Updated October 25th: Changed the example file to include the view to be displayed when blocking images.

Update 12/2012: The manual has a short updated chapter on this subject.

MailMate encourages the use of a single mailbox for archiving messages (for each IMAP account). This concept is similar to the All Mail mailbox in Gmail (Googles free webmail service) and one might think that Gmail would be a perfect match for MailMate since Gmail supports the IMAP protocol. Unfortunately that is not quite the case. The main reason is how they chose to map the concept of labels in Gmail to some representation in the IMAP protocol. IMAP does support so-called flags, but this was probably not well supported in many clients and it would require users to manually setup smart mailboxes for all Gmail labels in order to actually view them as mailboxes like in the webmail interface. Google chose a different approach which can be best described as a hack.

Each label in Gmail becomes a real mailbox when accessing the messages via IMAP. Existing email clients do not expect this and the result is that each message is fetched multiple times, once for each of its labels. Even if not using labels, the problem persists since every message in Inbox, Sent Mail or Drafts are also located in All Mail. In MailMate it becomes even worse because of the special All Messages mailbox which is going to include all the duplicates.

There are other issues when accessing Gmail via IMAP, but the purpose of this blog post is to simply state what I currently consider the most sensible settings in MailMate for a Gmail account. Unfortunately part of this means that you are not going to be able to access labels within MailMate.

• Edit the subscriptions of the Gmail account such that the following mailboxes are unsubscribed: [Gmail]/All Mail, [Gmail]/Starred and all labels.
• Create a mailbox in the webmail interface named [Gmail]/Archive.
• Map Gmail standard mailboxes to the standard mailboxes of MailMate. This is done by default for new Gmail accounts in MailMate (probably only works for the English language, but this is untested – UPDATE 28/8-2011: should work for all accounts now). You can also do this manually, e.g., select the [Gmail]/Drafts mailbox and open the context sensitive menu where you can set the mailbox type to Drafts. Do the same for all of the other standard mailboxes.
• Create a filter in the gmail interface which automatically labels any new incoming messages with the [Gmail]/Archive label. UPDATE: This is not a good solution since it is going to result in duplicate messages in MailMate (Inbox and Archive). Alternative ideas are welcome.

Apart from missing labels, the main problem with the above is that you can no longer access messages which are only in the All Mail mailbox. To be able to access these you need to mark them all with the [Gmail]/Archive label. This can be done as follows within the webmail client:

• Mark all conversations in All Mail as [Gmail]/Archive.
• Remove the [Gmail]/Archive label from all messages in the Inbox and any other standard mailboxes (not those in Starred!)

If your actual use of labels is to use them as mailboxes, i.e., at most one label per message then you can still subscribe to them. Such messages should not have the [Gmail]/Archive label.

Note that Gmail has a so-called lab (experimental features) which provides a few more IMAP configuration options. It is named “Advanced IMAP Controls”. You do not need this to make the above work, but it could be useful for other email clients.

I am proud to present the first public beta release of MailMate — a brand new email client for Mac OS X. You can read more about current and missing features on the main page. Please make sure to read that before downloading MailMate.

This is an early beta release and at the time of writing only 4 people have ever tried to install and use MailMate. You could be MailMate user number 5 and any feedback from you is going to be greatly appreciated. To provide feedback, you can either join the mailing list or use the “Help ▸ Send Feedback…” menu item inside MailMate.

Disregarding any bugs, MailMate may still not be ready to be your primary email client. In its current state though, it would still be a very useful complement to any other email client. If you use it as a complement to Apple Mail then note that you can find the currently displayed message using the “Message ▸ Open in Apple Mail” menu item in MailMate.

The short term goal for MailMate is a stable 1.0 release with most of the missing features described on the main page, and hopefully a few new exciting features as well.