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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
