A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers

[Phil Pennock]

On 2018-05-22 at 19:35 -0700, Craig P Hicks wrote:
> "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

There's an existing semi-standard for trying to improve email security
by moving headers inside the body and having MUAs handle that
consistently; the main website has gone, but the spec seems to still be
up at <https://github.com/autocrypt/memoryhole>.

You might consider blending your proposal into that and talking with the
Memory Hole folks (Daniel Kahn Gillmor wrote the spec) about whether or
not the email headers in the header block (text/rfc822-headers section)
might start with a new Efail: header which can be completely ignored for
display purposes.

This buys you complete independence from the type of the payload,
inserting only into the headers; you lose the "first 14 bytes" part, but
you were incompatible with MemoryHole anyway, and I get encrypted mail
from a few MemoryHole users already, so there's a userbase there.  If
it's the first header, then there's nothing sensitive earlier in the
encrypted message.  Advocating for MUAs to default to "efail-proofed
memoryhole format" for encrypted mail _might_ gain traction?

-Phil