search

roundcube / roundcubemail

The Roundcube Webmail suite
https://roundcube.net
GNU General Public License v3.0
5.79k stars 1.62k forks source link

Roundcube break attachment with special characters #5772

Closed gonzalo- closed 7 years ago

gonzalo- commented 7 years ago

Hi guys,

I have some issue with Roundcube 1.2.4 over OpenBSD 6.1. Users can't download properly attachments with special characters like accents, e.g Canción.docx or stuff like that.

At the moment of download the file, the name is cut off to Canci and even if I rename the file, is still broken, if I forward the mail to gmail or something, I can open it just fine.

Any idea? Is a know issue?

Thanks.

alecpl commented 7 years ago

I don't see how that could happen. I mean the broken name issue is a separate issue from the broken content issue. Sample message source also could be useful to make sure it's valid and to test on another Roundcube instance.

What web server? What browser? What plugins?

gonzalo- commented 7 years ago

Sure.

Sample message source:

MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="=_84aaf1e54c831b7b9545f5da0f879dac"
Date: Fri, 26 May 2017 16:18:23 -0300
From: =?UTF-8?Q?xxx_S=C3=A1nchez?= <xxx@xxx.xxx>
To: xxxx@gmail.com
Subject: =?UTF-8?Q?Fwd=3A_Cotizaci=C3=B3n_de_seguro_=28Hugo_/_Do?=
 =?UTF-8?Q?minio_IDO-624=29=2E?=
Organization: XXXX
In-Reply-To: <b5a15197f0252df7352c104144d98b2@xxx.xxx>
References: <b5a15197f02df7352c104144d98b2@xxx.xxx>
Message-ID: <23976ce907c14c17180eecb291855@xxx.xxx>
X-Sender: xxx@xxx.xxx
User-Agent: Roundcube Webmail/1.1.4

--=_84aaf1e54c831b7b9545f5da0f879dac
Content-Type: multipart/alternative;
 boundary="=_9d88323d2214de7fcdf84310eaf2f08a"

--=_9d88323d2214de7fcdf84310eaf2f08a
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

-------- Mensaje original -------- 

        ASUNTO:
        Cotización de seguro (Dominio IDO-624).

        FECHA:
        2017-05-04 15:08

        REMITENTE:
        xxx@xxx.xxx

        DESTINATARIO:
        Matias Vergara <xxx@xxx.xxx>, Gestion 
<xxx@xxx.xxx>

Adjunto otra cotización. 

-- 
P

--=_9d88323d2214de7fcdf84310eaf2f08a
Content-Type: multipart/related;
 boundary="=_fc42fbac7542b39dd1475acbb0fdad89"

--=_fc42fbac7542b39dd1475acbb0fdad89
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=
eva,sans-serif'>
<p>&nbsp;</p>
<p>-------- Mensaje original --------</p>
<table border=3D"0" cellspacing=3D"0" cellpadding=3D"0">
<tbody>
<tr>
<th align=3D"right" valign=3D"baseline" nowrap=3D"nowrap">Asunto:</th>
<td>Cotizaci&oacute;n de seguro (Trimarco Hugo / Dominio IDO-624).</td>
</tr>
<tr>
<th align=3D"right" valign=3D"baseline" nowrap=3D"nowrap">Fecha:</th>
<td>2017-05-04 15:08</td>
</tr>
<tr>
<th align=3D"right" valign=3D"baseline" nowrap=3D"nowrap">Remitente:</th>
<td>xxx@xxx.xxx</td>
</tr>
<tr>
<th align=3D"right" valign=3D"baseline" nowrap=3D"nowrap">Destinatario:</th=
>
<td>Matias &lt;xxx@xxx.xxx&gt;, Gestion Productores &lt;ge=
xxx@xxx.xxx&gt;</td>
</tr>
</tbody>
</table>
<p>&nbsp;</p>
<!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<div>&nbsp;</div>
<div>-- <br />
<p><strong><em>XXX</em><br /></strong>P.A.S. Mat. N&ordm;=
 70.671<br /><strong>Cel.</strong> 155 6155 4010<br /><br /> <img src=3D"ci=
