User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 When a .dwg file is attached to an email the file attachment is not done correctly by SM v1.1. If you look inside the email as in the sent folder there is an attachment but there is something wrong. The attachment does not show up when normally viewing the sent file or if sent to someone with SM v1.1 (Mac only?). When I sent an email with such an attachment to an earthlink email it got there but was shown with a name of "unknown-0 B" and clicking on this name does nothing when an attached zip of the same file shows correctly and can be saved. Reproducible: Always Steps to Reproduce: 1. Create a "real" .dwg file. (A text file renamed to be a dwg works ok.) 2. Create an email 3. Attach the file 4. Send it. Actual Results: See summary Expected Results: Intact file at the receiving end of the email.

ccing a couple mail people.

David sent me one of his busted messages. It has: Content-Type: multipart/appledouble; boundary="------------ad020609080608020304090604"; x-mac-type="44574720"; x-mac-creator="41434144"; name="test PC.dwg" If I attach the message myself (linux), I get: Content-Type: application/octet-stream; name="test PC.dwg" If I change David's message to use application/octet-stream, the attachment is listed OK. So bug 146382, bug 355142 and bug 307705 seem related. I guess the question is why SeaMonkey is using that content type.

I seem to be running the same SM binary as David. I've sent his message to myself and can't reproduce his error. We need to look at more of the MIME headers than just the header for the attachment. When I send his file to myself, I get: [...] Subject: test Content-Type: multipart/mixed; boundary="------------050009050507090809080604" This is a multi-part message in MIME format. --------------050009050507090809080604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------050009050507090809080604 Content-Type: application/octet-stream; x-mac-type="54455854"; x-mac-creator="74747874"; name="test PC.dwg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="test PC.dwg" QUMxMDE1AAAAAAAGAfw [...] Where is appledouble coming from? Is it a function of having the app that understands DWG files installed? I would think that an unknown type would be treated as application/octet-stream by SM?

