I don't know why, but it's good now.

Right. I mixed up commits/tickets.

It doesn't seem to be the same bug.

See also https://travis-ci.org/horde/horde/jobs/10019299 (PHP 5.5 only)

Sorry, but this commit messed up the previous good one 
(e3bff89cc6549b895c8aefdff4204b4044309ae8).

Now the EOL is wrong again. Please thet with the attached csv.

Changes have been made in Git (master):

commit e895486b0d566d7e050e7a8959af19d0234d5d09
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Mon Aug 5 01:55:44 2013 -0600

     Partially revert "[mms] Use the correct EOL string when transfer 
encoding content (Bug #12452)."

     This reverts commit e3bff89cc6549b895c8aefdff4204b4044309ae8.

     This needs to be fixed by doing auto-EOL determination

  framework/Mime/lib/Horde/Mime/Part.php      |   21 ++++++++++-----------
  framework/Mime/package.xml                  |    7 +++++++
  framework/Mime/test/Horde/Mime/PartTest.php |   18 +-----------------
  3 files changed, 18 insertions(+), 28 deletions(-)

http://git.horde.org/horde-git/-/commit/e895486b0d566d7e050e7a8959af19d0234d5d09

Horde_Mime 2.2.4

Changes have been made in Git (master):

commit e3bff89cc6549b895c8aefdff4204b4044309ae8
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Wed Jul 24 19:40:40 2013 -0600

     [mms] Use the correct EOL string when transfer encoding content 
(Bug #12452).

  framework/Mime/lib/Horde/Mime/Part.php |   13 +++++++++----
  framework/Mime/package.xml             |    4 ++--
  2 files changed, 11 insertions(+), 6 deletions(-)

http://git.horde.org/horde-git/-/commit/e3bff89cc6549b895c8aefdff4204b4044309ae8

Can you please test the attached test.csv if it's good for you after 
sending or not?

According to my observations, the csv content will have extra 
linefeeds, when it's content-transfer-encoding is quoted-printable. 
The encoding depends what the client sends to the server. From my XP 
machine if I send mail with attached csv the Content-Type is 
application/vnd.ms-excel and the Content-Transfer-Encoding is base64. 
In this chase the content of the csv is good.
But from other XP or Win7 machines regardless they have installed 
excel, the Content-Type is text/plain and the 
Content-Transfer-Encoding is quoted-printable. In this chase the csv 
content has extra linefeeds.

What other mail system do you think?
I tested this withhin horde, I sent email to myself.

I created and attached a very simple csv file.
Could you please test this?

No it doesn't.  We don't add ANY line feeds to output.  If any are 
being added, they are being added by another mail system other than 
Horde/IMP.

I realized, that even if I change Content-Type to text/csv it'll be wrong.
The real problem is the Content-Transfer-Encoding. If it's base64, the 
file will be good, but with quoted-printable encoding, the content 
will get extra linefeeds.

Why did you change to "Not a bug"?

The fact is that if the user doesn't have mime association to ".csv"   
then the file will be wrong.
It is a webmail problem, not the user's problem.

My suggestion is, if horde has the mime mapping even if it's "text/*" 
use that. It's more reliable than the fileinfo package.

It's because php fileinfo gives text/plain; charset=iso-8859-1 for 
that file, which is entirely wrong.

I have a file named: "Madalbal Sprinter Járat Export_20130712_104907.csv"

If I attach this file, horde threats this file as text/plain and in 
this way the csv gets extra 0x0a and 0x0d characters at the end of the 
rows.

It messes up the CSV

I don't know if the filename*1 field should contain the file extension only?

here is the relevant source what was generated:
---
--=_VlA-bfgbnALjE_FrMe9vhQ3
Content-Type: text/plain;
  name*0*=iso-8859-1''Madalbal%20Sprinter%20J%E1rat%20Export_20130712_104907.;
  name*1*=csv; charset=iso-8859-1
Content-Disposition: attachment; size=17681;
  filename*0*=iso-8859-1''Madalbal%20Sprinter%20J%E1rat%20Export_20130712_104;
  filename*1*=907.csv
Content-Transfer-Encoding: quoted-printable
---