@Jeremy Kinsey: I completely agree.
Actually, it gets worse: differences arise between composing a plain text message which has only an image attachment and the same message with a second attachment of another format (e.g. PDF):
- The body of the first message is structured as etresoft described above (i.e. utilising a non-plain text/HTML alternative).
The body of the second message (plain text with both image and PDF attachments) is
multipart/mixed
and contains exactly three parts: the text/plain
message, the image/jpg
attachment (Content-Disposition: inline
) and the application/pdf
attachment (Content-Disposition: inline
).
The latter encoding is that which one would expect from a genuine "plain text" message. The fact that Mail.app uses it in these circumstances (and simple
text/plain
encoding of the entire body for plain text messages with no attachments) causes me to doubt the explanation etresoft provides above (i.e. that Mail.app "always" encodes messages as HTML for reasons of compatibility). I see no reason why Mail.app cannot also use this encoding for messages containing only image attachments.
It is interesting to note that all MUAs (except Mail.app) with which I have tested such messages render the second message with separate 'attachments' whilst (unsurprisingly) the first message has an 'inline' image: I imagine this is because, despite the specified Content-Disposition, it is ambiguous what should be done with inline attachments in such circumstances.
However, since Mail.app still renders these attachments inline, the desired fix would be to use the second form of encoding together with
Content-Disposition: attachment
.
I found the following article on Micah Gilman's blog:
Disable Mac Mail.app Inline Image Attachments
Therein he observes that one can change the behaviour of Mail.app by right- (or ctrl-) clicking upon an attachment and choosing "View as Icon" (or "View in Place" to undo). Furthermore, he describes how to force Mail.app to always "View as Icon":
$ defaults write com.apple.mail DisableInlineAttachmentViewing -bool yes
Sadly, this only affects the UI: i.e. there is no change to the
Content-Disposition
irrespective of the selected view.
Such inconsistency is confusing and highly undesirable: when sending messages, one has a reasonable expectation that recipients will see the messages in a similar fashion to how one sees them oneself. There is little doubt in my mind that this is also a (somewhat separate) bug.
As regards whether these issues are "features" or "bugs" (don't software companies just love to tell their users that their product is doing everything right, but the user is using them wrong? the manner in which one holds a certain telephone handset springs to mind...) seems to me to be nothing more than semantics. A feature is only useful if it is desired by the product's users; and a bug is a behaviour which is not desired by the product's users. Any misalignment of those definitions simply means that the user's/functional requirements have been misunderstood or misinterpreted when producing the product's technical specification.