Attachments problem

[JVolt]

When an e-mail is sent by Mozilla Thunderbird with attachment filenames within special characters (like çâãó), the roundcube just don't show it in show page, but say theres an attachment when seen in e-mails list.

I has tested too many ways and attachment's names, and i think has discovered whats wrong.

When sending e-mails from thunderbird with special characters, it convert the filename to ascii! (something like %44%25%35%22...)

Then the roundcube can't show!

But i'm not able to fix it. :(

Is there someone saying about same problem, but him didnt explain correctly (​http://trac.roundcube.net/trac.cgi/ticket/1483824) and the post got tagged as duplicated.

So is there any possibility to make the roundcube read ascii filenames?

I'm not 100% sure thats the real problem, or is the one problem about that, but i think its.

Thanks very much, i hope can help.

[thomasb]

Please test this with the latest SVN trunk version. If you can reproduce it, please upload the full message source to ​http://testing.roundcube.net and provide the given Upload-ID here. We cannot fix this without a sample message.

[JVolt]

The upload-id is: 20070403_230632_9

I hope it can help.

[thomasb]

The attachment is specified as "inline" and the filename encoding is not recognized by RoundCube:

name*=ISO-8859-1''%61%6C%6F%E7%E3%6F%2E%64%6F%63

What encoding standard is this?

[r@…]

Section 4 of RFC 2231 ("MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations") seems relevant here. I don't know if the patch ​http://pear.php.net/bugs/bug.php?id=3636 applied in Mail_Mime 1.4.0a1 is useful - the author states, "I have modified mimeDecode so that it converts attachment file names into UTF-8. Attachment filenames on mails will now be converted from foreign character sets to UTF-8".

[r@…]

The following patch serves to illustrate the problem more than to fix it.

--- func.inc.20070408   Mon Apr  9 00:13:01 2007
+++ func.inc.new        Mon Apr  9 00:21:20 2007
@@ -975,7 +975,8 @@

       // part is file/attachment
       else if ($mail_part->disposition=='attachment' || $mail_part->disposition=='inline' || $mail_part->headers['content-id'] ||
-               (empty($mail_part->disposition) && ($mail_part->d_parameters['filename'] || $mail_part->ctype_parameters['name'])))
+               (empty($mail_part->disposition) && ($mail_part->d_parameters['filename'] || $mail_part->ctype_parameters['name'] || $mail_part->d_parameters['filename*'] || $mail_part->ctype_parameters['name*'] )))
+
         {
         // skip apple resource forks
         if ($message_ctype_secondary=='appledouble' && $secondary_type=='applefile')
@@ -984,13 +985,16 @@
         // part belongs to a related message
         if ($message_ctype_secondary=='related' && $mail_part->headers['content-id'])
           {
-          $mail_part->filename = rcube_imap::decode_mime_string($mail_part->d_parameters['filename']);
+          $mail_part->filename = rcube_imap::decode_mime_string($mail_part->d_parameters['filename']) ? $mail_part->filename = rcube_imap::decode_mime_string($mail_part->d_parameters['filename']) : $mail_part->filename = rcube_imap::decode_mime_string($mail_part->d_parameters['filename*']);
+
           $mail_part->content_id = preg_replace(array('/^</', '/>$/'), '', $mail_part->headers['content-id']);
           $sa_inline_objects[] = $mail_part;
           }
         // is regular attachment
         else if (($fname = $mail_part->d_parameters['filename']) ||
                  ($fname = $mail_part->ctype_parameters['name']) ||
+                 ($fname = $mail_part->d_parameters['filename*']) ||
+                 ($fname = $mail_part->ctype_parameters['name*']) ||
                  ($fname = $mail_part->headers['content-description']))
           {
           $mail_part->filename = rcube_imap::decode_mime_string($fname);
@@ -1022,6 +1026,8 @@
     {
     if (($fname = $structure->d_parameters['filename']) ||
         ($fname = $structure->ctype_parameters['name']) ||
+        ($fname = $structure->d_parameters['filename*']) ||
+        ($fname = $structure->ctype_parameters['name*']) ||
         ($fname = $structure->headers['content-description']))
       {
       $structure->filename = rcube_imap::decode_mime_string($fname);
@@ -1452,7 +1458,9 @@
   $attrib_str = create_attrib_string($attrib, array('id', 'class', 'style', 'cellspacing', 'cellpadding', 'border', 'summary'));
   $out = '<table '. $attrib_str . ">\n";

-  $filename = $part->d_parameters['filename'] ? $part->d_parameters['filename'] : $part->ctype_parameters['name'];
+  if (!$filename = $part->d_parameters['filename'] ? $part->d_parameters['filename'] : $part->ctype_parameters['name'])
+  $filename = $part->d_parameters['filename*'] ? $part->d_parameters['filename*'] : $part->ctype_parameters['name*'];
+
   $filesize = $part->size;

   if ($filename)

This causes the encoded word extension for the attachment ("ISO-8859-1' '%61%6C%6F%E7%E3%6F%2E%64%6F%63") to be displayed instead of the pretty name ("aloção.doc"), which I suppose is better than no attachment being displayed at all.

[jsalokan]

Is there available any "hotfix" for SVN edition yet? The code which r has given is very appreciated, but does not work in SVN edition. Sadly I went and upgraded the webmail first to it without thinking that it could be roundcube's problem.

[r@…]

I think the problem is avoided, if not completely fixed, in Changeset 540. See ​http://trac.roundcube.net/trac.cgi/changeset/540

[r@…]

I downloaded Changeset 540 and made this patch:

--- func.inc      Sun Apr  8 10:00:14 2007
+++ func.inc.new  Wed Apr 11 16:49:29 2007
@@ -999,7 +999,13 @@
         else
           {
           if (!$mail_part->filename)
-            $mail_part->filename = 'file_'.$mail_part->mime_id;
+            if ($filename_encoded_word = $mail_part->d_parameters['filename*'] ? $mail_part->d_parameters['filename*'] : $mail_part->ctype_parameters['name*'])
+            {
+            list($attachment_charset,,$urlencoded)=split('\'',$filename_encoded_word);
+            $mail_part->filename = rcube_charset_convert(urldecode($urlencoded), $attachment_charset);
+            }
+          else
+            $mail_part->filename = 'filse_'.$mail_part->mime_id;
           $a_attachments[] = $mail_part;
           }
         }
@@ -1502,4 +1508,4 @@
   }

Probably not the best or the brightest piece of code, but it does display "special" characters in attachment filenames.

[r@…]

And of course I fat-fingered the line:

+            $mail_part->filename = 'filse_'.$mail_part->mime_id;

which should read:

+            $mail_part->filename = 'file_'.$mail_part->mime_id;

[yanek]

I also needed this to get working above patch properly:

--- program/include/rcube_imap.inc (revision 541)
+++ program/include/rcube_imap.inc (working copy)
@@ -1121,6 +1121,22 @@
         $struct->parts[] = $this->_structure_part($part[8], ++$count, $struct->mime_id);
       }
       
+    if (!empty($struct->d_parameters['filename*0*'])) 
+    {
+      $filename = "";
+      for($iii=0; !empty($struct->d_parameters['filename*'.($iii).'*']); $iii++) 
+      {
+        $filename .= $struct->d_parameters['filename*'.($iii).'*'];
+      }
+      $struct->d_parameters['filename*'] = $filename;
+    }
+
+    if (!empty($struct->ctype_parameters['name*0*'])) 
+    {
+      $name = "";
+      for($iii=0; !empty($struct->ctype_parameters['name*'.($iii).'*']); $iii++) 
+      {
+        $name .= $struct->ctype_parameters['name*'.($iii).'*'];
+      }
+      $struct->ctype_parameters['name*'] = $name;
+    }
+

[thomasb]

Ticket #1484336 (with sample message) marked as duplicate of this bug.

[thomasb]

This needs more testing before adding to trunk. Maybe there's a simpler solution.

[romanex]

i try to apply changes find on this page but nothing help me. may be this can help?

---

Content-Transfer-Encoding: base64
Content-Type: text/plain; name="?????????????????? ???????????????? (2).txt"; charset="UTF-8"
Content-Disposition: attachment; filename="?????????????????? ????????????????.txt"

---

what can i try to do else?

[mattenklicker]

I have a similar problems with attachments generated by mutt. Attachments are displayed, but with names like "Part 2" "Part 3".

Coding example from mutt:

Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename*=iso-8859-1''test%A7mail


--UugvWAfsgieZRqgk
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename*=iso-8859-1''umlautt%E4%DFt
Content-Transfer-Encoding: 8bit

asdf

--UugvWAfsgieZRqgk--

[till]

Screenshot (latest svn)

[till]

I just attached a screenshot, can anyone verify this is still happening?

[till]

New upload ID: 20080211_211509_2 (by yllar)

[till]

Seems to work (per feedback from IRC), and I cannot recreate it either.

If you use a funky language (like Japanese, etc.) please supply a sample and re-open the ticket. Also make yourself available for questions. ;-))

[thomasb]

This does not yet work for me. I'll verify the patches and add them to the trunk.

[thomasb]

Fixed in [ddc34f98].

We now do charset decoding as specified in ​http://www.faqs.org/rfcs/rfc2231.html for file names.