Version: (using Devel) OS: Linux Installed from: Compiled sources When going through MS Exchange's IMAP, mail headers get mangled. So the encrypted message is not diplays decrypted inline, but as an attachment msg.asc. It would be nice to have a workaround, berhaps always treating msg.asc as an inline encrypted message. Example of the mangling: from: ######### ... MIME-Version: 1.0 Content-Type: multipart/encrypted; boundary="nextPart2290510.Q879XD5fpI"; protocol="application/pgp-encrypted" Content-Transfer-Encoding: 7bit Message-Id: ... Status: RO X-Status: RST X-KMail-EncryptionState: X-KMail-SignatureState: X-KMail-MDN-Sent: --nextPart2290510.Q879XD5fpI Content-Type: application/pgp-encrypted Content-Disposition: attachment Version: 1 --nextPart2290510.Q879XD5fpI Content-Type: application/octet-stream Content-Disposition: inline; filename="msg.asc" -----BEGIN PGP MESSAGE----- Version: GnuPG v2.0.9 (GNU/Linux) /* the message */ -----END PGP MESSAGE----- --nextPart2290510.Q879XD5fpI-- ############# to: ############# /*sent from received by, etc.*/ Content-Type: multipart/mixed; boundary="_003_20081129144621404cyrilledunantepflch_" MIME-Version: 1.0 X-UID: 2740 X-Length: 2781 Status: R X-Status: NT X-KMail-EncryptionState: X-KMail-SignatureState: X-KMail-MDN-Sent: --_003_20081129144621404cyrilledunantepflch_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --_003_20081129144621404cyrilledunantepflch_ Content-Type: application/pgp-encrypted; name="ATT00001" Content-Description: ATT00001 Content-Disposition: attachment; filename="ATT00001"; size=74; creation-date="Sat, 29 Nov 2008 14:46:22 GMT"; modification-date="Sat, 29 Nov 2008 14:46:22 GMT" Content-Transfer-Encoding: base64 VmVyc2lvbjogMQ== --_003_20081129144621404cyrilledunantepflch_ Content-Type: application/octet-stream; name="msg.asc" Content-Description: msg.asc Content-Disposition: attachment; filename="msg.asc"; size=1616; creation-date="Sat, 29 Nov 2008 14:46:22 GMT"; modification-date="Sat, 29 Nov 2008 14:46:22 GMT" Content-Transfer-Encoding: base64 /*encoded attachment*/ --_003_20081129144621404cyrilledunantepflch_--
Let's clarify some aspects of your report: Choose the right option: Option 1: * You compose an encrypted mail with kmail (using gpgp) * You send the message to an exchange server (to yourself?) * You receive your composed message changed. Option 2: * You compose an encrypted mail with kmail (using gpgp) * You send the message to an exchange server (to someone else) * You receive a forwarded or replyied mail and are unable to decrypt it. In case 1, there is little to do, except to use a standars compliant mail server. In case 2, it depens on the client that composed the mail you received. Please clarify.
Hi Cyrille. Thanks for reporting this bug. Unfortunately, if you wish for us to proceed with investigating it, we will need you to answer Jaime's question from Comment #1. Since this bug report has received no response for over a month I'm closing it, but please reopen it if you can answer the question above or provide aditional information about how to reproduce the bug.
Hmmm, I thought I had answered... it is option 1. Of course, it is Exchange's fault, I am just wishing for a workaround. Which would be that an attachment called msg.asc should always be decrypted and displayed inline.
May be it will be solved in kde 4.3. Plase read http://dot.kde.org/2009/01/31/computerworld-openchange-kde-bring-exchange-compatibility-linux
In kmail 1.12 (kde 4.3) (or recent 4.3 betas), there is an option in settings|Composer|Attachment about Outlook-Compatible attachment naming. Please, could you check if this solves this bug?
Message from Cyrille: Hmmm, I had not tested again. But the bug is fixed. Even without the option. This is probably due to the change of behaviour: kmail used to have encryption and signing separate, so when you would send a signed and encrypted message, the signature would be there, but the message only as an attachment (not decrypted inline, thus the bugreport). Now encrypted mails are marked only as "signed" but are properly decrypted. Weird. In any case barring the odd behaviour, this is working for me. Thank you very much. -- Cyrille Dunant