iPhone Email Attachments – Revisited

iPhone Email Attachments – Revisited

My solution for sending messages via email on the iPhone – detailed here – works for every mail client… except Gmail.

Gmail simply will not let you see embedded images.  Period.

Since this kinda crap really grates on my nerves, I started digging a little deeper.  Plus, I really think there should be a 100% universal way to attach stuff to email messages from the iPhone… and I’m not the only one.  My embedded images solution is workable, but is not wholly satisfying – because it is not a 100% solution.

So, like I usually do when trying to sniff out how a particular piece of web software works without having access to the source, I see what is being sent “over the wire.”  And since I knew that iPhoto on the iPhone WAS able to send an attachment, I sent myself a picture… and then checked the raw message source to see how Apple was doing it.

I sent myself a picture, with no accompanying text, and this is what the “interesting” pieces looked like:

Content-Type: multipart/mixed;
X-Mailer: iPhone Mail (5H11)
Mime-Version: 1.0 (iPhone Mail 5H11)
Date: Wed, 11 Mar 2009 12:13:43 -0400

Content-Type: text/plain;
Content-Transfer-Encoding: 7bit

Content-Disposition: inline;
Content-Type: image/jpeg;
Content-Transfer-Encoding: base64

Notice the Content-Type of “multipart/mixed.”  No real surprise there… just that when you send a message using the Email client launched by an iPhone application, this is almost always “multipart/alternative”.  First “hmmm.”

Secondly, when I used my methodology of using embeded images (<img src=”data:image/png;base64[my data here in base64]”>), this gets cobbled out as

Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

by the Apple Email Client.  By contrast, Apple creates it’s image attachments by doing the following:

Content-Disposition: inline;
Content-Type: image/jpeg;
Content-Transfer-Encoding: base64

So – why not just do the same thing?


I don’t know what MIME boundaries (the “Apple-Mail-1-782786827” above) Apple is using to segregate its constituent email pieces (text, html, images, attachments) ahead of time – and they are generated dynamically by the email client when putting together it’s messages.


If I knew what the boundary tag was, I could fake out the client, create my own inline image, and boogey on down.

Now, even though this does seem like a serious roadblock, it may not be a total loss, because it presents both

  • (a) a possible direction to look (fake out a boundary, unlikely though it may be) and
  • (b) it presents another solution path (go down to the socket level and code my own SMTP alternative, so that I can create the MIME code directly to send out my attachments).

(a) looks to be a total non-starter, as it looks like the boundary is made – in part – of a timer component, and there is no way to guess how long someone will keep the message open before sending to reliably fake this out each and every time.  (b) will absolutely work – provided you are motivated to write this dude.  Looks like a commercial opportunity for a Cocoa Touch class, and I may yet do this.

A final and as yet unspoken work around would be to know how Apple preps an image in their email client before sending, so that it’s Mail.app knows to wrap the image up as an inline attachment.  Unfortunately, I don’t know of anywhere I can look to see how they compose their messages (no view source – dang!).

All in all, this has stimulated me to investigate some additional paths for a problem that I thought I had a reasonable solution for – and for many, I do and did.

Onward and upward.


4 thoughts on “iPhone Email Attachments – Revisited

  1. As you say , the boundary ‘faking’ is a non starter. Unless they used a consistent boundary it’s never going to work, at least in any standard way.

    SMTP of course would work, and there are a bunch of open source libraries than can be dropped in to get this up and going but that doesn’t mean it’s a good solution either…

    Building in SMTP support means the user needs to maintain multiple sets of email credentials and the developer potentially having to trouble shoot the users email settings and different email providers.

    Of course a few apps take this path, but it’s still not a great solution 😦


  2. John,

    Actually, you should be able to get the email credentials / settings from the Mail.app Settings bundle I would think.

    The simple solution would be for Apple to “lift their skirts” and just tell us what to do to make it work.



  3. If you can get the mail credentials then that’s great though I would be really surprised if you could.

    If that was the case I could create an app that did something wonderful and caused everyone to download it but in secret it could be harvesting email credentials and passing them back.

    So what I’m saying if Apple had that opened up it would be a bit security concern in my eyes.

    I think it may just be that the Mail.app url scheme doesn’t support attachments so there is probably no way to get it to function like the photo + mail combination.

    The photo app loads up the mail page inline, so I’d assume it’s not actually calling a URL but calling some mail view controller and passing it the data , similar to the image picker controller.

    This would be what they’d need to do, provide a UIMailSenderViewController or something along those lines to give us a proper interface for sending an email..


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s