Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Binary attachments with wrong content-type (text/hml) are malformed while downloading #4292

Closed
rcubetrac opened this issue Jul 28, 2013 · 10 comments

Comments

@rcubetrac
Copy link

Reported by netesa on 28 Jul 2013 18:35 UTC as Trac ticket #1489267

One of my users regularly receives pdf files with wrong content-type set to text/html. Roundcube obviously displays a warning message while trying to open such attachments and this behaviour is OK. It is, however, also impossible to properly save such message parts as files. They are malformed while downloading.

I have tried to fix this error on my own, but this case appears to be more complex than I expected. I have found that function get_message_part (in line 2092) calls handlePartBody:

$body = $this->conn->handlePartBody($this->folder, $uid, true,
    $part ? $part : 'TEXT', $o_part->encoding, $print, $fp, $o_part->ctype_primary == 'text', $max_bytes);

As the mimetype is wrongly set to 'text/html' handlePartBody performs cleanup of text parts in line 2554:

else if ($formatted) {
    $line = rtrim($line, "\t\r\n\0\x0B") . "\n";
}

This malforms the attachment, which is binary (base64 encoded) but its type is set to text/html.

It seems to me that a nice solution to this problem would be detection of the real content-type by calling rcube_mime::file_content_type somwhere inside get_message_part.

Migrated-From: http://trac.roundcube.net/ticket/1489267

@rcubetrac
Copy link
Author

Comment by @alecpl on 29 Jul 2013 06:54 UTC

I suppose the problem is that there's no "Content-Transfer-Encoding: base64" header in the attachment part. If there would be such information the body wouldn't be malformed (the line you pointed wouldn't be executed). I think we won't implement a workaround for such case. Could you provide complete message body?

@rcubetrac
Copy link
Author

Status changed by @alecpl on 29 Jul 2013 06:54 UTC

new => closed

@rcubetrac
Copy link
Author

Comment by netesa on 29 Jul 2013 08:50 UTC

"Content-Transfer-Encoding: base64" is properly defined for such message. I have sent a sample message body to your email.

@rcubetrac
Copy link
Author

Comment by @alecpl on 29 Jul 2013 09:54 UTC

There's at least one issue here. The warning message is confusing. "Expected: text/html(.pdf);
detected: text/html(.html)". This is fixed in d59a8d2.

@rcubetrac
Copy link
Author

Comment by netesa on 29 Jul 2013 10:45 UTC

This patch seems to fix my the problem of the malformed file:

--- rcube_imap.php.orig 2013-07-28 14:27:18.000000000 +0200
+++ rcube_imap.php      2013-07-29 12:37:00.129516442 +0200
@@ -2122,7 +2122,8 @@

         if ($o_part && $o_part->size) {
             $body = $this->conn->handlePartBody($this->folder, $uid, true,
-                $part ? $part : 'TEXT', $o_part->encoding, $print, $fp, $o_part->ctype_primary == 'text', $max_bytes);
+                $part ? $part : 'TEXT', $o_part->encoding, $print, $fp,
+                $o_part->encoding != 'base64' && $o_part->ctype_primary == 'text', $max_bytes);
         }

         if ($fp || $print) {

@rcubetrac
Copy link
Author

Comment by @alecpl on 29 Jul 2013 12:24 UTC

The problem is when IMAP server supports BINARY extension. In such case downloaded attachment body (of text/* attachment) is "formatted", but shouldn't.

@rcubetrac
Copy link
Author

Status changed by @alecpl on 29 Jul 2013 12:24 UTC

closed => reopened

@rcubetrac
Copy link
Author

Milestone changed by @alecpl on 29 Jul 2013 12:24 UTC

later => 1.0-beta

@rcubetrac
Copy link
Author

Comment by @alecpl on 30 Jul 2013 17:17 UTC

Fixed in ae85336.

@rcubetrac
Copy link
Author

Status changed by @alecpl on 30 Jul 2013 17:17 UTC

reopened => closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant