Closed Bug 236239 Opened 21 years ago Closed 20 years ago

Some attachments are encoded as appledouble [text.txt, word.doc] Can't send/receive msword .doc attachment: null byte in message; appledouble error copying to sent folder

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: romgregorie, Assigned: Bienvenu)

References

Details

(Keywords: fixed-aviary1.0)

Attachments

(2 files)

don't try to send out appledouble on non-macs
2.19 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
fix for aviary branch
1.77 KB, patch
Details | Diff | Splinter Review 
User-Agent:       
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8

The text file is unix line end. If the file is named "foo.txt" it is encoded as
appledouble and thus unreadable at the receiving end.

If the file is named just "foo" (without extention) if is encoded correctly, as
text/plain.

The settings for outgoing mail char enconding do not seem to matter.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
bug 232923 seems related.
got exactly the same problem, but using Mac OSX 10.3.3

the problem is well known, trying to send an word-doc attachment, the error:

*There was an error copying the message to the Sent folder. Retry* pops up.
Cancel this one pops up the next one:

*The message was sent successfully, but could not be copied to your Sent folder.
Would you like to return to the compose window?*

So, the message has been sent, but the attachment is not viewable. Having a look
at the source the conten-type just before the attachment shows:

content-type: multipart/appledouble; xmac-type="5738424E",
x-mac-creator="4D535744"; name="text.doc"

another client not having this problem has as content-type:
content-type: text/plain; charset=us-ascii; format=flowed


Build Identifier: Mozilla/5.0 (Windows; O; Windows NT 5.1; en-US; rv:1.7.1)
Gecko/20040707

Generates the same problem as in comment #2 (including the spurious
"...succesfully sent but, could be copied to your Sent folder.")

This started to happen a couple of days ago with version 1.6 after having
received an appledouble encoded Word .doc from a Mac user.  After upgrading to
the version above the problem was gone until today after receiving a Mac
appledouble encoded Word .rtf, the same thing happened .  Reinstallation wa not
a successful work-around this time. I hope this helps.  Mail sending is
virtually pointless for these type of attachments now.


Build Identifier: Mozilla/5.0 (Windows; O; Windows NT 5.1; en-US; rv:1.7.1)
Gecko/20040707

Another update.  Had a go at it again.  Under Helper Applications in the
Preferences I found that multipart/appledouble was associated with .doc/Word
documents. After removing that, the problem was gone.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
 and
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707

Some more information (after being able to reproduce the behaviour on a
different computer):

A mail that contains a multipart/appledouble encoded Attachment (e.g. with a
word .doc or .txt file in it) is received using the Messenger.  Opening the
attachment brings up the usual dialog, since mutlipart/appledouble has no
default application attached to it. Choosing Word now opens the file. having
"Always perform this action when handling files of this type" ticked (by
accident??), connects multipart/appledouble with .doc files.  Next time you send
a .doc file, Mozilla tries to create an appledouble attachment, but seemingly
fails to create a resource fork (surprise, surprise on a PC).  That's the reason
why the sent mails containg word (in our case or .txt in the above case)
attachments are incorrectly encoded (which also might lead to the
refusal/failure saving the message in the "Sent" folder).  

If you do not have "Always perform..." ticked, everything is (and stays) fine. 

Still I do not understand, why a PC based Mozilla would try to include a
resource fork anyway, while sending a mail. BTW the failure on MacOS X could be
due the same reason, since there resource forks are discouraged and not widely
used anymore.

*** Bug 232923 has been marked as a duplicate of this bug. ***
*** Bug 249473 has been marked as a duplicate of this bug. ***
Updating 

Bug 232917 claims to have fixed a similar problem in TB0.5 
   (for files sent from OS X)

Dupes:
Bug 249473: receiving client is Mutt; sending client is TB 0.7.1 (Windows?)
Bug 232923: receiving client is TB0.4/Win2K; sending client is TB0.4/Win98
   claims that problem does not exist sending *from* Win2K machine

another possible dupe: bug 221811 (message sent from OS X via Exchange server)

Questions about the messages exhibiting this problem:
 - Is the "appledouble" header visible in the copy of the message in the 
