User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.5) Gecko/20031007 Saving specific messages is broken in the following way: Reproducible: Always Steps to Reproduce: 1. Get a message containing attachments which have the full path to the original file specified (in the MIME header) - some strange mailers (like webmails) do this. OE and Mozilla do not. 2. The path should also contain 8-bit (accented characters) 3. Save the message as TXT (plain text) Actual Results: The resulting file is empty. Expected Results: The file should be saved correctly, as it is done using the other export formats (html, eml).
Reporter (aceman): could you please attach a sample message, in .EML format, to this bug so we could verify? (A relatively small message if possible.)
Created attachment 136219 [details] Raw message showing the problem. This is an example message. It was stripped from a real message. I removed unnecessary (personal) headers and cut the attachments so that they are undecodable. But it still shows the bug. Atleast for me.
I can confirm this behavior; replicated with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031120 The expected result (from the attached sample) is a file that contains something like: =====begin paste===== Subject: none Attachment From: censored Date: Tue, 11 Nov 2003 19:08:23 +0100 To: censored text C:\\WINDOWS.000\\Pracovná plocha\\mail.rar Content-Type: APPLICATION/octet-stream Content-Encoding: BASE64 [etc...] =====end paste===== If the sample email is edited to replace the á's with a's, the mail is saved as expected. Note that Mozilla (at least sometimes) encodes attachment names with hi-ANSI characters like this: Content-Type: image/png; name="=?ISO-8859-1?Q?fact=F6id=2Epng?=" The lack of this encoding (expectation of 7-bit characters in the headers) may be the root cause of the problem. On the other hand, this particular email has a top-level ISO-8859-2 encoding. For reference, see bug 192901, but this is quite a different behavior here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Thanks for confirmation. I don't see the behaviour in bug 192901. Actually, it works really well here (in 1.5), it correctly offers the file name for the attachment (with accented chars preserved). But of course, it may may work because of the coincidence, that e.g. 'á' is in the same position in iso-8859-2 and win-1250. But it even replaced dangerous characters - '\' is replaced with '-'. Maybe that function could be used to parse the attachment names when saving the message text.
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: stephend → attachments
Product: Core → MailNews Core
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 262739
You need to log in before you can comment on or make changes to this bug.