Changes have been made in Git (master):

commit 9f37b38f3f228134044db125b8519239e7b89e21
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Mon Feb 9 23:01:34 2015 -0700

     Use base64 encoding if that is defined as the default for a 
primary MIME type (Bug #13835)

     Not needed under MIME rules, but working around broken attachment data
     is not worth tracking down, especially in light of the recent PHP memory
     stream issues

  framework/Mime/lib/Horde/Mime/Part.php |   14 ++++++++++++--
  1 files changed, 12 insertions(+), 2 deletions(-)

http://github.com/horde/horde/commit/9f37b38f3f228134044db125b8519239e7b89e21

Changes have been made in Git (master):

commit a40480ee6e352c25fbb8ba98cdc0da39072bed10
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Sun Feb 8 04:49:11 2015 -0700

     [mms] Work around broken line-oriented data when transfer 
encoding (Bug #13835).

  framework/Mime/lib/Horde/Mime/Filter/Encoding.php  |   26 
++++++++++++++++++++
  framework/Mime/lib/Horde/Mime/Part.php             |    1 +
  framework/Mime/package.xml                         |    2 +
  .../Mime/test/Horde/Mime/Filter/EncodingTest.php   |   16 ++++++++++++
  4 files changed, 45 insertions(+), 0 deletions(-)

http://github.com/horde/horde/commit/a40480ee6e352c25fbb8ba98cdc0da39072bed10

It seems I can't attach the files, so here are they:
This is what I attached in horde
http://people.fsn.hu/~bra/horde/orig.es3
and this is what I got in gmail:
http://people.fsn.hu/~bra/horde/gmail.es3

Horde sends the e-mails through a postfix (2.11.1) server.

Maybe I'm misunderstanding something here, but for me exactly means 
it's exactly the same, but it's not:
$ md5sum orig.es3 gmail.es3
1e5ff3a4beff2589882afa87abd56c81  orig.es3
01c974b662f8f187edf4207f7ce24852  gmail.es3

And they aren't the same even when I do "by translating both the 
two-character sequence #xD #xA and any #xD that is not followed by #xA 
to a single #xA character".
because the SMTP server (postfix) breaks lines, which (both this and 
the CRLF issue) is not the case when you encode it in base64.
BTW, our users ask that if they attach a file, it should be the same 
on the receiving side. This is the case with gmail, outlook.com, 
fastmail, outlook etc, but not with horde. I can't tell them you 
should normalize your XMLs, because they are not generating or parsing 
them.
To them the issue is if they send the files with horde, it'll break. 
If they send it with whatever else, it won't.

I will attach two files, orig.es3, which is I sent as an attachment, 
and gmail.es3 which I got in gmail. If I feed the gmail.es3 into an 
XML parser (http://validator.w3.org/check), the original validates 
while the received one breaks on multiple points (the line breaks).

I've just found this:
"Your browser is incorrectly reporting the file as 'text/something'
when uploading.  That's the only way we would be non-base64 encoding
an attachment."
When this statement became false?

You are incorrect.  http://www.w3.org/TR/REC-xml/#sec-line-ends

When normalized as is required, the data is EXACTLY the same as when sent.
False.  Directly from the MIME RFC:

"It may seem that the Content-Transfer-Encoding could be
inferred from the characteristics of the media that is to be encoded,
or, at the very least, that certain Content-Transfer-Encodings could
be mandated for use with specific media types.  There are several
reasons why this is not the case."

When I attach an .es3 (mime type application/vnd.eszigno3, uploaded by 
the browser as application/octet-stream) file and the destination SMTP 
server supports 8BITMIME ESMTP extension, Horde encodes the attachment 
as 8bit and not as base64 as it should.
This means the attachment will be converted to CRLF line endings and a 
CRLF will be inserted after 998 characters by the SMTP server if a 
line is longer than that, therefore breaking the XML parser on the 
receiver end and breaking any checksum validations.

If I disable 8BITMIME extension, the attachment is encoded as base64 
and is not modified at all.

AFAIK, Horde should base64 encode any non text/* mime types.

The attached file doesn't have any long lines, but from the SMTP 
capture it can be seen that it's not base64 encoded if the 8BITMIME 
extension is announced.

I can upload long line files on request of course.