-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
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? |
Status changed by @alecpl on 29 Jul 2013 06:54 UTC new => closed |
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. |
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) { |
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. |
Status changed by @alecpl on 29 Jul 2013 12:24 UTC closed => reopened |
Milestone changed by @alecpl on 29 Jul 2013 12:24 UTC later => 1.0-beta |
Status changed by @alecpl on 30 Jul 2013 17:17 UTC reopened => closed |
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:
As the mimetype is wrongly set to 'text/html' handlePartBody performs cleanup of text parts in line 2554:
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
The text was updated successfully, but these errors were encountered: