 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Applications / Firefox / Mozilla / November 2003Attachments sent from Moz 1.5 on Mac are unreadable by AOL (appledouble MIME encoding)
This all started when I sent a piece of mail to some AOL friends with a MS-Word attachment. The attachment showed up as not readable. It turns out the problem is as follows: When an HTML email is sent from the PC (with the "HTML only" option), the email has the typical MIME parts for the attachment: > Content-Type: multipart/mixed; > boundary="------------030900060706010701060603" > ... > This is a multi-part message in MIME format. > --------------030900060706010701060603 > Content-Type: text/html; charset=us-ascii > Content-Transfer-Encoding: 7bit > ... > --------------030900060706010701060603 > Content-Type: application/msword; > name="ONCAdNov03.doc" > Content-Transfer-Encoding: base64 > Content-Disposition: inline; > filename="ONCAdNov03.doc" But when sent from the Mac, the attachment includes the Mac "resource fork" (extra data file describing the what's in the actual MS-Word file on the Mac OS). It looks like Moz creates a 2 part MIME structure using nested MIME parts: > Content-Type: multipart/mixed; > boundary="------------070807080502030209000506" > ... > This is a multi-part message in MIME format. > --------------070807080502030209000506 > Content-Type: text/html; charset=us-ascii > Content-Transfer-Encoding: 7bit > ... > --------------070807080502030209000506 > Content-Type: multipart/appledouble; > boundary="------------ad010607060302090207060508"; x-mac-type="5738424E"; x-mac-creator="4D535744"; > name="ONCAdNov03.doc" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename="ONCAdNov03.doc" > ... > --------------ad010607060302090207060508 > Content-Type: application/applefile > Content-Transfer-Encoding: base64 > ... > --------------ad010607060302090207060508 > Content-Type: application/octet-stream; name="ONCAdNov03.doc" > Content-Transfer-Encoding: base64 > Content-Disposition: inline; filename="ONCAdNov03.doc" This is saying a MIME part described as "multipart/appledouble" contains two nested MIME parts. An "application/applefile" MIME part (the resource fork) and a application/octet-stream MIME part (the MS-Word file) FYI, the 2nd example email here is not readable by AOL. The attachment shows up as a .mim file, which means AOL punted because it didn't know what to do with the MIME structure, and just put all the extra MIME parts into the .mim file. There's a "resolved" bug number 133004 for this at bugzilla.mozilla.org. One of the comments for that bug says: "We use internet config to determine if we need to send an attachment as appledouble or not" Does anybody know what this "internet config" is? Is anybody else having this problem? Is this nested appledouble MIME encoding behavior acceptable. Ie. *should* AOL be able to handle this sort of MIME encoding? -- Ben in DC PublicMailbox@benslade.com (put 030516 anywhere in the subj to get thru) "It's the mark of an educated mind to be moved by statistics" Oscar Wilde > Is this nested appledouble MIME encoding behavior acceptable. Ie. > *should* AOL be able to handle this sort of MIME encoding? Yes, it should. Just like it should handle nested multipart-mixed, for example.... -Boris Ok, two questions then.. 1) There are lots of "it should handle it" cases with email, but how common is it to find mail systems which don't handle it. 2) What resource fork file? When I use a "ls -al" command to look at the file I see no resource fork file. Looking at the Apple web page: Mac OS X > System Overview > The File System > Resource Forks http://developer.apple.com/documentation/MacOSX/Conceptual/SystemOverview/FileSy stem/chapter_8_section_5.html I see the following statement: > Files residing on HFS and HFS+ file systems have their Finder attributes > stored in a private fork separate from both resource and data forks. ... > Apple strongly encourages developers to use file extensions as > alternative means for identifying document types. So what I'm wondering is, was there a resource fork file to attach in the first place? Looking at the original MIME structure, I notice that the MIME part for the apple resource fork has no filename. Should a nested MIME structure be setup for a Apple resource fork file when the new OS X filesystem (HFS) doesn't use them? And when Apple recommends developers use the file extensions to identify document types? Ben in DC >> Is this nested appledouble MIME encoding behavior acceptable. Ie. >> *should* AOL be able to handle this sort of MIME encoding? [quoted text clipped - 3 lines] > > -Boris > 2) What resource fork file? When I use a "ls -al" command to look at > the file I see no resource fork file. ls is a unix command that in the basic configuration doesn't know didly about resource forks. Take a look at these two links: http://www.macosxhints.com/article.php?story=20030409060740180 http://www.macosxhints.com/article.php?story=2002022409532098  SignatureBjarne D Mathiesen http://mozilla.mathiesen.info København N ; Danmark ; Europa ----------------------------------------------------------------- denne besked er skrevet i et totalt M$/Intel-frit miljø MacOS X 10.2.8 Jaguar ; Mozilla 1.6a ; PowerPC G4 800MHz Wow, so if I do a "ls myfilename/rsrc" I can see the hidden resource file that gets sent by Mozilla along with my MS-Word doc. Is there anyway to remove the resource file so I can send the MS-Word doc to AOL and avoid the extra MIME formatting that makes AOL choke? I tried FTP'ing the file back to a new location in my Mac, but no joy. I guess I could try mounting my PC as a remote SMB filesystem and moving the file over there. What a hassle. Thanks in advance Ben in DC >>2) What resource fork file? When I use a "ls -al" command to look at >>the file I see no resource fork file. [quoted text clipped - 5 lines] > http://www.macosxhints.com/article.php?story=20030409060740180 > http://www.macosxhints.com/article.php?story=2002022409532098 > Wow, so if I do a "ls myfilename/rsrc" I can see the hidden resource > file that gets sent by Mozilla along with my MS-Word doc. [quoted text clipped - 3 lines] > > I tried FTP'ing the file back to a new location in my Mac, but no joy. You can just remove them from the terminal using the /rsrc addendum with the rm command. Also, if you just do the normal Unix mv and cp commands the operations *doesn't* take the resource fork into account and you loose it. Then there's FileBuddy - http://www.versiontracker.com/dyn/moreinfo/macosx/11688 - that amongst it's tool has options to remove eithe branch - resource or data - from a file. The ftp-programs that you get for Mac OS X normally do know about both data and resource forks, so they do the right thing and look at whether the receiver can handle both forks or not. SignatureBjarne D Mathiesen http://mozilla.mathiesen.info/ København N ; Danmark ; Europa ---------------------------------------------------------------------- denne besked er skrevet i et totalt M$/Intel-frit miljø MacOS X 10.2.8 Jaguar ; Mozilla 1.6a ; PowerPC G4 800MHz Hmmm, the Unix commands seem to know about the rsrc forks and prevent me from removing them (on my OS X 10.2.8 system): > [ObiwansMacInDC:~/Projects/OurNationsCapital] myusername% ls ONCAdNov03.doc/rsrc > ONCAdNov03.doc/rsrc [quoted text clipped - 6 lines] > [ObiwansMacInDC:~/Projects/OurNationsCapital] myusername% sudo rm tmp.doc/rsrc > rm: tmp.doc/rsrc: Operation not permitted I guess I'll take a look at filebuddy. Ben in DC > You can just remove them from the terminal using the /rsrc addendum with > the rm command. Also, if you just do the normal Unix mv and cp commands [quoted text clipped - 9 lines] > data and resource forks, so they do the right thing and look at whether > the receiver can handle both forks or not. Forgive me for replying to myself, but it looks like the "cp" operation *did* work. Yes, the ls command below shows a rsrc file for the newly created tmp.doc file, but the rsrc file is zero length and Mozilla ignores it, creating a nice normal non-nested MIME part for the MS-Word attachments. The filebuddy program was useful in figuring this out. Thanks for your help. Ben in DC > Hmmm, the Unix commands seem to know about the rsrc forks and prevent me > from removing them (on my OS X 10.2.8 system): [quoted text clipped - 30 lines] >> data and resource forks, so they do the right thing and look at whether >> the receiver can handle both forks or not. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.