(In reply to comment #3) > David sent me one of his busted messages. It has: > > Content-Type: multipart/appledouble; > boundary="------------ad020609080608020304090604"; x-mac-type="44574720"; > x-mac-creator="41434144"; > name="test PC.dwg" Is it wrapped like that, or is the x-mac-creator part correctly folded (indented) in the message source? (Paste is not your friend.) > I guess the question is why SeaMonkey is using that content type. Bug 355142 answers that, does it not? David probably received a message from someone (on a Mac) sending *him* a .DWG file, with multipart/appledouble combined with application/octet-stream; he made some "always do this" association when he opened it, and now the .DWG is associated with the multipart/appledouble. If this scenario is accurate, Tools|Options|Attachments, View&Edit Actions -- look at the association for .DWG, and the "multipart/appledouble" type will be associated with it. Delete that association to fix the problem seen when attaching messages. Is there a more correct MIME type for the .DWG files? application/x-autocad or whatever?

Some more information. This was specifically noticed when a file was sent intra-office. AutoCAD is a Windows only CAD program. They "define" the DWG format. Sort of like MS defines the .DOC format. And they change it, usually in non trivial ways, with every new release which seems to be every two years. For better or worse most CAD programs use this format as a way to trade files. And Illustrator will open them also. So many folks who do NOT have AutoCAD use the format. This issue was NEVER seen before v1.1 so something changed. Prior to this I had two different instances of folks using a v1.1rc saying they had attached one or more files but they had not been sent and did not appear with the email in the sent folder. But since I was told this several days after each incident I wasn't sure it was operator error. And with one of the reports that was the most likely thing to have happened. But now I don't know. And with one of the people involved it was most likely not a DWG file but another type. The likely hood of him sending anyone a DWG file is about the same as me piloting a 747. I'll see if I can track down the email in his sent folder now that I know to look for a large email that doesn't show any attachments.

David, apparently I needed to express comment 5 as a question, directed at you: Look in Tools|Options|Attachments, View&Edit Actions. Is there an entry for .DWG? And if you click 'Change Action', does the phrase "multipart/appledouble" appear on the little window? IF SO, delete that entry. Your problem will be solved for the near term. If not -- I've just rediscovered the Mac-specific bug 364594, which can cause this kind of problem without explicitly setting "Always do this" when an attachment is opened. (In reply to comment #6) > AutoCAD is a Windows only CAD program. They "define" the DWG format. Sort of > like MS defines the .DOC format. Yes, we know; and Microsoft also registered a MIME type for the format: application/msword. I just Googled around and found that Autocad also has one: application/acad Unfortunately, Thunderbird's "hide the MIME type so as not to confuse the users" philosophy makes it difficult to fix this problem; see bug 244618.

(In reply to comment #7) > David, apparently I needed to express comment 5 as a question, directed at you: > > Look in Tools|Options|Attachments, View&Edit Actions. Is there an entry > for .DWG? And if you click 'Change Action', does the phrase > "multipart/appledouble" appear on the little window? > > IF SO, delete that entry. Your problem will be solved for the near term. Uh, what version? I don't see "Options" under the Tools menu. SM v1.1 I don't see it with either a Nav or Email window up. I did look in the Nav helper applications of the preferences and didn't see an entry like that. > If not -- I've just rediscovered the Mac-specific bug 364594, which can cause > this kind of problem without explicitly setting "Always do this" when an > attachment is opened. > > > (In reply to comment #6) > > AutoCAD is a Windows only CAD program. They "define" the DWG format. Sort of > > like MS defines the .DOC format. > > Yes, we know; and Microsoft also registered a MIME type for the format: > application/msword. I just Googled around and found that Autocad also has > one: application/acad > > Unfortunately, Thunderbird's "hide the MIME type so as not to confuse the > users" philosophy makes it difficult to fix this problem; see bug 244618. > I'll look at these.

I just changed the description. It's not just DWG files. It's more. Maybe the problem is any binary file? I'm wading past my safe zone of knowledge to some degree. Architects trade all kinds of binary files all the time. If the issue is these must be defined in the MIME table (that I can't seem to find a user setting for) my clients will be hosed. I need to figure out a work around or back them down to SM v1.0.7 Asking users to .ZIP everything is NOT a good long term solution as many mail server now block all .ZIP files.

> > If not -- I've just rediscovered the Mac-specific bug 364594, which can cause > > this kind of problem without explicitly setting "Always do this" when an > > attachment is opened. The problem description looks like one we had a couple of years ago with Mozilla where attaching a Word .DOC file from from a Mac when using Moz on a Mac COULD (but not always) create an email with either a Null or invalid line ending. I never did figure out which. We just .ZIPed the file at the time. I'll look more closely at this one.

(In reply to comment #8) > Uh, what version? I don't see "Options" under the Tools menu. SM v1.1 Sorry; I'm using Thunderbird. On the suite, we're talking about Preferences | Navigator | Helper Applications And on the suite, the item in question won't be listed under "DWG" but (probably) under "multipart/appledouble". Select it and click Remove. (In reply to comment #9) > Architects trade all kinds of binary files all the time. If the issue is > these must be defined in the MIME table (that I can't seem to find a user > setting for) my clients will be hosed. Well: I'm pretty sure that you're seeing some combination of bug 355142 and, maybe, bug 364594; if so, then editing the MIME table may be required. Fortunately, it's much easier to do that under the suite. For instance: at the Helper Apps dialog, after you delete the multipart/appledouble entry, select: New Type. Fill in the fields as follows: MIME Type: application/acad Description: AutoCAD Drawing File Extension: DWG Plus, select your preferred action, and OK. Now you're ready to go; DWG files that you receive will be handled as you expect, they won't change the MIME table, and when you send out a .DWG file, it will go out with the correct application/acad MIME type associated with it.

(In reply to comment #11) > (In reply to comment #8) > > Uh, what version? I don't see "Options" under the Tools menu. SM v1.1 > > Sorry; I'm using Thunderbird. On the suite, we're talking about > Preferences | Navigator | Helper Applications > And on the suite, the item in question won't be listed under "DWG" but > (probably) under "multipart/appledouble". Select it and click Remove. No such entry. I even looked in the file "mimeTypes.rdf" and can't find anything close. What I do have, as best I can tell from the mimeTypes.rdf file, is: <RDF:Seq RDF:about="urn:mimetypes:root"> <RDF:li RDF:resource="urn:mimetype:application/x-stuffit"/> <RDF:li RDF:resource="urn:mimetype:application/pdf"/> <RDF:li RDF:resource="urn:mimetype:application/zip"/> <RDF:li RDF:resource="urn:mimetype:application/x-tar"/> <RDF:li RDF:resource="urn:mimetype:application/x-gzip"/> <RDF:li RDF:resource="urn:mimetype:application/macbinary"/> <RDF:li RDF:resource="urn:mimetype:application/mac-binhex40"/> <RDF:li RDF:resource="urn:mimetype:application/msword"/> <RDF:li RDF:resource="urn:mimetype:video/x-ms-wmv"/> <RDF:li RDF:resource="urn:mimetype:audio/playlist"/> <RDF:li RDF:resource="urn:mimetype:application/vnd.ms-excel"/> <RDF:li RDF:resource="urn:mimetype:application/vnd.ms-powerpoint"/> <RDF:li RDF:resource="urn:mimetype:image/tiff"/> <RDF:li RDF:resource="urn:mimetype:audio/x-pn-realaudio"/> <RDF:li RDF:resource="urn:mimetype:application/smil"/> <RDF:li RDF:resource="urn:mimetype:application/x-apple-diskimage"/> <RDF:li RDF:resource="urn:mimetype:image/jpeg"/> </RDF:Seq>

(In reply to comment #11) > (In reply to comment #8) > (In reply to comment #9) > > Architects trade all kinds of binary files all the time. If the issue is > > these must be defined in the MIME table (that I can't seem to find a user > > setting for) my clients will be hosed. > > Well: I'm pretty sure that you're seeing some combination of bug 355142 and, > maybe, bug 364594; if so, then editing the MIME table may be required. > Fortunately, it's much easier to do that under the suite. For instance: at the > Helper Apps dialog, after you delete the multipart/appledouble entry, select: > New Type. Fill in the fields as follows: > MIME Type: application/acad > Description: AutoCAD Drawing File > Extension: DWG > > Plus, select your preferred action, and OK. Now you're ready to go; DWG files > that you receive will be handled as you expect, they won't change the MIME > table, and when you send out a .DWG file, it will go out with the correct > application/acad MIME type associated with it. I wasn't clear. It would be almost impossible for me to get a list of all file types. Kind of like asking folks to name every thing they ate in the last month. DWG was just the one that hit first. The day after I put in SM v1.1.

(In reply to comment #12) > > And on the suite, the item in question won't be listed under "DWG" but > > (probably) under "multipart/appledouble". Select it and click Remove. > > No such entry. I even looked in the file "mimeTypes.rdf" and can't find > anything close. Well, that's a drag. Could you send me a message with a DWG attachment, created the same way as the original report? (In reply to comment #13) > I wasn't clear. It would be almost impossible for me to get a list of all file > types. You were perfectly clear. I was providing a workaround. Could you at least try it for that DWG file type, to see if it works? Since my original assumption has been shown incorrect, I'm not even sure the workaround will do the trick.

(In reply to comment #11) > > Well: I'm pretty sure that you're seeing some combination of bug 355142 and, > maybe, bug 364594; if so, then editing the MIME table may be required. > Fortunately, it's much easier to do that under the suite. For instance: at the > Helper Apps dialog, after you delete the multipart/appledouble entry, select: > New Type. Fill in the fields as follows: > MIME Type: application/acad > Description: AutoCAD Drawing File > Extension: DWG > > Plus, select your preferred action, and OK. Now you're ready to go; DWG files > that you receive will be handled as you expect, they won't change the MIME > table, and when you send out a .DWG file, it will go out with the correct > application/acad MIME type associated with it. Did the above. DWG file got through. Appears to be ok.

Oh, good. Now you've fixed it, so that means it's going to Even More Difficult for you to send the information I asked for. I don't want ZIP files. I didn't really want the mimeTypes.rdf, altho I can verify that it doesn't exhibit the problem I was originally assuming. I want an actual, as-sent, broken email message of the type you were complaining about in the first place. That's why I said, in comment 14, > Could you send me a message with a DWG attachment, > created the same way as the original report? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Excuse me. From a machine with nothing changed in the profile I sent TWO emails. One with a .zip of two different files that seem to break things plus a copy of my mime/types in case it would be useful. THE SECOND email has the .zip plus the two file inside the zip independently. I was trying to send as much as possible. I guess I was wrong. Anyway the second email breaks in multiple ways from the user point of view. You can't even see the .zip file that was attached first. WHAT I FIXED was on my personal machine. To see, as I thought you wanted me to, if adding the DWG mime type, would fix things. It did. On my personal machine. Tell me what do do next to help and I will. I thought I was. I guess not. I'll read more carefully in the future.

OK. I've sent Mike C. three emails. Two as described above. The last just now with nothing but the attached DWG and a few words of text in the body. It and the previous two were sent from a machine with a profile without a mime type for DWG or the Apple Double. It was send from the domain <clearscapes.com>.

> THE SECOND email has the .zip plus the two file inside the zip independently. > Anyway the second email breaks in multiple ways from the user point of view. > You can't even see the .zip file that was attached first. Here's the message in question. When I received it, the .zip attachment was visible and seemed to be the only attachment in the message. When I viewed the message source I didn't notice the other attachment, which was completely empty except for the headers. The MIME structure of this message is as follows: Top: multipart-mixed; boundary=xxx902 --xxx902 Part 1: text/plain [OK] --xxx902 Part 2: application/zip [OK] --xxx902 Part 3: multipart/appledouble; name=BlankPowerCADD.dwg; boundary=yyy704 --yyy704 Part 3.1: multipart/appledouble; name=BlankPowerCADD; boundary=zzz702 --yyy704-- --xxx902-- Both part 3 and 3.1 are empty, except for the headers. Since these are supposed to be three separate attachments, it's not clear why part 3.1 is nested within part 3.

Here's the 3rd email David sent me, which should be v. similar to the one received by Andrew Schultz above, and the headers are as seen in comment 4. The MIME structure of this is: Top: multipart-mixed; boundary=xxx908 --xxx908 Part 1: text/plain [OK] --xxx908 Part 2: multipart/appledouble; name=BlankPowerCADD.dwg; boundary=yyy503 [data, no preceding boundary or additional headers] --yyy503-- <-- but an end boundary --xxx908--

First, let me clarify my comment 4. I sent David's attachment, (not the entire .eml) to myself. I downloaded the attachment from #20, and saved it as a .eml. When I opened it, it just displayed the text part, no sign of the attached .dwg file. I then went and edited out the --yy503-- boundary mentioned in #20. No difference when I tried to open it. I then put the trailing 503 boundary back and added a leading --yy503 (note trailing -- removed) boundary. Still no difference. I'm going to have to crack the books on MIME. I don't know whether the boundary is supposed to go within the encoded data or outside. Logically, it should go within, since the parts have to be separable? The error may be the trailing boundary not being included with the encoded data? (I need to dig up a free-standing base64 decoder.) David, you've sent us busted samples. How about sending me a non-busted sample of the same attachment, presumably from a 1.0.6/7 OS X SM? I presume the others will want to be copied too. I'm curious about interoperability here. Does it alway occur when the sender is a SM 1.1? Does it matter what the receiver is SM 1.1, 1.0.x, Mac, Win? Etc. I'm also new enough to Mac to not understand resource forks, but I wonder if resource forks cause appledouble to be used? If I just pull down a .dwg onto my system, will it have a resource fork? If it doesn't, is that why it is sent application/octet-stream? Where I'm driving is can this be trivially reproduced for any Mac file with a resource fork? (How can I view a file's resource fork?)

(In reply to comment #21) Things I can respond to before I head for the vet. > David, you've sent us busted samples. How about sending me a non-busted sample > of the same attachment, presumably from a 1.0.6/7 OS X SM? I presume the > others will want to be copied too. Everyone on this bug? > I'm curious about interoperability here. Does it alway occur when the sender > is a SM 1.1? Does it matter what the receiver is SM 1.1, 1.0.x, Mac, Win? > Etc. So far I've not tried it on anything but SM v1.1 on a Mac. It first surfaced when outsiders mentioned that attachments they were expecting were missing. Mostly Windows, mostly not any Moz product. It started when I switch the staff from SM v1.0.x to v1.1. It happens during the creation / sending as the copy in the Sent folder is bad. > I'm also new enough to Mac to not understand resource forks, but I wonder if > resource forks cause appledouble to be used? If I just pull down a .dwg onto > my system, will it have a resource fork? If it doesn't, is that why it is sent > application/octet-stream? Where I'm driving is can this be trivially > reproduced for any Mac file with a resource fork? I'm not a wizard on this subject but here's what I think I know. Resource forks are a separate data stream for the file. It is structured. On OS X 10.4.x you can have more streams. Few if anyone uses them. Resource forks are "depreciated" according to Apple which means you should stop using them. But this and the multiple data streams in a file seem to be a continous point inside of Apple and not everyone seems to agree with this path. Anyway, the newer file formats from Apple usually do not have a resource fork. But many do have small ones. To do simple testing you can take a text file (notpad say) from a Windows setup and move it to a mac. It will NOT have a resource forks. Open it will Resfool (see below) and you'll get a chance to create a resource fork for the file. I can't remember a trivial way to see if a file has a resource fork just now other than copying it to a FATxx device. Say a memory stick. But to see the fork you'd have to take the stick to a Windows machine or look at it via terminal as the Finder "hides" such things from you. > ... (How can I view a file's > resource fork?) Resfool http://www.ljug.com/sw/resfool.html $20 shareware but it will work for a week or so before the NAG gets real annoying. If you want others visit <www.versiontracker.com> and search for resedit. Now this may (but I doubt it) be only an issue with HFS+ file systems. All the systems I work with use this and this is what I'll bet 99% of the Macs out there use. Resource forks are built into HFS+. On FATxx and some other systems they exist as a separate file. On NTFS I think they use built in features of the file system.

(In reply to comment #22) > (In reply to comment #21) > > > > David, you've sent us busted samples. How about sending me a non-busted sample > > of the same attachment, presumably from a 1.0.6/7 OS X SM? I presume the > > others will want to be copied too. > > Everyone on this bug? > Well, I was thinking anyone you'd previously sent a sample to + me, but perhaps me and Mike will do. We should get an unbroken one attached to this bug for comparison, but I'd like to receive one "live". Can't do more until maybe this evening. :/

(In reply to comment #21) > First, let me clarify my comment 4. I sent David's attachment, (not the > entire .eml) to myself. Right. And once I saw David's actual problem message, I should have confirmed this bug, because what you posted shows the same problem: the headers are broken. I don't know what's causing it, tho, and I can't reproduce it since I don't have a Mac. The problem is, the MIME in the outgoing message is invalid. It's Mozilla's fault. It's interesting to me that the workaround of manually assigning a useful MIME type to the particular extension does in fact fix the problem; but David is right that this is not a solution generally. > David, you've sent us busted samples. That was the whole point -- without a broken message, how can we begin to analyze what the problem is? The thing is, I don't have a Mac, which is how appledouble attachments are generated. > How about sending me a non-busted sample of the same attachment, presumably > from a 1.0.6/7 OS X SM? I presume the others will want to be copied too. Bug 146382 has an attachment which is a message with (I believe) a valid appledouble attachment, if you want to see an example.

OK. I'm farily certain that Mike and Rich have a broken message sent from me from SM v1.1 and two valid ones. One valid one sent from v1.1 with dwg set as a mime/type and another from v1.0.7. Anyone else?

I wonder if this might be fallout from bug 365282. David Bienvenu, is that possible? Unfortunately, it doesn't appear the Seamonkey nightlies are built for Mac, at least not in the directories I've looked in.

Mike, it's definitely in the same area, but I thought the affect of that change was limited to files that were getting sent via extensions where the extension set the content type - those files couldn't be apple double, but normal file sends shouldn't have been affected. But, it's complicated code.

OS X does not seem to come with a base64 decode utility, but http://www.xs4all.nl/~jlpoutre/BoT/Mac-OSX/oneliners.html shows a way to easily make one. If I use that to decode the base64 data from https://bugzilla.mozilla.org/attachment.cgi?id=253541, I see --------------ad040205050307010004020503^M Content-Type: application/applefile Content-Transfer-Encoding: base64 AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAUAAAADAAAAVgAAABIAAAAJAAAAaAAAACAAAAAI^M AAAAiAAAABAAAAAEAAAAmAAAAAAAAAACAAAAmAAAAR5CbGFua1Bvd2VyQ0FERC5kd2dEV0cg^M QUNBRAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1TfAUNU3wGS20MAA1TkwUAAAEAAAABAAAA^M AAAAAAAeAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA^M AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA^M AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA^M AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA^M AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAAHgAAAAAAAAAA^M ABwAHv//^M ^M --------------ad040205050307010004020503^M Content-Type: application/octet-stream; name="BlankPowerCADD.dwg"^M Content-Transfer-Encoding: base64^M Content-Disposition: inline; filename="BlankPowerCADD.dwg"^M ^M QUMxMDE1AAAAAAAGAW0lAAATBh4ABgAAAADcAAAAnQEAAAF5AgAAEgUAAAIFJAAAnAAAAAOh^M [snip MANY lines] AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA^M AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAODakvgrydfXYqg1wGK779Q=^M ^M --------------ad040205050307010004020503--^M ^M Which seems to look ok to me. (I'm not sure about the Carriage Return characters though, which display here as ^M.) The extra 503 boundary outside the block, noted in comment 20 is clearly bogus. Looking at a good copy e-mailed from David to me under SM 1.0.7, I see [...] Subject: Re: Workng DWG per Rich's request v1.07 References: <45C23BA7.7070101@davidrossconsultant.com> In-Reply-To: <45C23BA7.7070101@davidrossconsultant.com> Content-Type: multipart/mixed; boundary="------------070007000504040109020007" This is a multi-part message in MIME format. --------------070007000504040109020007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David Ross wrote: > This should be a good attachment. I'll send a confirmation if I get it ok. > > Sent with SM v1.1 and DWG defined as a mime type. > > (Now to mount a v1.0.7 image and send with that.) I got that one clean. Now here's one from a v1.0.7 release. --------------070007000504040109020007 Content-Type: multipart/appledouble; boundary="------------ad040709050008030800070600"; x-mac-type="44574720"; x-mac-creator="41434144"; name="test PC.dwg" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="test PC.dwg" --------------ad040709050008030800070600 Content-Type: application/applefile Content-Transfer-Encoding: base64 AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAUAAAADAAAAVgAAAAsAAAAJAAAAYQAAACAAAAAI AAAAgQAAABAAAAAEAAAAkQAAAAAAAAACAAAAkQAAAR50ZXN0IFBDLmR3Z0RXRyBBQ0FEBACx 4LHgAAAAAAAAAAAAAAAAAAAAAAAADVCz4g1Qs+NLbQwADVS1NwAAAQAAAAEAAAAAAAAAAB4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAABAAAAAAAAAAAeAAAAAAAAAAAAHAAe//8= --------------ad040709050008030800070600 Content-Type: application/octet-stream; name="test PC.dwg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="test PC.dwg" QUMxMDE1AAAAAAAGAfwtAAATBh4ABgAAAADcAAAAnQEAAAF5AgAAEgUAAAILLAAAIgEAAAMt [big snip] AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AADg2pL4K8nX12KoNcBiu+/U --------------ad040709050008030800070600-- --------------070007000504040109020007-- Notice that the appledouble part was not base64 encoded, but that should not have caused things to fail in and of itself?? (Rather inefficient though!) Suspecting that this is really a problem with resource forks, I tried a little test. I used vi to create a simple text file named "HelloWorld". ~/desktop/bug$ hexdump -C HelloWorld 00000000 68 65 6c 6c 6f 77 6f 72 6c 64 0a 0a |helloworld..| 0000000c When I send this to myself as an attachment, the guts of the e-mail are: Subject: hello world Content-Type: multipart/mixed; boundary="------------030607000904060905030204" This is a multi-part message in MIME format. --------------030607000904060905030204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit h.w. attached --------------030607000904060905030204 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="HelloWorld" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="HelloWorld" helloworld --------------030607000904060905030204-- This e-mail displayed the attachment both in the attachment area and inline, as expected. I then got the file in a Finder window, selected it and hit cmd-i (Get Info.) I changed Open With from "none" to (what the heck) "SeaMonkey", then closed the Get Info window. I e-mailed the file to myself again. This time, I got: Subject: hello world (opens with SM) Content-Type: multipart/mixed; boundary="------------080403000100040805030909" This is a multi-part message in MIME format. --------------080403000100040805030909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit seamonkey hello world --------------080403000100040805030909 Content-Type: multipart/appledouble; boundary="------------ad010000090208020905020307"; x-mac-type="0"; x-mac-creator="0"; name="HelloWorld" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="HelloWorld" LS0tLS0tLS0tLS0tLS1hZDAxMDAwMDA5MDIwODAyMDkwNTAyMDMwNw0KQ29udGVudC1UeXBl [snip] MDAwMDkwMjA4MDIwOTA1MDIwMzA3LS0NCg0K --------------080403000100040805030909-- Notice that there is no spurious boundary as cited in comment #20. The decode of the appledouble part yields: -------------ad010000090208020905020307^M Content-Type: application/applefile Content-Transfer-Encoding: base64 AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAUAAAADAAAAVgAAAAoAAAAJAAAAYAAAACAAAAAI^M [snippers] ZGVkXxAjQXBwbGVOYXZTZXJ2aWNlczpHZXRGaQAAAQAAAAUIAAAECAAAADIAP/CsBNIAAAAc^M ADIAAHVzcm8AAAAKAAD//wAAAAAAXSVo^M ^M --------------ad010000090208020905020307^M Content-Type: application/octet-stream; name="HelloWorld"^M Content-Transfer-Encoding: base64^M Content-Disposition: inline; filename="HelloWorld"^M ^M aGVsbG93b3JsZAoK^M ^M --------------ad010000090208020905020307--^M ^M Which looks a whole lot like David's cases. Like David's broken .dwg cases, all that the receiver sees for this message is the text part. There is no sign of any attachment. I'm assuming that by setting Open With, I caused the file to get a resource fork. If that is indeed the case, then it seems that the problem is generic. Attachment of files with resource forks is br0ken. So, if I'm right, steps to reproduce: 1. create a (text) file with no extension or other associations (resource fork) 2. give it a resource fork by assigning it an Open With in Finder Get Info. 3. send the resulting file as an attachment Results: The receiver will see only the text part of the message, no sign of an attachment. Expected Results: The sent file should appear as an attachment. (I have no idea what the ramifications of appledouble are in the normal case.)

(In reply to comment #28) Sorry for the extra noise, but I did not say this right. > Notice that the appledouble part was not base64 encoded, but that should not > have caused things to fail in and of itself?? (Rather inefficient though!) > What I meant to say was that in the good case, the appledouble part is not base64 encoded. The appledouble part is needlessly encoded in the failing cases, but that in and of itself should not cause trouble. It's just inefficient.

(In reply to comment #24) > It's interesting to me that the workaround of manually assigning a useful MIME > type to the particular extension does in fact fix the problem; but David is > right that this is not a solution generally. http://www.faqs.org/rfcs/rfc1740.html says 2c. Detail specific to MIME-based usage Macintosh documents do not always need to be sent in a special format. Those documents with well-known MIME types and non-existent or trivial resource forks can be sent as regular MIME body parts, without use of AppleSingle or AppleDouble. That matches the behavior we see. I sent myself the HelloWorld sample file from Apple's Mail.app and I got a file with the same structure as David's 1.0.7 transmission. Aside 1: Mail.app included x-unix-mode=0644; on the content-type of the actual data part. Aside 2: Mail.app offers a "Send Windows Friendly Attachments" checkbox in the Attach dialog. When I tested with that, it sent the HelloWorld file as a simple attachment of type application/ octet-stream. Good Idea (s/Windows/Non-Mac/).

I'm not demanding or anything but just asking. Does anyone have any idea of if this is a "oops" type-o or if there is some non trivial amount of work to be done with this. I have to decide if I should step back to v1.0.7 in some offices. Troop are getting very restless and starting to look for touches and yard implements with me as the object of affection.

Do SM or TB trunk and 1.8 branch builds before Jan 2nd work and ones after not work? If so, then bug 365282 would be the cause, and I can try to figure out a fix for bug 365282 that doesn't cause this problem. With all the research that's gone into this problem, does someone have concise steps for reproducing this problem, along with a sample file to attach? I do have a mac to try this on.

(In reply to comment #32) > With all the research that's gone into this problem, does someone have concise > steps for reproducing this problem, along with a sample file to attach? I do > have a mac to try this on. > As best it seems from the work done here, if you attach a file to an email and that file HAS a resource fork and DOES NOT have a stored mime/type the problem will occur. The problem is that the attachments are not correctly encoded into the email. Getting a file with a resource fork isn't always obvious as the Finder goes out of the way to hide this from you. If you have a resediting tool, it will tell you if a file has a resource fork. Most tools will allow your to create a resource fork for a file if one is not present. ResFool, mentioned above will allow you to do this.

(In reply to comment #32) > Do SM or TB trunk and 1.8 branch builds before Jan 2nd work and ones after not > work? If so, then bug 365282 would be the cause, and I can try to figure out a > fix for bug 365282 that doesn't cause this problem. If someone will point me to these builds, I'll test and see. I'll also email David Bienvenu a good and bad email.

One more key point. The email is assembled wrong. It gets put into the sent folder with the problem. I'll see if a draft also has the issue.

locally backing out the fix for bug 365282 did not seem to help with this issue so I don't think it's related.

This definitely works in 1.5, so something broke in 2.0 (d'uh). 2.0 isn't writing out the mime boundary before the applefile part, so the mime structure is completely broken. Perhaps the code that tries to get the resource fork is broken...

we were running afoul of the code in PickEncoding that checks for mismatched line endings (crlf vs cr vs lf). That was because the apple encoding call was generating lines with just lf endings. If we fix that to generate crlf, which is what we want to send over the wire, I believe, then everything is fine. Alternatively, we could change PickEncoding not to base64-encode apple double parts, I suppose, but this fix doesn't require a special case...

this should be fixed in tomorrow's TB 2.0 nightly beta 2 build - please try that and let me know. I'll land this on the trunk as soon as I can.

WFM, Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 :-) I sent my HelloWorld attachment to David, let's see if he gets fixed for it and his .dwg files. Might I suggest that for posterity's sake, this bug be renamed to something like "OS X files with resource forks and no defined MIME type encoded incorrectly" since it was found to not be .DWG specific. FYI, I located a free resource fork editor, Rezilla (oooo, catchy name!) at http://sourceforge.net/projects/rezilla. This one is freeware. Didn't mess with it though.

fixed on trunk as well

Seamonkey's next 1.1 release is going to want this fix; I'm not sure if that'll get automatically included just because this is in 1.8.1.2.

Mike, it will. We share the relevant code with TB.

Verified fixed with 2.0.0.0 rc2 on Mac OS 10.4.9