EXPECTED BEHAVIOR Warn the user about the security risk and offer to decrypt nonetheless. The dialogue could show a text similar to Werner's explanation: "Not supporting MDC opens the path to somewhat tricky but possible attacks on the ciphertext using the decryption tool as an oracle. For example Enigmails auto-decrypt features makes this possible. This is why we finally decided to let gpg, and GPGME, tell the caller that the decryption failed if MDC was not used with a modern cipher." [https://dev.gnupg.org/T3714#109029] ACTUAL BEHAVIOR Decryption fails without explanation, the debug log shows: sgpgme.c:504:can't decrypt (Entschlüsselung fehlgeschlagen) (the string in parentheses comes from gpgme, which may or may not take it from gnupg in the backend) WORKAROUND Add an action "gpg -d %u" and apply it to the message. The decrypted message will be shown in a dialogue followed by "gpg: WARNUNG: Botschaft wurde nicht integritätsgeschützt (integrity protected)". IMPLEMENTATION As discussed in IRC "currently it is impossible to say why it failed, the API is simply not there". [It] "sounds like we're missing the gpgme equivalent warning for "gpg: WARNING: message was not integrity protected". This was discussed lately in context of e(html)fail on the gnupg list [https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060379.html]. Quoting Werner [https://dev.gnupg.org/T3714]: DECRYPTION_INFO 0 9 The 0 tells you that there is no MDC. I have not checked whether we make this available in the GPGME API. I will check that anyway in somedays because I am currently adding AEAD support to gpg which will eventually replace MDC. A specification is not everything and implementations sometimes even need to ignore requirements. RFC4880 is over 10 years old and had a long drafting process. New research showed that there are real world threats for non authenticated messages and thus gpg now makes the MDC a hard requirement for all algorithms for which we can assume that MDC has to be used. We hesitate to require the MDC also for old algorithms (3DES, CAST5) because a lot of data has been encrypted using them in the first years of OpenPGP. The option --ignore-mdc-error This option changes a MDC integrity protection failure into a warning. This can be useful if a message is partially corrupt, but it is necessary to get as much data aspossible out of the corrupt message. However, be aware that a MDC protection failure may also mean that the message was tampered with intentionally by an attacker. can be used as a workaround but the real solution is to fix compliant-according-to-specs-only implementations. FWIW, we recently received a draft of a paper for a novel attack which can only be avoided with the MDC. TESTING 1) send yourself an uncrypted mail with attachment 2) save an uncrypted mail (with attachment to test SMIME) to the file email.eml 3) encrypt the file with: gpg -ea -r YOUR_KEY_ID email.eml 4) create a new message and insert (not attach) the encrypted email.eml.asc (note the "gpg: WARNING: encrypting without integrity protection is dangerous") 5) open the encrypted mail with claws