Attachments names rejected by mailserver

[delboy711]

I regularly get complaints from people who receive mails generated by roundcubemail  0.3  that attachments are not readable.

On examination I find that their mailserver (Exchange?) is replacing the attachment filename with names in the format ATTXXXXXX.dat.

So a mail that starts out with an attachment as :-

Code Select Expand

Content-Transfer-Encoding: base64
Content-Type: application/application-pdf;
 name*="UTF-8''Tallbo_25_Pool.pdf";
Content-Disposition: attachment;
 filename*="UTF-8''Tallbo_25_Pool.pdf";

Arrives at its destination as :-

Code Select Expand

Content-Type: application/pdf;
name="ATT226730.dat"
Content-Transfer-Encoding: base64
Content-Description: ATT226730.dat
Content-Disposition: attachment;
filename="ATT226730.dat"

The only difference I can see between the way Roundcubemail handles attachments compared to Kmail or Thunderbird is the way it includes the character set in the file name separated by two single quotes. I suspect it is this Exchange is taking exception to.

Can anyone give me a hint how to stop Roundcubemail doing this? None of the configuration settings make any difference.

[delboy711]

After further study I can see Roundcube is encoding the attachment in compliance with RFC 2231. So it looks as if the remote mailserver/client has a problem with RFC2231.

I have tried setting mime_param_folding to 1 and 2 to select RFC 2047 but it makes no difference to the encoding of attachments. Nor does setting the user encoding preference.  

Can anyone point me to the code where it selects between RFC2231 and RFC 2047 encoding? I have looked but cannot find it.

[delboy711]

I found the problem.
I had installed using the GPL dependent version of roundcubemail so I did not have the modified mimePart.php  introduced in changeset 1897 to fix bug 1485320

#1485320 (attachment names wrong in Outlook) ? Roundcube Webmail
Changeset 1897 ? Roundcube Webmail


Installing the 'complete' version of roundcubemail fixed the problem.

To avoid similar problems in the future shouldn't mimePart.php be included in the dependent download?