Closed Bug 249049 Opened 16 years ago Closed 16 years ago
Attachments automatically inlined, can't be viewed in other clients
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.
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 ****. . . ).
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.
This isn't a critical bug -> major.
Severity: critical → major
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
(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
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 ***
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
(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
You need to log in before you can comment on or make changes to this bug.