Version: 4.8 (using KDE 4.8.0) OS: Linux Outlook 2003 or 2007 display the e-mails sent with the new KMail wrong: the signature is reported as invalid, the text itself shows "=" characters, for example: > Die Gleichheitszeichen deuten darauf hin, dass der quoted-printable Inh=lt > der E-Mail durch den von Ihnen verwendeten E-Mail-Client fehlerhaft > dekodiert wird und die fehlerhafte Ausgabe zu Signatur-Problemen führ=. The problem appeared with the upgrade to KMail 4.7: The problem did not occure with: > KMail/1.13.6 (Linux/2.6.38-10-generic; KDE/4.6.5; x86_64; ; ) > MIME-Version: 1.0 > Content-Type: application/pkcs7-mime; smime-type=enveloped-data; > name="smime.p7m" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; filename="smime.p7m" But the problem did occure with: > User-Agent: KMail/4.7.2 (Linux/3.0.0-12-generic; KDE/4.7.2; x86_64; ; ) > MIME-Version: 1.0 > Content-Type: application/pkcs7-mime; name="smime.p7m"; > smime-type=enveloped-data > Content-Transfer-Encoding: base64 We CC'ed the same e-mail to another user and decrypted the e-mail with openssl, etc. There everything looked fine. Reproducible: Always Steps to Reproduce: 1. Create a S/MIME signed e-mail with KMmail >= 4.7.2 . 2. Send this e-mail to someone using Outlook 2003 or 2007 . 3. Let it check the signature. Actual Results: The Outlook client reports the signature is broken and shows "=" chars where non should be shown. Expected Results: The Outlook client should just show the e-mail as correctly signed. It might very well be that this is an Outlook bug - but I am not fully sure. Also, the "=" chars do look like this might be an mime part decoding problem.
openSUSE 12.1 x86_64 KDE 4.9.0 Can confirm this. It seems that the CRLF is encoded wrong, which results in the equal signs shown in the received message. I did a quick test with the different character sets in the kmail-editor-settings. Changing the order of the used character sets doesn't helped (for my test-text). But it seems that if you delete every character set except UTF8 - so that kmail only use UTF8 for sending - the encoding and signature is correct in outlook and thunderbird. I will do a bit more testing also with attachments, and report back. May this is a work-around until this bug got fixed...
So I did a few test with KMail and Outlook 2007: Sign only: Signature OK, no equal character Encrypt only: equal characters are shown, where german "umlaute" like öäüß and CRLFs are in the original text Sign and encrypt: Signature broken, equal characters are shown, where german "umlaute" like öäüß and CRLFs are in the original text Against my first try UTF-8 isn't an option, it happens with all possible character set. For me it seems that the encryption and/or base64 encoding doesn't work right like Roland stated in his post, which certainly brakes the signature. If you look into the body of a mail, one sent with KMail and one with Thunderbird, you will see a different in the line ending. KMail only uses "=" while Thunderbird uses "=20" Here is a sample sent with KMail: sadhksdjh sadkhkjsadhkjhsad sakjhkajshd kasjhdkasjhd kjashdjhaskdhkasdk= jh asdhaksdj asdjhsad sadjhska dkajshdkjh adskdhkjhaskjdddjhasd asdhkja= sdh sdjhkashdkjh asdjhkjh asdkjh askjdh asdh asdjhkjhsadkjh asdkhk hsad= And this is a sample sent with Thunderbird: sadhksdjh sadkhkjsadhkjhsad sakjhkajshd kasjhdkasjhd=20 kjashdjhaskdhkasdkjh asdhaksdj asdjhsad sadjhska dkajshdkjh=20 adskdhkjhaskjdddjhasd asdhkjasdh sdjhkashdkjh asdjhkjh asdkjh askjdh=20 Hope this could give somebody a clue what went wrong.
Can you pease check with kmail 4.10.2, we improved the Content Transfer Encoding with that version? It would be great If you can give us the exact text you entered into kmail. Also great the right mail sended from thunderbird.
Created attachment 78938 [details] The text used for testing
Created attachment 78939 [details] Encrypted Mail sent with TBird
Created attachment 78940 [details] Encrypted Mail sent with KMail
(In reply to comment #3) > Can you pease check with kmail 4.10.2, we improved the Content Transfer > Encoding with that version? > It would be great If you can give us the exact text you entered into kmail. > Also great the right mail sended from thunderbird. Hi Sandro, thanks for taking care - too bad the result is still the same as described above. attached the text I used for testing. I copied the Emails out of the "Sent Messages" - Folder, and attached them. The most obvious difference in the encrypted messages is that the line length differ by 4 byte, but I don't know if this matters. But in the unencrypted messages there are many differences. The received versions from Outlook I will provide tomorrow, when I'm in the office
Created attachment 78941 [details] Un-encrypted messages
Okay I looked at your files and tryed on my own: All mails created with kmail are correct in the sense of RFCs. Okay kmail choos quoted-printable for encoding the text and tb choose 8bit (actually 8bit is not really save - Some mailserver destroy 8bit content, but that is another story :) Unfortunaltelly the most interesting part is hidden for me now. Can you encrypt the part the is actually send from tb? text.base64 (is the content of the mail send from thunderbird line 13-end) gpgsm -d --asume-base64 < /tmp/text.base64 That shows, how the mailtext is encoded. I actually think, that tb chooses also 8bit for Content-Transfer-Encoding or is this attachment 78941 [details]? I see no other relevate differences between tb and kmail till now. Just for you information: = - stands in quoted printiable for a line break, because the line is longer than 80 chars =20 - stands for a encoded space (see also wikipedia for an explanation)
(In reply to comment #9) Yep - attachment 78941 [details] contains the unencrypted messages with all header information: 6160 -> sent by KMail 6164 -> sent by TBird Unfortunately (or luckily ;-)) I wasn't in the office but tomorrow I will. Then I'll attache also how it looks in Outlook. At a first look I think Outlook does not interpret the line break, instead it displays the equal signs. And it looks like that TBird does not modify/format the message at all.
Created attachment 79000 [details] Received Mails how they look in Outlook These are the mails as they are received in Outlook. As I don't find any good export format (may I'm wrong with MS-Products ;-)) I place both mails as screenshot and standard text files.
Please can you run the gpgsm command i wrote before for the TB mail and the kmail mail?
Created attachment 79007 [details] TB-Message decoded with gpgsm
Created attachment 79008 [details] KMail-Message decoded with gpgsm
(In reply to comment #12) > Please can you run the gpgsm command i wrote before for the TB mail and the > kmail mail? I attached the output of gpgsm (79007 and 79008). The both tar balls contain 2 messages each. One that was only encrypted and one that was encrypted and signed (may you need both).
Many thank for these information. I think the problem lies at the side of Outlook, that can't handle quoted-printables right. But ok, that doesn't help you :) Let's try to prove, that this is actually the problem. Try to send an text without any special chars ( so 7bit can be used): Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. And one where kmail will use base64 (like tb used for the text): öüß äöüßäöüß äöüßäöüß äöüß äöüßöüß äöüß äöüß äöüßäöüß If these mails are shown correctly singend under Outlook, than actually the problem is Outlook.
Created attachment 79375 [details] Second try received Mails how they look in Outlook (In reply to comment #16) > If these mails are shown correctly singend under Outlook, than actually the > problem is Outlook. Hi Sandro, too bad - both have a broken signature. Looking at the qouted printable RFC I see that the max. line length should be 76 characters. While TB uses 72, in KMail options the default is 78. Also Microsoft stated this: http://msdn.microsoft.com/en-us/library/ms526941%28v=exchg.10%29.aspx So I thought - hey this could be a possible solution and I played with different LL. But this makes everything really worse. It seems that changing the default LL in KMail disables it and it has no effect in any way. I attached various screenshots, where the subject should give you the information of the sending options. BTW: I also send a mail from TB in quoted printable which is encrypted and signed correctly. Some other steps I investigated: In PHP there is a function quoted_printable_encode and -decode, which are often used for SMTP-Mails. The decoding function could decode the produced QP from KMail, but compared to the encoding function PHP produces a different result. I will try to produce an encrypted email with PHP, and I have also a Lotus Domino Mail-Server where I will try to reproduce the problem.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!