6.0.0-beta1
7/27/25

[#14807] Broken File Names in Attachments when using ActiveSync
Summary Broken File Names in Attachments when using ActiveSync
Queue IMP
Queue Version 6.2.21
Type Bug
State Not A Bug
Priority 1. Low
Owners mrubinsk (at) horde (dot) org
Requester rene.marth (at) hetzner (dot) de
Created 04/12/2018 (2663 days ago)
Due
Updated 11/23/2018 (2438 days ago)
Assigned 10/23/2018 (2469 days ago)
Resolved 11/21/2018 (2440 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
11/23/2018 06:30:13 PM Michael Rubinsky Comment #12 Reply to this comment
Hi Michael,

sorry for the misleading RFC.

So this is a long known issue that Horde (and only Horde) ignore? 
That sounds quite absurd.
What's absurd is failing to follow accepted standards. "Fixing" this 
by implementing an undefined behavior in order to support the few 
clients that are broken at the expense of breaking the behavior for 
clients that implement this correctly is equally absurd. If we need to 
choose between supporting clients that work correctly with the 
standards, or support the few clients that do not while potentially 
breaking behavior for those that do, the choice is clear.  For those 
people that prefer the broken behavior and the risks that come with 
it, well, it's open source software. It can be modified. There are 
also, as you indicate, other products that have chosen to produce 
broken email headers that they can use.
"I'm RFC conform and I do not care if my software is usable in the 
real world or not" - Is that really the way you want to go? The 
developers of other OS software like Thunderbird/Roundcube have 
another approach that makes more sense (at least IMHO) because it 
prefer usability over rfc conformity.
It's not about "prefering" it. It's about producing output that is 
correctly understood by any properly functioning MUA. It's about 
keeping our software current. It's about not perpetuating the problem. 
Purposely producing broken data is the opposite of good software: "Our 
software doesn't work with your MUA because we have to support a MUA 
that doesn't follow the standard."  RFC 2231 exists for a reason. It's 
a standard. We produce output that conforms to it, and other relevant 
standards. Choosing not to conform to the standards completely defeats 
the purpose of a standard.

[Show Quoted Text - 15 lines]
This looks correct.


11/23/2018 10:06:29 AM rene (dot) marth (at) hetzner (dot) com Comment #11 Reply to this comment
Hi Michael,

sorry for the misleading RFC.

So this is a long known issue that Horde (and only Horde) ignore? That 
sounds quite absurd.

"I'm RFC conform and I do not care if my software is usable in the 
real world or not" - Is that really the way you want to go? The 
developers of other OS software like Thunderbird/Roundcube have 
another approach that makes more sense (at least IMHO) because it 
prefer usability over rfc conformity.

However: Just for completeness for all other frustrated users - here 
are the 2 files that needs to patched

Line 140: .../Horde/Mime/Headers/ContentParam.php

Add: 'broken_rfc2231' => true,

Line 305: .../Horde/Mime.php

Replace: public static $brokenRFC2231 = false;
With: public static $brokenRFC2231 = true;

... = path to your horde - at my installation it is /usr/share/php/

@Michael: feel free to correct my patch if I haven't guessed correct

11/22/2018 05:12:06 PM Michael Rubinsky Comment #10 Reply to this comment
What do you think about https://www.ietf.org/rfc/rfc2388 ?
I'm not sure how this is relevant. RFC 2388 has nothing to do with 
encoding data in email headers. It's the RFC that defines 
multipart/form-data used when submitting HTML forms.
11/22/2018 05:09:17 PM Michael Rubinsky Comment #9 Reply to this 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.

11/22/2018 07:50:27 AM rene (dot) marth (at) hetzner (dot) com Comment #8 Reply to this comment
What do you think about https://www.ietf.org/rfc/rfc2388 ?

3. Definition of multipart/form-data
[...]
"Field names originally in non-ASCII character sets may be encoded
    within the value of the "name" parameter using the standard method
    described in RFC 2047."

4.4 Other attributes
[...]
The original local file name may be supplied as well, either as a
    "filename" parameter either of the "content-disposition: form-data"
    header or, in the case of multiple files, in a "content-disposition:
    file" header of the subpart. The sending application MAY supply a
    file name; if the file name of the sender's operating system is not
    in US-ASCII, the file name might be approximated, or encoded using
    the method of RFC 2231.

Isn't that exactly the method Thunderbird is using? (and that works 
with the tested mail clients)
11/22/2018 07:37:35 AM rene (dot) marth (at) hetzner (dot) com Comment #7 Reply to this comment
Roundcube has a setting for that issue. Why do you do not have it? 
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?

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.

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.
11/21/2018 03:05:33 PM Michael Rubinsky Comment #6
State ⇒ Not A Bug
Reply to this comment
This is indeed, Outlook (still) not correctly supporting RFC 2231 
encoded parameters.

See Ticket: 4733, Ticket: 14241, and any number of 
reports/discussions/blog posts searchable via google.
11/21/2018 08:17:40 AM rene (dot) marth (at) hetzner (dot) com Comment #5 Reply to this comment
Just an additional note: Windows Mail with IMAP does not show the 
attachment at all. In Thunderbird (IMAP) it works. Here are the 
relevant headers:

========HORDE START===========

[...]
User-Agent: Horde Application Framework 5
Content-Type: multipart/mixed; boundary="=_sSjubC64Y53vvOhHRiY0HDy"
MIME-Version: 1.0
[...]

Text-Part:
--=_sSjubC64Y53vvOhHRiY0HDy
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline

Attachment:
--=_sSjubC64Y53vvOhHRiY0HDy
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline

--=_sSjubC64Y53vvOhHRiY0HDy
Content-Type: 
application/vnd.openxmlformats-officedocument.wordprocessingml.document;
  name*0*=utf-8''%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%81%AE%E5%90%8D%E5%89%8D%E3;
  name*1*=%83%95%E3%82%A1%E3%82%A4%E3%83%AB.docx
Content-Disposition: attachment; size=12054;
  filename*0*=utf-8''%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%81%AE%E5%90%8D%E5%89%8D;
  filename*1*=%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB.docx
Content-Transfer-Encoding: base64

[...]
--=_sSjubC64Y53vvOhHRiY0HDy--

========HORDE END===========

And here the same email but created with Thunderbird:

========THUNDERBIRD START===========
[...]
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
  Thunderbird/60.0
MIME-Version: 1.0
Content-Type: multipart/mixed;
  boundary="------------A1CD64BC9E4F9663CCD7485B"
[...]

Text-Part:
--------------A1CD64BC9E4F9663CCD7485B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Attachment:
--------------A1CD64BC9E4F9663CCD7485B
Content-Type: 
application/vnd.openxmlformats-officedocument.wordprocessingml.document;
  name="=?UTF-8?B?5pel5pys6Kqe44Gu5ZCN5YmN44OV44Kh44Kk44OrLmRvY3g=?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
  filename*0*=utf-8''%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%81%AE%E5%90%8D%E5%89%8D;
  filename*1*=%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%2E%64%6F%63%78
========THUNDERBIRD END===========

11/21/2018 07:55:26 AM rene (dot) marth (at) hetzner (dot) com Comment #4
New Attachment: test_file_inside.zip Download
Reply to this comment
It seems that even your bugtracker does not support this kind of files...

I attach it again in a zip (with an iso file name)
11/21/2018 07:52:40 AM rene (dot) marth (at) hetzner (dot) com Comment #3
New Attachment: ??????????.docx
Reply to this comment
You can use this file to test.

1. Create a new mail in horde - attach it
2. Get it by EAS (Outlook)

---> The attachment is now "Unbenannte Anlage 000004.docx"
11/16/2018 03:12:07 PM Michael Rubinsky State ⇒ No Feedback
 
10/23/2018 01:20:20 AM Michael Rubinsky Comment #2
Assigned to Michael Rubinsky
State ⇒ Feedback
Reply to this comment
IIRC, this had something to do with some broken MIME header that 
outlook produces. If you can provide a full sync log showing the data 
being transmitted, I can look.  I receive attachments with special 
characters fairly frequently and they are displayed fine in my 
ActiveSync client.
04/12/2018 08:47:27 AM rene (dot) marth (at) hetzner (dot) de Comment #1
Patch ⇒ No
State ⇒ Unconfirmed
Milestone ⇒
Queue ⇒ IMP
Summary ⇒ Broken File Names in Attachments when using ActiveSync
Type ⇒ Bug
Priority ⇒ 1. Low
Reply to this comment
Attachment file names gets broken if they contain special chars (like 
German umlauts) - happens with Active Sync (tested on Outlook).

Steps to reproduce:

1. Create a mail that contains an attachment with a file name like 
"Ättachment.dwg"
2. Get this mail via Active Sync (Outlook 2013+16 tested)

Expected: Mail contains an attachment "Ättachment.dwg"
Result: Mail contains an attachment "Unbenannte Anlage 0000XXXX.dat"

Saved Queries