493157 - IMAP attachment text file data is incorrect received from OEX composed email

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Phil Lacy]

Attachment: source comparison of emails

Using gmail account, connected via IMAP. An email with text file attached, when opened or saved reads incorrect data.  Interpreting OEX data as HTML tags. See attachment. Speaks for itself

Actual file content
test file
Content of attachment from received email:
<div class="moz-text-flowed" style="font-family: -moz-fixed">test file</div>

Comment 1

[Mark Banner (:standard8)]

It is interesting that the wrapped lines of the content types etc have a tab at the start of the line rather than a space. I wonder if there's something in the rfc that we are expecting and OEX is doing wrong, or if we're not flexible enough.

Comment 2

[Phil Lacy]

Don't know if that would explain that we see and expect plain/text yet we render it like for a browser. I'll do some debugging

Comment 3

[Phil Lacy]

Comment on attachment 377608 [details]
source comparison of emails

>Content-Type: text/plain;
>	format=flowed;
>	name="New & Text Document.txt";
>	reply-type=original
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment;
>	filename="New & Text Document.txt"
>
>test file
>------=_NextPart_000_001C_01C9D4DE.52ABF880--

in mailbox file, changing tabs to spaces had no effect.  However removing format=flowed fixed it. 
Mark, what now? Shouldn't that qualifier be ignored and not override text/plain?

Comment 4

[Phil Lacy]

Attachment: passes thru as is data marked as raw [Checkin: Comment 10]

never could find where the attachment is marked as nsMimeMessageRaw. I'm not sure what nsMimeMessageAttach means, maybe a designation that it is an attachment in which case I need to know where this is getting tagged so maybe it should be tagged as such.
Either way I would think this check is proper and any naMimeMessageRaw should not be parsed into anything.

Comment 5

[Mark Banner (:standard8)]

Comment on attachment 377992 [details] [diff] [review]
passes thru as is data marked as raw
[Checkin: Comment 10]

David knows this area of the code much better than I do, so passing to him.

Comment 6

[Phil Lacy]

from nsStreamConverter.cpp, if it has a 'part' it defaults to raw. If not and it has a 'header=' it may have the attach type which is nsMimeMessageAttach which uses the plaintext mimeobjecttype.
So the only question is if we ever need nsMimeMessageRaw format type to be output with the plaintextflowed mimeobjecttype which essentially puts in the html code for displaying purposes.  If so then maybe we should be calling an attachment nsMimeMessageAttach and forget this patch.

Comment 7

[Phil Lacy]

This patch does not affect decoding binary attachments. my proof consists of opening a zip file from imap message with zip attachment residing in draft folder.
Also, this works in local folders.

Comment 8

[David :Bienvenu]

Comment on attachment 377992 [details] [diff] [review]
passes thru as is data marked as raw
[Checkin: Comment 10]

thx for the patch, it definitely fixes the problem, and I can't see why we'd ever want raw to mean output html. I would think we'd want the format_out to be nsMimeMessageAttach so I'll have a look at the code that's setting the type to raw to see what's going on there - it might have to do with stripping attachments...

Comment 9

[Phil Lacy]

I used an email with html formatting and viewed attachment in-line and it displayed ok with this patch so I marked checkin required.

Comment 10

[Serge Gautherie (:sgautherie)]

Comment on attachment 377992 [details] [diff] [review]
passes thru as is data marked as raw
[Checkin: Comment 10]


http://hg.mozilla.org/comm-central/rev/4a231a0cac5e