A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers
Craig P Hicks
craigphicks at pindertek.com
Thu May 24 05:03:17 CEST 2018
Thanks Phil. Very interesting! I will look into that.
On Wed, May 23, 2018 at 3:05 PM, Phil Pennock <gnupg-users at spodhuis.org>
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnupg-users