Bug 184919 - Kmail changes newline encoding to Unix on attachment files
Summary: Kmail changes newline encoding to Unix on attachment files
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kmail2
Classification: Applications
Component: general (show other bugs)
Version: 4.9.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-19 11:20 UTC by Sebastian Voitzsch
Modified: 2017-01-07 22:14 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Voitzsch 2009-02-19 11:20:36 UTC
Version:            (using KDE 4.2.0)
OS:                Linux
Installed from:    Ubuntu Packages

When attaching a text file to a mail, KMail changes the newline encoding to Unix format (line feed only instead of carriage return/line feed pair for Windows).

Expected is that files are leaved untouched when attaching them to a mail.

How to reproduce: open a new mail, select "attach file". Select a file with known Windows cr/lf encoding and attach it to the mail. The file gets attached, and the "size" attribute right then shows a different size due to the removed cr chars. Right-clicking the attachment and selecting "open" will open the file with Kate, "extras->newline" will show "Unix" instead of "Windows/Dos".
Comment 1 Jaime Torres 2009-02-22 12:21:35 UTC
What encoding do you use for the attached file before sending it?
One you have attached a file in composer, use right click over the attachment list in the composer window and select the encoding you want for the attached file.


Reading in rfc 1521

The difference between "8bit" (or any other conceivable bit-width
   token) and the "binary" token is that "binary" does not require
   adherence to any limits on line length or to the SMTP CRLF semantics,
   while the bit-width tokens do require such adherence.  If the body
   contains data in any bit-width other than 7-bit, the appropriate
   bit-width Content-Transfer-Encoding token must be used (e.g., "8bit"
   for unencoded 8 bit wide data).  If the body contains binary data,
   the "binary" Content-Transfer-Encoding token must be used
Comment 2 aw81 2009-03-09 09:04:55 UTC
Is there a way to set the default encoding?
Comment 3 Thomas Arend 2012-08-29 17:29:05 UTC
Kmail2 editor does not comply with RfC 822 and uses only "lf" instead of "cr-lf" at the end of a  line.  Especially in quoted-printable and MIME Extensions

See:

RfC 822, 2045 Point 2.10. Lines
Comment 4 Myriam Schweingruber 2012-08-29 17:37:18 UTC
Reassigning to Kmail2
Comment 5 Denis Kurz 2016-09-24 18:09:07 UTC
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?

If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.
Comment 6 Denis Kurz 2017-01-07 22:14:31 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.