Distro: Archlinux x86_64 (kernel 3.12.9-2-ARCH) Summary: Trying to reply to decrypted s/mime email messages is made difficult by the lack of original sender's information being supplied to the compose windows To: line and template fields. Test case 1: Receive smime encrypted email and decrypt. Decrypted content appears in message preview pane. Top of preview does not contain From: To: Subject: or Date: lines. When hitting reply, the address box (To:) is left blank and the message templates do not contain any information (e.g. instead of "On <date>\n<sender> wrote:" the reply composition consists of "On \n wrote:"). Test case 2: Receive smime encrypted email and do not supply password -- decryption fails. In this case, the preview pane contains: From: <sender> To: <recipient> Subject: <subject> Date: <date with tz> [smime.p7m application/x-pkcs-7-mime (size) ] Further details: Using the icons on the right side of the message preview pane, the top icon usually contains the full email (message/rfc822), and the icons below contain any decrypted content and then the "gear" icon for the pk7 content (signature, etc). In test case 1: the "@" icon (message/rfc822) contains just the text part + the pk7 part, the text icon contains the message/text part, and the gear contains the pk7 part. When clicking on the gear icon, a duplicate icon of the message/text appears directly above the gear icon. In text case 2: the "@" icon contains the generic headers (From: To: Subject: Date:) , a blank body, and the pk7 attachment. The only other icon is the pk7 icon.
*** Bug 3449 has been marked as a duplicate of this bug. ***
When enabling "Display header pane above message view" this pane will show the correct from, to and subject information about the message. It seems that in the function messageview_show (messageview.c) it first parses the file (in the cache) which contains the normal headers and an attachment smime.p7m (for a signed, not encrypted, message at least). After that it sees the smime file and verifies it and stores the result in a tmpfile in the ~/.claws-mail/tmp/ directory. Then it parses this file and uses that to display the (multi-part) message. When I run claws-mail --debug I see the following in the debug log: imap.c:1589:message 3 has been already fully cached. procheader.c:174:generic_get_one_field: empty line message/rfc822 (offset:0 length:26564 encoding: 6) application/pkcs7-mime (offset:2114 length:24450 encoding: 4) procheader.c:174:generic_get_one_field: empty line smime.c:223:Checking S/MIME signature smime.c:239:no boundary file-utils.c:58:TIMING safe_fclose : 0s010ms smime.c:290:start scan file: /home/stefan/.claws-mail/tmp/tmpfile.0000000a procheader.c:174:generic_get_one_field: empty line procheader.c:174:generic_get_one_field: empty line procheader.c:174:generic_get_one_field: empty line procheader.c:174:generic_get_one_field: empty line procheader.c:174:generic_get_one_field: empty line message/rfc822 (offset:0 length:15160 encoding: 6) multipart/related (offset:91 length:15069 encoding: 6) multipart/alternative (offset:278 length:6983 encoding: 6) text/plain (offset:408 length:673 encoding: 0) text/html (offset:1221 length:5991 encoding: 3) image/png (offset:7438 length:7675 encoding: 4) file-utils.c:58:TIMING safe_fclose : 0s004ms mimeview.c:543:signed mail sgpgme.c:110:err code 0 messageview.c:1291:found part 6/related The linenumber might be off, because I added some code for testing myself. But it still shows the mime parts with the 4 spaces indentation. The first is the message from the cache and the second is the file from the tmp directory. And the last line references the last file. I ran this with claws build from git. Please let me know if you need more information. TigerP
Created attachment 2010 [details] A signed message which shows the issue I've received this file which contains a signed message, with a subject and without any text in the body. When you use "import mbox file" to load it into claws, you can see the issue. TigerP
The example file provided has a broken MIME structure, indicated by the line: smime.c:239:no boundary It has a bunch of junk, garbled characters before the Content-Type ... boundary declaration. You can see this if you use 'Display as text' on the p7m MIME part. Therefore, the bug is in whatever software was used to create the message.
Created attachment 2011 [details] partial fix (WIP) an improvement, but not yet finished. Comments welcome
Created attachment 2012 [details] A signed message with a body This file contains a signed message with a multi-part message body.
I also frequently see this issue with some senders. Even if it might be a problem with their clients a workaround would be highly appreciated. For me it is in a corporate environment where most people use different versions of Outlook and Mails are frequently signed/encrypted/both. Thunderbird seems to deal with those mails correctly. I will try the partial fix. Paul why do you say it is not finished, what should i watch out for?
Ok I see. The patch just gives me those lost headers where the multipart message seems to to be an attachment in the "main" view. I can look at the parts and read them, but a decent reply with quoting is still not possible.
Actually, with the attached patch, (at least with the example message attached to this bug item), it is possible to get "a decent reply with quoting". You need to open the main body part, and select its text before hitting 'reply'. However, I don't claim that this is ideal.
I recently tried claws-mail 3.19.0git9 and that version no longer has the issue. I was able to reply to the email as any normal (unsigned) email.