Version: 1.6.2 (using KDE KDE 3.2.2) Installed from: Debian testing/unstable Packages OS: Linux When KMail Base64 encodes 8-bit text, it doesn't produces canonical form of it by replacing LFs with CRLFs. As a result, mailers on 8-bit clean channels strip the LFs from the message on decoding and it becomes quite unreadable.
Looks like this bug causes problems with my ISP mail server which recodes messages from base64 to 8 bits.
My little research shows that kmail has this problem for several years now. It was discussed elsewhere: http://lists.altlinux.ru/pipermail/sisyphus/2003-January/017525.html When kmail base64-encoded messages are recoded to 8-bit by MTA linefeeds are stripped out.
The situation is the same for versions 1.7.1 and 1.7.2.
*** This bug has been confirmed by popular vote. ***
The situation is the same for 1.8.2 !
I have same bug with email messages going from gmail.com accounts. I wonder how come gmail.com suffered with a same bug.
As for me this is not kmail problem
then which problem is it?
KMail just need to replace \n with \r\n before encoding (to base64 or quoted-printable) and before sending letters.
Apparently works correctly in 3.5.2 ! Could anyone else check on 3.5.2 or later?
any update on kmail in current linux distros? or maybe close as this bug is old and may not reproduce on current kmail version. can't try myself since not using kde for a long time now, just revisiting bugs i'm voted on.
I'll check it in a few days. Don't close it for a while.
...so, is this still valid?
This seems to be no issue anymore. Closed as remind. Please reopen if it still exists.
Yes, it is valid for KMail 1.11.0 from KDE 4.2.0.
*** Bug 122892 has been marked as a duplicate of this bug. ***
Is it valid with KMail2? I have a feeling it is not, but please confirm it.
No feedback since September. Closing
Please correct me if I get this wrong. This is bascially about RFC2045 – RFC2049? When creating an attachment of MIME type text/plain, it may be encoded as base64. According to RFC2049, it must be converted into a canonical form, which means for text/plain that LF must be converted to CRLF. If this is correct, then this seems to be still broken. I just sent an email through KMail2 with a text file "res.txt" attached that consists only of LF LF. In the transmitted email, the attachment looks like this: Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="UTF-8"; name="res.txt" Cgo= When decoding Cgo=, you will notice that it still reads LF LF instead of CRLF CRLF.