[Tickets #14807] Re: Broken File Names in Attachments when using ActiveSync

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://bugs.horde.org/ticket/14807
------------------------------------------------------------------------------
  Ticket             | 14807
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | Broken File Names in Attachments when using ActiveSync
  Queue              | IMP
  Version            | 6.2.21
  Type               | Bug
  State              | Not A Bug
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2018-11-22 17:09) wrote:

> Roundcube has a setting for that issue. Why do you do not have it?

Our MIME library actually *does* have that setting, and many, *many*  
years ago we provided a switch to enable it in our groupware apps from  
horde's configuration. We now explicitly do not use it in our  
applications because producing such output is explicitly breaking the  
standard. A standard that has been published for 20+ years and is  
understood by the vast majority of MUAs. To restate what was said in  
ticket:4733, RFC2047 explicitly forbids using an 2047 encoded word in  
any parameter of the Content-Type or Content-Disposition field.

See RFC 2047[5]:


    An [RFC 2047] 'encoded-word' MUST NOT be used in parameter of a

    MIME Content-Type or Content-Disposition field

RFC 2231[2] further explains the issue, and rationale for RFC 2231 in  
depth. It's too much to quote the full relevant text here, so I'll  
leave that up to the reader.

> https://bugs.horde.org/ticket/4733 is 12 years ago. It's not very  
> likely that Microsoft will change their mind. So why not use a way  
> that every Client understand?

Our normal approach to dealing with standards-related issues is to try  
to be lenient in the data we *receive* - implementing work arounds  
where feasible to accept data from broken sources...and heaven knows  
our ActiveSync code is littered with dozens of such work arounds  
because of the fragmented nature of the ActiveSync client landscape.  
However, we strive to always *produce* standard compliant data for  
other clients to consume.


> It'a also wrong what Michael wrote in https://bugs.horde.org/ticket/4733#c9
>
> " FYI, Opera, Thunderbird, and KMail (at a minimum) send w/ correct 2231
> encoding."
>
> As you see in my example this isn't the case for (at least)  
> Thunderbird. It encodes the Content-Type -> name attribute in 2047  
> while using 2231 for the Content-Disposition -> filename attribute.

Well, he was certainly not wrong at the time. This was clearly the  
case 12 years ago, when that ticket was created and I would argue that  
the "mixed" 2047/2231 version of the encoding is incorrect for the  
reasons stated above, and elsewhere.

> And this is exact the option that Roundcube provide (2047/2231  
> encoding). This seems to be the most compatible way to encode  
> non-ascii chars in attachment file names.

The beauty of open source means you are free to modify your own  
install to enable this behavior by setting the static parameter  
$broken_rfc2231 to true in your Horde_Mime library, though doing so is  
unsupported.