X.509 mails will not be decrypted
Closed, ResolvedPublic

Description

Some of my contacts use X.509 / MIME. When I receive mails from them, the little lock icon shows up in the mail list, but otherwise (either inline or in a mail window) there is just empty space and the "Unsicher"-? icon in the ribbon.

JJworx created this task.Nov 26 2018, 10:19 AM

I forgot the debug log:

additional info: I have their certificate(s) and sending encrypted mails to them is successful.

aheinecke triaged this task as High priority.Nov 26 2018, 2:49 PM
aheinecke added a project: gpgol.
aheinecke claimed this task.
aheinecke added a subscriber: aheinecke.

You are running in a codepath that means "Outlook told us this was S/MIME, but we have not seen the proper message headers and neither does the data look like it is S/MIME."
Sadly your log does not help much in that case because it marked the mail as bad and aborts.
I've changed that "marking a mail as bad" so that future logs will be more helpful and that it will still try to treat this case as "encrypted" maybe that will already work, although I doubt it. The log will at least be a bit more helpful.

A version with that change is: https://files.gpg4win.org/Beta/gpgol/2.3.3-beta6/

It would be a great if you could ask your contact if they would be willing to help, I think their crypto solution does something strange here.
Here is my S/MIME Certificate chain for "andre.heinecke@intevation.de"

Ok, with the beta gpgol the mail is successfully decrypted. This is the debug.log:

Thanks, from that log I can understand the problem:

mapihelp.cpp:change_message_class_ipm_note_smime: content type is 'application/ms-tnef'

^ This means that the S/MIME message is wrapped in Microsofts proprietary attachment format. We have code already for that case in the OpenPGP case because that happened with PGP/Inline sometimes, too ( T3419 ). But we didn't have it for S/MIME yet. I thought for S/MIME that would not happen because S/MIME is already always an attachment. I'll add something. The current code is not so good as it will try to decrypt anything that Outlook says is S/MIME but which we do not understand. So a signed only message wrapped in this format would probably fail.

I'll leave the fallback to "just try to decrypt" in though because it is better then doing nothing like we did before.

JJworx added a comment.EditedNov 28 2018, 8:57 AM

fine with me

JJworx added a comment.EditedNov 28 2018, 9:26 AM

This is a new bug, I believe, but perhaps it only appears with "broken"
S/MIME-messages of this type, So I'll first post it here:

If the newest mail in the Inbox (Outlook 2013 with Exchange Server) is
such a mail, Outlook will not start. It just has the opening splash
window with animation. Nothing behind that. If I kill a gpg...exe in the
TaskManager, the GPG password window appears. After entering the
password, Outlook can be opened again.

aheinecke changed the task status from Open to Testing.Mon, Mar 25, 9:17 AM

I'm changing this to testing as the original problem is now fixed with a good solution that properly detects the contents of ms-tnef wrapped messages.

This is a new bug, I believe, but perhaps it only appears with "broken"
S/MIME-messages of this type, So I'll first post it here:

If the newest mail in the Inbox (Outlook 2013 with Exchange Server) is
such a mail, Outlook will not start. It just has the opening splash
window with animation. Nothing behind that. If I kill a gpg...exe in the
TaskManager, the GPG password window appears. After entering the
password, Outlook can be opened again.

I think ^ is out of scope a bit. It seems that a GnuPG process was hanging there and in that case decryption hangs and if that happens to occur to be the first mail we hang :-(
We have an issue for rare/random "hangs" and working on fixing them.

3.1.6 is released.

aheinecke closed this task as Resolved.Wed, Mar 27, 1:53 PM
aheinecke closed subtask T4264: Gpg4win 3.1.6 as Resolved.