EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
The EFAIL is particularly effective because it can surround every whole encrypted block B with chosen encrypted binary to yield ABC which decrypts to    "....  

Yet it also has the limitation that it cannot further divide the encrypted block B. Also, EFAIL depends upon plaintext of B being part of and HTML attribute value. Attribute values have a choice of only three final delimiters: doublequote (") singlequote (') and space ( ). So if every plaintext that is encrypted as a single block is prefaced by those three characters, then EFAIL cannot what comes after those characters. (Call it an obfuscation string). Play round with this sandbox    https://try.jsoup.org/%7E_nyXks5PuAs-zJeek8CVhpuAvtI

to see how that works.I've written in more detail at    A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers
    https://github.com/craigphicks/efail-safe-send-to-insec-recv/wiki
    

The thing about new EFAIL reading-safe versions that somehow force or Strongly! advise to use MDC is that some readers won't update for years. And that becomes the problem of the sender when their messages are exfiltrated. Only if the message format is changed so that old readers can't read new messages ... but there are obvious drawbacks to that.That's why I think this sender-safe solution, even if its a bit ugly, is worth considering.Any implementation would have to be close to the encryption module, to avoid any mistakes aligning the obfuscation string with the encryption boundary start, actively checking that alignment is correct.