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 |
sorry for the misleading RFC.
So this is a long known issue that Horde (and only Horde) ignore?
That sounds quite absurd.
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.
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.
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.
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
encoding data in email headers. It's the RFC that defines
multipart/form-data used when submitting HTML forms.
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 inany 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.
likely that Microsoft will change their mind. So why not use a way
that every Client understand?
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.
" 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.
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.
encoding). This seems to be the most compatible way to encode
non-ascii chars in attachment file names.
install to enable this behavior by setting the static parameter
$broken_rfc2231 to true in your Horde_Mime library, though doing so is
unsupported.
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)
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.
State ⇒ Not A Bug
encoded parameters.
See
Ticket: 4733,Ticket: 14241, and any number ofreports/discussions/blog posts searchable via google.
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===========
New Attachment: test_file_inside.zip
I attach it again in a zip (with an iso file name)
New Attachment: ??????????.docx
1. Create a new mail in horde - attach it
2. Get it by EAS (Outlook)
---> The attachment is now "Unbenannte Anlage 000004.docx"
Assigned to Michael Rubinsky
State ⇒ Feedback
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.
Patch ⇒ No
State ⇒ Unconfirmed
Milestone ⇒
Queue ⇒ IMP
Summary ⇒ Broken File Names in Attachments when using ActiveSync
Type ⇒ Bug
Priority ⇒ 1. Low
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"