d:051a550524ba683e336312e29aa28f75@xxx.xxx" alt=3D"" width=3D"13=
1" height=3D"83" /></p>
</div>
</body></html>

--=_fc42fbac7542b39dd1475acbb0fdad89
Content-Transfer-Encoding: base64
Content-ID: <051a550524ba683e336312e29aa28f75@xxx.xxx>
Content-Type: image/png;
 name=051a5505.png
Content-Disposition: inline;
 filename=051a5505.png;
 size=12914

iVBORw0KGgoAAAANSUhEUgAAAk8AAAF3CAYAAAC8Bq8zAAAACXBIWXMAABcSAAAXEgFnn9JSAAAA
[cut]
--=_fc42fbac7542b39dd1475acbb0fdad89--

--=_9d88323d2214de7fcdf84310eaf2f08a--

--=_84aaf1e54c831b7b9545f5da0f879dac
Content-Transfer-Encoding: base64
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document;
 name="=?UTF-8?Q?Cotizaci=C3=B3n_de_Seguro_Automotor=2Edocx?="
Content-Disposition: attachment;
 filename*=UTF-8''Cotizaci%C3%B3n%20de%20Seguro%20Automotor.docx;
 size=56132

UEsDBBQABgAIAAAAIQBdiaa1kgEAAMAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
[cut]
L3N0eWxlc1dpdGhFZmZlY3RzLnhtbFBLBQYAAAAADgAOAI8DAACf1wAAAAA=
--=_84aaf1e54c831b7b9545f5da0f879dac--

This is a server with OpenBSD, using httpd native web server with php-fpm. And this happen if I try to download the file with firefox or chrome from OSX and Windows. And the plugins are:

$config['plugins'] = array(
    'archive',
    'zipdownload'
);

Thanks

alecpl commented 7 years ago

This works perfectly for me. I suppose you'll have to debug what exactly is returned when requesting the attachment in http headers and body. Do you use compression on http level? Try with disabled.

gonzalo- commented 7 years ago

No, no compression. Is weird. :/

nevun commented 7 years ago

I had the same problem, for some reason the addcslashes-encoding of the filename in Content-Disposition header makes some component confused and part of the filename adds up in the body instead of the header. This workaround solves it for me:

--- program/steps/mail/get.inc.orig     Tue Jun 13 14:20:50 2017
+++ program/steps/mail/get.inc  Tue Jun 13 16:35:43 2017
@@ -306,10 +306,7 @@

             $filename = rcmail_attachment_name($part);

-            if ($browser->ie)
-                $filename = rawurlencode($filename);
-            else
-                $filename = addcslashes($filename, '"');
+            $filename = rawurlencode($filename);

             $disposition = !empty($plugin['download']) ? 'attachment' : 'inline';
gonzalo- commented 7 years ago

Awsome! this fix the issue! Any chance to have this upstream?

alecpl commented 7 years ago

Maybe it's time to use RFC 2231. This page should help us to choose the solution: http://greenbytes.de/tech/tc2231/. I'm thinking about this sample: http://greenbytes.de/tech/tc2231/#attwithfn2231utf8 or this: http://greenbytes.de/tech/tc2231/#attfnboth

gonzalo- commented 7 years ago

IMHO the first link sounds good to me ( http://greenbytes.de/tech/tc2231/#attwithfn2231utf8 ).

nevun commented 7 years ago

Yes, moving to using rfc2231 seems like a good idea.

For the record: in this case the OpenBSD httpd stops parsing the http header from php when it detects a character that is not in the ISO-8859-1 character set. Unfortunately it just leaves the rest of the header in the buffer and this is why this eventually ends up in the content and corrupts the attachment.

alecpl commented 7 years ago

Fixed.