thoughton:digitallife Mail.app nightmare over

Mail.app nightmare over

Back in April, I posted a rant about Mail.app's handling of inline images. The gist of my tirade was that Mail.app insisted (nothing's changed - it still does) on displaying images inline, rather than as attachments. The problem here is that messages with inline images or PDF documents take an age to open. This glacial response time is infinitely more aggravating when there are several such emails to open in succession (for instance when searching for one particular image out of dozens emailed to you). Mail.app does offer you the ability to right-click an image and choose 'display as icon', but close and re-open the email and you'll find that Mail.app will blithely continue to display the image as if you'd never told it otherwise. Even worse, there is no global preference to alter this behaviour.

This glaring tidbit of user-interface idiocy is particularly frustrating for me since I was a long-time Eudora user prior to the arrival of Mail.app and Eudora has always, for at least a decade, clearly distinguished between inline images and attachment images. Those of you who have never used any email client other than Mail.app may wonder what I am blithering on about. The basic explanation is that 'inline' should mean that the image is displayed along with the text of your email, whereas an 'attachment' should properly be an image (or other file) that is sent with the email as a file attachment but is not displayed with the text of your email.

The 'official' description of the difference between 'inline' and 'attachment' can be found in this RFC document, the relevant part of which is:

2.9 Content-Disposition and Multipart

If a Content-Disposition header is used on a multipart body part, it applies to the multipart as a whole, not the individual subparts. The disposition types of the subparts do not need to be consulted until the multipart itself is presented. When the multipart is displayed, then the dispositions of the subparts should be respected.

If the `inline' disposition is used, the multipart should be displayed as normal; however, an `attachment' subpart should require action from the user to display.

If the `attachment' disposition is used, presentation of the multipart should not proceed without explicit user action. Once the user has chosen to display the multipart, the individual subpart dispositions should be consulted to determine how to present the subparts.

Thus concludes Mac History 101.

"So", I hear you ask, "why are you moaning about this again?". Despair not dear reader - there is a solution! I have recently discovered that I am not alone in my Mail.app nightmare. Adam Nohejl of Czech outfit Loki Software must have been a fellow resident of inline-hell, but unlike yours truly he actually did something about it, writing a wonderful piece of $6 shareware named Mail Attachment Iconizer. This program does one thing only, and by God does it well. Simply fire up the installer and Mail Attachment Iconizer will modify your copy of Mail.app and forever turn those inline images into image icons. Double click 'em and they expand into images or PDFs; double-click a second time and they revert to icons. Apple - are you watching? This is the way it should have been done from the start. :mad:

For those of you wondering why I switched from Eudora in the first place if it was so damned wonderful, the answer is that Eudora at the time did not make the transition to OS X very well and wasn't updated for at least two years. It also didn't have Mail.app's tight integration with Address Book and the iLife apps. Not to mention the fact that Mail.app is free, whereas Eudora requires an annual (annual!) payment for the ad-free version.

Posted on 17 November 2005, to Apple | Bereft of Reason | How To... | Internet | Mac OS X