sender's Sent folder, or only in the received message?  If visible in the Sent 
copy, please save the message as .eml and attach it to this bug.
 - Which receiving clients are exhibiting the problem?
 - Is the message being received via a MS Exchange server?  
   If so, using the IMAP or Win.Messaging?

See also bug 156349 -- probably unrelated, but I don't know for sure.
OS: Linux → All
Summary: A text attachment is encoding as appledouble. → Some attachments are encoded as appledouble [text.txt, word.doc]
I think another related bug is bug 229855.  See also
http://forums.mozillazine.org/viewtopic.php?t=39285&highlight=appledouble
Also, this is an issue for Mozilla Mail/News as well at TBird
(but I can't change the product field).

There is an issue here that is very important: On a Mac under OS-X it
is sometimes impossible to send, and/or receive, and/or count on
others (who are not using Macs) being able to receive MSWord .doc
files. The following are actions and symptoms:

To reproduce: 

Compose a new message and address it
Attach a .doc file ("letter.doc" below)
Try to send the message:

 1. Some SMTP servers complain that an error has occurred, report
    "null byte in data", and won't send the msg.

 2. Some other SMTP servers do send the message. However,

 3. If the message does get sent, there is then sometimes
    a problem writing the mail to a sent folder, as has 
    been reported before. 

 4. If the message does get sent, the .doc attachment is 
    in the message but the attachment can't be read by Mozilla Mail 
    The mime header info for the attachment is:

      Content-Type: multipart/appledouble; x-mac-type="5744424E"; 
                    x-mac-creator="4D535744"; name="letter.doc"
      Content-Transfer-Encoding: 8bit
      Content-Disposition: inline; filename="letter.doc"

That is, an appledouble encoding.

I tried a workaround reported here:

 http://forums.mozillazine.org/viewtopic.php?t=39285&highlight=appledouble

namely, adding the following entry to prefs.js:

 user_pref("mail.file_attach_binary", false);

This has no effect that I can see, and the behaviors listed above
still ensue. 

This is a fairly critical bug because many people exchange .doc files with
email. 

Finally, there may be "invisible" duplicate reports of this; bug
reports on this problem are hard to find, because few of the summaries
mention null bytes, or difficulties sending or reading msword or doc
file attachments. Keyword queries on combinations of null byte,
msword, doc, file, attachment, don't show the key related bugs. 
I may file a new bug report with a different summary line
so the info is easier to find. 


*** Bug 261311 has been marked as a duplicate of this bug. ***
Can someone who this is happening to send me their mimetypes.rdf, from their
user profile directory? thx...
Assignee: mscott → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 262124 has been marked as a duplicate of this bug. ***
I re-filed a description with the following summary line:

"Can't send/receive msword .doc attachment: null byte in message; appledouble
mimetype"

as bug 252124 to reduce duplication and make this easier to find.

I've duped that one against this, and changed this summary
Summary: Some attachments are encoded as appledouble [text.txt, word.doc] → Some attachments are encoded as appledouble [text.txt, word.doc] Can't send/receive msword .doc attachment: null byte in message; appledouble error copying to sent folder
Grrrr.  Comment 13 should have read "I refiled it as bug 262124" - sorry!
Please check that you duped the right one. 
Using info from Comment #4 and Comment #11 above, I tried the following
successfully:

1. On Mozilla, go to Preferences/Navigator/Helper Applications and
remove the entry for "multipart/appledouble". This has the effect of
removing the appledouble RDF descriptions from Mozilla's
mimetypes.rdf file.  This fixed the problem completely - Using Mozilla
Mail/news, I can now attach .doc files, send them with no errors on
both SMTP servers, and receive/read them with Mozilla and
Thunderbird. They are now encoded in the emails as:

  Content-Type: application/msword; x-mac-type="5744424E"; 
                x-mac-creator="4D535744";
 name="letter.doc"
  Content-Transfer-Encoding: base64
  Content-Disposition: inline; filename="letter.doc"

2. With Thunderbird, I couldn't find an interface to edit the mimetype
associations. So (after closing Thunderbird) I directly edited
Thunderbird's mimetypes.rdf file and removed all the appledouble
related RDF descriptions I found (3 of them I think). Again, this
fixed the problem completely on Thunderbird. Using Tbird I can now
attach .doc files, send them with no errors on both SMTP servers, and
receive/read them with Mozilla and Thunderbird. They are now encoded
in the emails as:

  Content-Type: application/msword; x-mac-type="5744424E"; 
                x-mac-creator="4D535744"; name="letter.doc"
  Content-Transfer-Encoding: base64
  Content-Disposition: inline;  filename="letter.doc"


I don't know what other appledouble mimetype implications there are,
and maybe appledouble is needed for something and shouldn't be just
completely removed. But at a minimum this is a workaround. 

this fixes the problem if the association has been messed up - I was not able
to get my associations messed up. I had to copy a section of a bad
mimetypes.rdf into my mimetypes.rdf to recreate this. I'll see if I can
recreate this on a machine with word installed to prevent mimetypes.rdf from
getting messed up, but this will make us handle it more gracefully.
Attachment #160543 - Flags: superreview?(mscott)
Attachment #160543 - Flags: superreview?(mscott) → superreview+
the prev patch wouldn't apply on the aviary branch, so I made these changes.

Also, on my .8+ build, I was able to corrupt my mimetypes.rdf by double
clicking on an apple double word doc, so either tbird .8 is broken, or its
because I have word on this machine, or some other difference.
fixed on trunk and branch.
Status: NEW → RESOLVED
Closed: 20 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
verified on 20041124 builds
Status: RESOLVED → VERIFIED
The problem has occured in Mozilla 1.7.5:

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: teale@ucalgary.ca
Subject: test3
Content-Type: multipart/mixed;
 boundary="------------070200090405040406020402"
X-UCIT-MailScanner-Information: Please contact IT Help Desk at (403) 220-5555
for more information
X-UCIT-MailScanner: Found to be clean
X-UCIT-MailScanner-From: bphipps@ucalgary.ca
X-Loop: teale@lms3.acs.ucalgary.ca

This is a multi-part message in MIME format.
--------------070200090405040406020402
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi deb, trying again now that Mozilla 1.7.5 is installed

--------------070200090405040406020402
Content-Type: multipart/appledouble;
 name="S10-P10 and High Salt Extracts from Human Cells.doc"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="S10-P10 and High Salt Extracts from Human Cells.doc"
This is still a problem in Thunderbird 1.0 for Mac OS X, build 20041206. After
manually editing mimetypes.rdf, the problem was resolved. 
(In reply to comment #22)
> This is still a problem in Thunderbird 1.0 for Mac OS X, build 20041206. After
> manually editing mimetypes.rdf, the problem was resolved. 

I still see it with Thunderbird 1.0.2 on OS X.  I always delete or edit
mimetypes.rdf, but the problem reoccurs.  It seems like the problem occurs when
another user sends a Word file to a Thunderbird user. The other user's software
attaches the resource fork and the data seperately:

--Apple-Mail-7-1016259346
Content-Type: multipart/appledouble;
	boundary=Apple-Mail-8-1016259346
Content-Disposition: attachment


--Apple-Mail-8-1016259346
Content-Transfer-Encoding: base64
Content-Type: application/applefile;
	name="mastermatrix.doc"
Content-Disposition: attachment;
	filename=mastermatrix.doc

<base 64 data for resource fork>

--Apple-Mail-8-1016259346
Content-Transfer-Encoding: base64
Content-Type: application/msword;
	x-mac-type=5738424E;
	x-unix-mode=0644;
	x-mac-creator=4D535744;
	name="mastermatrix.doc"
Content-Disposition: attachment;
	filename=mastermatrix.doc

<base64 data for file contents>

--Apple-Mail-8-1016259346--

--Apple-Mail-7-1016259346--

This appears in the attachment list as one file and saves as expected.  Only
later when the user tries to send a file with the same extension, .doc, is the
bug encountered.
(In reply to comment #23)
> (In reply to comment #22)
> > This is still a problem in Thunderbird 1.0 for Mac OS X, build 20041206. After
> > manually editing mimetypes.rdf, the problem was resolved. 
> 
> I still see it with Thunderbird 1.0.2 on OS X.

Precisely the same behaviour still occurs on Tbird 1.0.7 with MacOS X 10.4.3 and MS Word 2004 Ver. 11.2

I would not consider this bug "fixed", sorry.
This bug certainly happens with Mozilla 1.7.12. I saved one user today (learning on the way about this bug). I would recommend patching 1.7 branch againt the problem.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: