I think this can be resolved according to the last comments. We have analyzed it and found that it is not an issue on our side.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 27 2019
As a workaround you could also forward the mail to yourself and remove the attachments in the forwarded mail. This would basically work the same as I've described in the previous message.
The next version will have a "decrypt permanently" option. Afterwards you could remove the attachments. Will this help in your use case? You could for example copy the mail into a local folder and remove the attachments then.
Feb 22 2019
Jan 29 2019
No... In this situation, my atachment is a rar file
Interesting. Thanks for reporting this. This happened in the past because images had a "content-id" (so they were marked to be an embedded image) but were not really embedded. I did not have a very good fix then because it is hard for us to detect (easy for Outlook itself though) so there might be more special cases where this happens.
Jan 28 2019
Jan 25 2019
I know, I helped implementing that. Patrick changed it.
Enigmail used to use gpg-wks-client. @kai implemented it back then and we had a milestone meeting to show that it works with posteo.
Jan 15 2019
Since today, I cannot send any Signed email. Outlook is crashing.
I guess it is due to the new version of GpgOL I installed.
Jan 14 2019
You can save as text or html decrypted. And apart save the attachment. You can save as .msg in encrypted form dragging and dropping the message row to the desktop. In Outlook smime native mode you can save as .msg in encrypted mode (could be the key cache decrypts "on the fly"). This option seems disabled in gpgol.
I can reproduce it. For me the image is properly attached, I can access the file, but the embedded image does not work. This will be because the content_id is mixed up. I don't know why this happens yet.
I've opened T4322 for the image embedding issue.
In T4318#121604, @che wrote:Ok, so saving a decrypted message is not possible at the moment, right?
Thanks to the remediation.
Hi Andre,
I think I understand what is going on here:
@aheinecke the file is gpgolXXX.dat. I never got the winmail.dat (I think).
Thanks for taking care of the action.
@MThib What is the filename of the .dat with the original message, is it gpgolXXX.dat or winmail.dat and can you confirm that even without an attachment any modifications to the forwared mail are ignored and the mail is sent out as if it was send again?
There appears to be something very fishy when forwarding from the sent mails folder. Even without attachments if I forward and modify the content the original message is sent out and not the modified one.
It is a bit related to T4241 indeed. As we have not yet seen a way to determine if the user actually triggered "save as" or if outlook just wants to save the modifications we can't decide when we should pass the save event and when we should block it.
Thank you for your detailed report. I agree that this can have serious consequences as it might send out unintended information. I'll look into it with high priority.
Jan 11 2019
Jan 10 2019
Jan 9 2019
Indeed in view of this data, it seems to be that the problem occurs by Microsoft. It fits also with the fact, that all other signatures are working fine from my experience.
I agree. It seems a MS trouble. It remembers the trouble that you have when send email of new version available for your software. Something modifies the signed content.
@jmrexach Thanks for the reminder, I confused those with other mails I've gotten regarding this issue.
Andre,
Were useful for you the files that I sent yesterday? There were extracted using MFCMAPI MFCMAPI tool once emails were collected but before opened by Outlook. When it's checked one of them fails to verify signature. Other two are ok (diferent origin but the same key).
@JW-D I would very much like to but I still only get an error on that page. Can you give me another, working, subscribe link? Maybe I found a wrong one.
A pristine file I do not have, because every file passes GpgOL before displayed. I suggest, you subscribe to the service and if you de-install GpgOL, you should obtain a pristine file.
Ok. So the tooltip was another issue. Which I've fixed now.
No, I can´t confirm it, I get no reason displayed. The key which I use is shown in my screenshot (I´ll send by e-mail)
The tooltip:
I must make a correction of my earlier statement from today. The three Microsoft messages were not displayed in the same order on the screen on both machines. I must say, that on Outlook 2016 AND Thunderbird PGP verification still fails by "Microsoft Security Update Releases". It is the same situation as last year, nothing has been changed. I sent two files in EML format and some screenshots to A.Heinecke today.
I'll work on this right now. Please wait with contacting MSRC before I have a chance to find out what the problem is.
Yesterday Microsoft issued three PGP signed mails. It is the first communication after MSRC confirmed failure of verification and promised to have internal procedures changed. I received those mails on two different machines, one equipped with Outlook 2016, the other with Thunderbird. Last year all messages failed on Outlook and Thunderbird, if the were issued from "Microsoft Security Update Releases".
Should be looked at before the next release.
Hi,
thanks for the report. We were unaware of the Andorid problem. The Web App issue was already reported similary.
18:25:22/11956/ERROR/mapihelp.cpp:mapi_change_message_class: can't save old message class: hr=0x80070005
18:25:22/11956/mapihelp.cpp:mapi_create_attach_table: message has 2 attachments
18:25:22/11956/mapihelp.cpp:mapi_create_attach_table: attachment info:
18:25:22/11956/ 3435173 mt=0 fname=gpgol_string_7' ct=application/pgp-encrypted' ct_parms=`(null)'
18:25:22/11956/ 3435205 mt=0 fname=gpgol_string_8' ct=application/octet-stream' ct_parms=`(null)'
18:25:22/11956/mapihelp.cpp:mapi_mark_moss_attach: Marking 3435173 as MOSS attachment
18:25:22/11956/ERROR/mapihelp.cpp:mapi_mark_moss_attach: can't set GpgOL Attach Type property: hr=0x80070005
18:25:22/11956/mapihelp.cpp:mapi_mark_moss_attach: Marking 3435205 as MOSS attachment
18:25:22/11956/ERROR/mapihelp.cpp:mapi_mark_moss_attach: can't set GpgOL Attach Type property: hr=0x80070005
Jan 8 2019
Reporter in wald said that he is using GMX with POP3. I don't see how that could change compose actions but maybe Outlook internally uses a different MAPI Provider which could cause different behavior. I have not tested POP 3 in a long time so this will be the next step here.
Jan 7 2019
I did in my first comment here ;-)
Please, provide e-mail address, then I´ll send it asap
Yes, please send the mails. Maybe they will show me the problem already. :-)
Very strange, but I tried it by myself, after your mail. The same for me. However, I can offer you to send two mails to you as EML files, one works, the other not. I using GnuPG also for verification from BSI newsletter, it works fine there. The problem is only with newsletters from "Microsoft security update releases", other Microsoft security notifications can be verified as well.
@JW-D thanks. Please send them to aheinecke@gnupg.org
I had a report of this by mail where the problem was that:
Yes, GpgOL in version 2.3.2 fails to verify the original message, it is labeled as "not-secure". But it happens only to "Microsoft security update releases", not to other Microsoft Security Notifications which I receive on regular base. I contacted Microsoft Security Responce Center (MSRC) and they confirmed the failure of signature verification in this case. They were not aware about it, but checked it by them self after my mail. They had no explanation for that. Labeling the message as "not-secure" would may indicate that it would be altered in transport, but MSRC did not say that. Therefore, I still assume, that we have a bug in GnuPG.
If it contains a gpgolPGP.dat it means that it was already parsed by GpgOL and GpgOL created the MOSS attachment from the clearsigned original message. That it's tnef is part of the export and should not be a problem.
Dec 20 2018
Dec 14 2018
No I do not think so. Because that would already be currently the case. If you had a subverted Root CA of course you can attack. But we are only talking about CRL / OCSP here. A root CA that does not provide a CRL for certificate X is OK. As long as the Root CA that issued X issues a CRL for that. Well the usual CRL / OCSP denial of service is still possible but I don't see any subversion.
Interesting idea but it does not help against attacks because all root CA are considered equal (virtually cross-signed). Thus a single not checked root CA allows to subvert all certificates.
I wonder if the best thing here might be another flag in the trustlist to disable CRL/OCSP checks for a single root certificate chain. I had such a request in the Gpg4win forums. Someone had a single unreacable CRL / OCSP and had to disable globally all checks for all other certs, too.
Dec 12 2018
Dec 11 2018
Fix was released with 2.2.11
Dec 10 2018
Hi, it's OpenPGP and the same Exchange server. Perhaps it has to do with
the "Unterhaltungsmodus" from the error message.
I'm pretty sure I tested this in the past using the Outlook.com web interface. The mails should show with an unknown attachment (the signature). I can't think of any changes recently that would have changed it. I'll check again.
Nov 28 2018
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:
fine with me
I'll leave the fallback to "just try to decrypt" in though because it is better then doing nothing like we did before.
Thanks, from that log I can understand the problem:
Nov 27 2018
Ok, with the beta gpgol the mail is successfully decrypted. This is the debug.log:
Nov 26 2018
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.
Nov 19 2018
3.1.5 is released with this change.
This should work with Gpg4win-3.1.5
Nov 16 2018
Nov 15 2018
Nov 14 2018
Thank you very much for the quick response and try-out in detail!
Bug or user error?
Thanks for reporting your problem. We are highly interested in any crash. But please note that our minimum supported Exchange Version is 2010 because 2007 has reached end of life in april 2017. So I cannot test with that Server.
Nov 13 2018
Default settings in Outlook are as following: (i) S/MIME encryption disabled, (ii) S/MIME signature enabled.
Nov 12 2018
I have a workflow now that does this without the openings. The mail is kept open by Outlook anyway when the properties are changed.
Nov 9 2018
Nov 8 2018
To reproduce it the key is to close Outlook through the file -> close option.
Nov 6 2018
It happens with 3.1.4, too.
Nov 5 2018
A wait, we have T4203 for the continuing problems. So let's close this.
This was likely one form of T4111