Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

How can I prevent mail attachments embedding when sending mail

In Lion when I send out an image - the recipients are receiving them as embedded images instead of simple attachments. I know in previous version of mail, having windows friendly attachments enabled solved this, but it doesnt seem to be helping in Lion mail.

MacBook Pro, Mac OS X (10.7)

Posted on Jul 25, 2011 1:47 AM

Reply
221 replies

Oct 25, 2011 10:32 AM in response to etresoft

Etresoft, that is not the issue I am reporting or that anyone here is reporting. The issue is that people have to right click the picture and save as.


This is not the future or the past. In fact, it is unusual and not the norm for all mail clients released in the past couple decades!!!


This "glitch" is a failure of the right click menu "save as" to sometimes appear, which is a separate issue.


So I say again, WHEN WILL WE HAVE A FIX FROM APPLE???

Oct 25, 2011 1:50 PM in response to Jeremy Kinsey

> The issue is that people have to right click the picture and save as.

That is just the way Microsoft designed it. Apple has no control over that. Ask Microsoft to add a "Save attachments" button like Apple Mail has.


> This is not the future or the past. In fact, it is unusual and not the norm for all mail clients released in the past couple decades!!!

This is a standard e-mail messaging protocol developed by Netscape, then adopted by Microsoft, and finally, last of all, supported by Apple.


> So I say again, WHEN WILL WE HAVE A FIX FROM APPLE???

Never. If you don't like the way Apple Mail composes e-mail messages, you can add additional software such as Attachment Tamer to Apple Mail or you can use some other e-mail program such as Thunderbird or Outlook.

Oct 25, 2011 2:37 PM in response to etresoft

Its pretty obvious to me that you have not read this thread in its entiretly and do not at all understand what I am saying.


Perhaps you'd care to tell me why it sends an html embedded image when you tell it to send as plain text. How is that not a bug?


Or am I still talking to a brick wall?


If you tell it to send plain text, then you clearly want it to be an attachment, not an inline embedded image. What on earth is so difficult for you to understand about that.


Sometimes I think the Apple loyalists are so blinded by their inate utopian ideological belief in self perfection that they are unable to see reality.

Oct 25, 2011 3:19 PM in response to Jeremy Kinsey

This thread is identical to the 20 others on the same topic.


If you notice in the Apple Mail menus, it doesn't say HTML anywhere. It says rich text format and it says plain text format. Those options only control how the text appears, they have no effect on how the message is constructed internally. Internally, Apple uses the HTML-based multipart/related architecture because it is best able to convey the structure of the message the way the author intends. Apple chose this method for one overriding reason - because that is what Outlook uses.


There are other ways to structure e-mail messages. Other e-mail programs and older versions of Apple Mail allow more control over that aspect. The problem with that strategy is that it makes the email program harder to use. Using a method other than multipart/related will fix this problem, but it will also trigger a different set of bugs in old versions of Outlook. In this other set of bugs, the hapless Outlook user can't see the attachments at all - or even some of the text content. Rather than ask users to try to pick an internal MIME structure appropriate for whatever obsolete version of Outlook a recipient happens to have, Apple chose to use a method that has the best chance of appearing on any recipient's screen the same way it looked on the sender's screen. Saving the attachments is not a requirement and is out of scope of the context of the composer.


The changes in the Lion version of Apple Mail are not bugs. Whether you like them or not, they are working as designed. It is different now. I suggest you encourage your recipients to upgrade. If you don't want to do that, you can buy Attachment Tamer to make Apple Mail regain some of its lost complexity. If you don't want to do that, you can use some other e-mail program. If you don't want to do that, your only remaining option is to just deal with it.

Nov 1, 2011 9:26 AM in response to etresoft

@etresoft: I'm not too sure how this discussion became about the MIME type of the message body (e.g.

multipart/related
etc.). The issue is solely about the Content-Disposition of certain message parts.


That is, Mail.app could quite easily (and without giving rise to any compatibility issues) specify the

Content-Disposition
of images to be
attachment
rather than
inline
(just as it does for most other file formats): recipients' MUAs would then present such images to their users as "proper" attachments (as desired), rather than as inline images.


Indeed, this is not only what most other senders' MUAs (including earlier versions of Mail.app itself) do in order to achieve that outcome (something many posters have observed), but furthermore it is what "Attachment Tamer" does to "fix" this rather unusual behaviour in Mail.app.


The point is that recipient MUAs are doing exactly what they should by rendering attachments inline when their

Content-Disposition
has been specified by the sender's MUA as such. However, having an inline disposition is not the behaviour desired by the sender.


I would venture that this is worse than an inconvenient "feature": to my mind, it is clearly a bug because images are included "inline" even in a plain text message (which really ought not to have any notion of "inline" parts, despite the

multipart/related
MIME type enabling such by breaking the message text around inline parts). This is undesirable and non-standard (although I accept it probably doesn't violate any RFCs).


If Apple wish for Mail.app users always to see images rendered inline, then they can choose to do so as a UI feature by ignoring any specified

Content-Disposition
. But there is absolutely no reason for that behaviour to be forced on others by encoding it into the message structure. Indeed, doing so is a violation of the Robustness principle (as is evidenced by your observation that "this thread is identical to the 20 others on the same topic": the behaviour has demonstrably broken things from a user's perspective).

Nov 1, 2011 11:32 AM in response to nickety

It is not a bug because it is the behavior that Apple intends it to have. You may not like that behavior, but that is a matter of preference. You can always submit feedback to Apple and recommend they change it. Until that happens, and there is no guarantee that it will, your only option is to use some other email program. Complaining will not help. If you use the software but complain about it, you are still using it. Apple won't take notice until people stop using it. If enough people stop using it, Apple will either change it to be more popular or drop it altogether - their choice.

Nov 1, 2011 11:50 AM in response to Jeremy Kinsey

@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):


  1. The body of the first message is structured as etresoft described above (i.e. utilising a non-plain text/HTML alternative).


  2. 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.

Nov 1, 2011 11:50 AM in response to Jeremy Kinsey

Apple develops the software they want. If they focused on developing the software that most people wanted, they could just merge with Microsoft. No one is forcing you to use Apple Mail. If you don't like it, tell Apple and don't use it. If that bothers Apple, they will change how it works.


You are correct. I don't see what the problem is. There are a number of different e-mail programs to choose from. You are the consumer, not the developer. You don't have the power to tell the developer how to work. All you can do is choose a different product. You can complain, but this is a pointless venue for such complaints. This is a tech support forum. I can suggest 3rd party plug-ins such as Attachment Tamer but I can't change the way Apple Mail works either. If you want to "send a message" to Apple, this is not the place. They aren't listening here. Tell them on their feedback page.

Nov 1, 2011 1:08 PM in response to Jeremy Kinsey

If you "routinely send and receive attachments of every sort from every OS version and mail application out there", then why are you complaining so much when one specific e-mail program on one specific version of one specific operating system doesn't work the way you want?


What will it take to convince you that the way Apple Mail works in Lion is exactly, precisely the way Apple wants it to work? I get that you don't like it. There are at least dozens of people who don't like it. Fine. Then why do you persist in using software that you don't like? That's the real mystery here.


Have you actually sent any feedback to Apple? You can insult me all you want, but you are just wasting your time.

How can I prevent mail attachments embedding when sending mail

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.