GpgOL - Unsigned S/MIME mails are not integrity protected


we have successfully switched from SMIME (Outlook integrated) to PGP (GpgOL). To be able to continue to read and reply to older emails we have decided to also use GpgOL for SMIME. Reading the old SMIME encrypted mails is no problem but if we reply to them we get the message “Unsigned S/MIME mails are not integrity protected” and the draft is empty because of security reasons. We do understand that it was not a good idea to not sign these mails but not being able to reply or forward mails is not really an option. Is there a way to deactivate this security setting?

Thank you and regards



currently there is no such setting. The problem is that with unsigned mails an attacker could modify old S/MIME mails in a way that they would include contents of other encrypted mails so that they would be included in the quote.

Is it really such a problem if for these old mails reply and forward does not include the quote?
We estimated that it would be acceptable for users to use “copy &paste”, which would cause them to be more better inspect the contents.

It would be easy to add a hidden option though to disable the current behavior. As a design principle we try to avoid such options to lower security as it is very hard for a user to understand the full implications of it.


Hi Andre,

I just realized that I placed this thread in the German forums, I am sorry.

Thank you for your quick response. I do understand your point and the security implications but being the person who needs to explain this to non-technical users I already know that this will lead to tons of empty mails as users won’t read the “error/info” message and have already forgotten about the copy&paste procedure a week later. So from a practical point of view it would nice to have a hidden setting to override this but it is of course up to you whether you can justify such a setting in your program or not.



@Bernhard I would be interested in your opinion on this.

Hi Peter, hi Andre,

if we allow contents that is not integrity protected with S/MIME
to get an automatic quote, there is a attack vector as the efail research
as shown.

Contents carried over must be thoroughly inspected, so I fear that we cannot
build in an option like this. What we could do instead would be to change the
message to be more constructive, maybe more like:

“You are replying to an old, unsigned S/MIME email. For security reasons of this version
of S/MIME we cannot allow an automatic quote. To protect your contents please
use manual copy and paste on contents that you have inspected for unrelated sensitive

This way users would a) get a better reason why they should care b) know what do to
so they cannot forget.

Peter would this be an improvement?
Best Regards,

Hi Bernhard,

that would definitely be an improvement and it would be great if you could implement that change in one of your next versions!

Thank you!!


My current draft of the dialog is:

While I’m not happy to mention EFail in there I think it is neccessary, at least that is what I also got from other people as feedback. So that knowledgable people can get a rough Idea what the “Security Issue” is.

As other Software still allows this it is otherwise very confusing why we block it.

Hi Andre,

good to see your suggestion here.

I would leave the keyword “EFAIL” out, because it is missleading in this context
and does not add much to the explanation itself. Instead one more sentence to explain the problem would be better, from my point of view. It is okay to have a longer text in this case,
but it should not refer to “security problem” either.


I didn’t like the EFail either.

This sentence is IMO better, trying to explain whats going on:

In this version of S/MIME someone could have added unrelated encrypted content so we cannot allow an automatic quote.

I would like to keep the “in this version of s/mime” to underline that there might be a better way in the future.

Yes, that sentence it better. Maybe even

"In mails encrypted after the S/MIME standards of 2018 …

given the year here is more specific and thus more understandable a few
years in the future, if an old email appears.

Now we should try to explain the problem better, so that users have a chance to
understand why this maybe a problem, maybe:

“an attacker could use the missing signature to have you
decrypt contents from a different, otherwise completely unrelated mail
and place it in the quote so they can get hold of it”

and then explain what they would need to do:

“so you must check each part of a quote thoroughly, this is why we only allow
this to be done manually, by copy and paste”


I’m not sure I understand what you mean by the Year. In 2019 this will still be the case and was the case in 2017. I prefer the “In this Version of S/MIME” as it is related to the Version of Gpg4win and we will know when we implement authenticated encryption for S/MIME

Also “Old” Mails is sadly not true. There are people and Software out there that send unsigned S/MIME Mails “Now” because signing can be unwanted or a hassle or they don’t know better.

I like the other parts. So here is my new draft:

You are replying to an unsigned S/MIME email.

In this version of S/MIME an attacker could use the missing signature to have you
decrypt contents from a different, otherwise completely unrelated email
and place it in the quote so they can get hold of it.
This is why we only allow quoting to be done manually in this case.

Please copy the relevant contents and insert them manually into the new email.

^ The last sentence was suggested by a customer to have a clear and not too scary action advice. So I put your suggestion with the “this is why” in the explanatory paragraph.
So the structure of the three paragraphs is now:

  1. What this message relates to.
  2. What is going on?
  3. What should I do now.

So if someone does not want to read the long middle part he can just see the last sentence with “What to do now”.


Sie antworten einer unsignierten S/MIME Mail.

In dieser Version von S/MIME kann ein Angreifer das fehlen der Signatur dazu verwenden Inhalte einer vollkommen anderen Mail zu entschlüsseln. Diese würden dann in der Antwort zitiert und möglicherweise dem Angreifer zugänglich.
Aus diesem Grund erlauben wir in diesem Fall nur manuelles zitieren.

Bitte kopieren Sie die relevanten Inhalte und fügen Sie diese manuell in die neue Mail ein.

Strike the manually from the last sentence. It’s redundant.

It’s improving. :slight_smile:

Just to explain my suggestion was to replace “this version”
with something that says the S/MIME that was standard in 2018 or before.
Which would still be the case 2019, as they would still use the S/MIME as commonly implemented 2018.