249049 - Attachments automatically inlined, can't be viewed in other clients

Status: RESOLVED DUPLICATE of bug 65794

(Thunderbird :: General, defect)

Description

[John R. Moser]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040617 Powergiraffe/0.9 (Firefox/0.9 rebrand)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040617 Powergiraffe/0.9 (Firefox/0.9 rebrand)

I try to attach my resume in RTF format when I send it around; but it appends it
inline to the message.  I can turn off display as inline in Thunderbird and then
save the message; but in i.e. Lotus Notes or Linux.net e-mail, it gives a ton of
garbage-looking **** at the end of the e-mail, and no way to save the attachment.

Outlook sends things fine.

I can't find the option, if there even is one, to turn this behavior off and
send *proper* *mime* *attachments* instead of this inline **** that seems to
break everything else in the world and be on by default.  Change the default
behavior and add an option.

If you want to test, try sending stuff with TB 0.7 to a linux.net e-mail (free).
 It might break hotmail too, dunno though.

Reproducible: Always
Steps to Reproduce:
1.  Install Thunderbird
2.  Compose a message to someone with Lotus Notes or Linux.net web mail,
possibly others
3.  Attach an .rtf file
4.  Watch RTF be inlined instead of base64 encoded

Actual Results:  
Inline attachment

Expected Results:  
Base64 attachment

Justification for critical:  I'm probably losing my chance at getting jobs here;
I've tried for a job with Google that I probably lost to a destroyed message.  I
guess I shouldn't be using alpha-stage software?

At any rate, I'm losing data, possibly *money*, due to created confusion and
hassle on the other end.

Comment 1

[John R. Moser]

Attachment: a message that is bad.

Check out the attachment, as encoded 7bit.

It's rich text format, but it's stuck inline because it's similar to a mark-up
language in that it is editable as plain text, thus it is evaluated as plain
text.

I need attachments to all be seen as binary, and encoded base64; it seems
there's no option, or if there is it's put in the most retarded place possible
because I can't find it after ~5 passes of every options dialog in Thunderbird
(including account settings, preferences, all the advanced ****. . . ).

Comment 2

[John R. Moser]

Content-Type: text/plain;
 name="master_resume2.rtf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="master_resume2.rtf"

With a proper /etc/mailcap, thunderbird now recognizes rtf and base64 encodes it
rather than plaintext.  However, it still sends it inline as text/plain, so same
problem.

Comment 3

[Oliver Klee]

This isn't a critical bug -> major.

Comment 4

[R.K.Aa.]

dup of bug 205871?
See  bug 205871 comment 3

Comment 5

[Damyan Ivanov]

IMO the problem is that if TB detects that attachment containt plain text (RTF
can be considered plain text) the it uses inline Content-Disposition:

Content-Type: text/plain;
 name="test.txt"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="test.txt"

Please, make it use Content-Disposition: attachment. If I want the text to be
inline, then I'd copy-paste it into the body. If I attach the attachment, let it
be attachment, and don't mark it inline.


Thanks,
dam

Comment 6

[Damyan Ivanov]

(In reply to comment #5)
> IMO the problem is that if TB detects that attachment containt plain text (RTF
> can be considered plain text) the it uses inline Content-Disposition:

Here's the code (around line 1009 in mailnews/compose/src/nsMsgCompUtils.cpp)

    if (pref_content_disposition == 1)
      PUSH_STRING ("attachment");
    else
      if (pref_content_disposition == 2 &&·
          (!PL_strcasecmp(type, TEXT_PLAIN) ||·
          (period && !PL_strcasecmp(period, ".txt"))))
        PUSH_STRING("attachment");

      /* If this document is an anonymous binary file or a vcard,·
      then always show it as an attachment, never inline. */
      else
        if (!PL_strcasecmp(type, APPLICATION_OCTET_STREAM) ||·
            !PL_strcasecmp(type, TEXT_VCARD) ||
            !PL_strcasecmp(type, APPLICATION_DIRECTORY)) /* text/x-vcard synonym */
          PUSH_STRING ("attachment");
        else
          PUSH_STRING ("inline");

It uses 'attachment' or 'inline' based on mixture of preferences and heuristics.

the preference in question is mail.content_disposition_type and its default
value is 0.

if mail.content_disposition_type is 1 'attachment' is used
otherwise some heuristics is used specifically to apply 'inline' to 'text/plain'
attachments and attachmants ending in '.txt' (WHY?)

setting mail.content_disposition_type to 1 in user.js or in the global
preferences (/etc/mozilla-thunderbird/pref/mailnews.js on my debian/sid) solves
the problem.

Please, why such special treatment for text/plain attachments?


thanks,
dam

Comment 7

[Mike Cowperthwaite]

First of all: whether *you* see the attachment inline or not, in TB/Moz, has no 
specific implications as to whether other clients see it.  Note that Mozilla 
will display some files inline even if spec'd as attachment (bug 147461); and 
depending on the rest of the headers, some attachments will be treated as 
attachment even if spec'd as inline (bug 229075).  

The setting of Display Attachments Inline affects your viewing of the message, 
but has nothing to do with the composition of the message.

It's true that Content-Disposition is set to inline all the time, which is 
undesirable most of the time; see bug 65794 comment 19 for how to make 
'attachment' the default.  Bug 66915 is a Seamonkey request for a UI to change 
it per-attachment.


Secondly:  An .RTF file is *not* text/plain; you should be using text/rtf.  
If the receiving mail client tries to display text/rtf inline when it doesn't 
know the format, that's not Mozilla's fault.  It's an IANA-registered type.

To control the .rtf <=> text/rtf assocation for TB under Windows, you need to 
set the MIME type in the registry entry for .rtf:
  HKEY_CLASSES_ROOT\.rtf
    @=rtffile
    Content-Type="text/rtf"
Content-Type may be set to application/msword, since Word likes to grab 
everything.

I don't know how this association is done under Linux.  (In Mozilla, you can 
make an explicit text/rtf entry in the Helper Apps -- maybe if you copy the RTF 
entry from Mozilla's mimeTypes.rdf file into TB's, that will install the 
association.)

Mozilla and TB do not display text/rtf inline, regardless of the value for 
Content-Disposition; RTF is MS proprietary:
  http://support.microsoft.com/support/kb/articles/q86/9/99.asp
They *will* attempt to display text/enriched (RFC1896) and text/richtext 
(RFC1341) because they know what those look like.  All three of these types will 
be BASE64'd.

I think that unrecognized text/* types (e.g. text/php) are treated as text/plain 
and so also shown inline.

*** This bug has been marked as a duplicate of 65794 ***

Comment 8

[Damyan Ivanov]

(In reply to comment #7)

I see your point, and have to apologise for not being clear enough.

My concern is for handling real text/plain attachments - i.e. a text file witn
.txt extension. See the code I mention - there really is a special handling for 
text/plain or .txt attachments and they are explicitly made inline.

I don't see any reason for this.


thanks,
dam