[hudson1]

I've searched high and low for a solution to this perpetual problem but so far, I've not found it: I've never found out why whenever I send a JPG file (such as a picture from my digital camera) using Mail as the client, no one who uses AOL (both Mac and Windows) can view the image.

This seems like the most basic of functions so I have to think that it should work. All non-AOL users can view the image as expected. When I send the image from the web interface for my mail system, AOL users can receive the images just fine then. If I remember correctly, I once tried to send an image to AOL users with Eudora as the client and this worked, too (I didn't care for Eudora otherwise).

This seems to be pretty conclusive evidence that the problem resides in Mail. One would think that Apple would have been on this problem from the start and fixed it long ago--or there's something that I'm doing wrong in Mail from my end.

Any thoughts?

[pat++]

I would say the problem is on AOL side. It's probably not related, but do you use rich text or plain text to send messages?

My guess is that Mail sends both the image itself and resources fork. This may confuse the mail AOL client...

[mrtew]

Yeah, I believe it's because AOL see the Mail jpg as two files.... the resouce and data forks and when it recieves a file with multiple attachments it compresses them into a mime file. There are two workarounds to this lame problem that I know of. The AOL user can uncompress the mime file with a program called WinZip (I guess this only applies to M$ AOL users), but if someone is computer savy enough to download and use this program then they are smart enough to dump AOL and get a real IP. The other thing you can do is get a little utility from versiontracker that will 'strip' off the resource fork of your images before you send them so Windows users will only get one file instead of two. Even non-AOL users see a second file, the resource fork, that they can't open and they think everything from 'incompatibility' to 'incompetence' to 'virus'. Apple is soooooooo LAME not to have fixed this problem by now. I just can't say it enough.... Apple is lame lame lame!

[kovacs]

Originally posted by mrtew:
The other thing you can do is get a little utility from versiontracker that will 'strip' off the resource fork of your images before you send them so Windows users will only get one file instead of two. Even non-AOL users see a second file, the resource fork, that they can't open and they think everything from 'incompatibility' to 'incompetence' to 'virus'. Apple is soooooooo LAME not to have fixed this problem by now. I just can't say it enough.... Apple is lame lame lame!

What is the name of this app?

[hudson1]

Thanks everyone for your follow-ups. I've done some more testing to identify the root cause and I think I have a handle on it now.

Yes, as has been mentioned the problem seems to stem from the inclusion of the resource fork but this isn't entirely clear, either. It's still more complicated than that because, IIRC, Eudora was able to send an image that AOL could handle but when sent with Mail it failed (been a while since I did that particular test so there's a chance I'm mistaken). So it appears to be a problem that's caused by a combination of three things: some kinds of resource forks, encoding by Mail, incorrect decoding by AOL.

I say "some kinds of resource forks" because if I take a JPG file, open in Goldberg, do a Save As, and then send it to a Mac AOL user, it was OK. Simply sending the file as it was left by iPhoto didn't work. Go figure and you can see that this is not a straight forward problem.

The easy thing to do (and to answer the poster's question) is to download the utility GrimRipper. This is a contextual menu plugin that will strip a resource fork from a file. What I most recently did was make a duplicate of a JPG image as saved by iPhoto and then easily stipped the resource fork from that duplicate with a "right click". That file was attached to an e-mail in Mail and sent. The recipient Mac AOL user openned it just file. Without the resource fork stripping, the same user only received a MIME file that was a pile of gibberish.

Hope this can help others.