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

* Your Email Address
* Spam protection	Enter the letters below: . .. ..__..__.. . \| \|\|\/\|\| \|[__]\| \| \|__\|\| \|\|__\\| \|\|/\\|
Comment	>> 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. >
Attachment
Watch this ticket

Saved Queries