3 ms·
This does make sense and is backwards compatible, though what about HTML messages? Will you add the simple to/from clutter to the top of the html content, too?
by diafygi 12y ago
This does make sense and is backwards compatible, though what about HTML messages? Will you add the simple to/from clutter to the top of the html content, too?
Instead of trying to extend the standard, why not just nest an unencrypted email in an encrypted email? I'm thinking along the lines of:
1. Someone writes their message into the client and attaches some files.
2. The client generates an unencrypted, standard multi-part email message as message.eml.
3. The client then pgp encrypts message.eml to message.eml.pgp.
4. The client then generates a new email with message.eml.gpg as an attachment and sends it.
5. The recipient receives the message and sees one attachment message.eml.gpg.
Most native clients can open arbitrary .eml files as email messages. This makes it much more convenient to interact (reply/forward/etc.) with this technique, and it is also HTML message compatible. Also, if you have a PGP plugin for your native client, it would decrypt the attachment, and you could just double click it to open that message to read/reply/forward/etc.
As far as web clients, most can't decrypt pgp messages so you'd have to download the message.eml.pgp. And I guess you'd also have to have something that can read .eml files. However, it should be fairly easy for pgp-enabled web clients like Mailpile to open these messages since they have to already have a message format parser.
Anyway, thanks for the article!
- HerraBRE 12y agoThanks for reading, and thanks for the feedback! HTML mail is certainly a problem - editing HTML in that way is not nearly as easily done (nor reversed) as plain text. This is a loose end in the current proposal. Like many techies, I'm somewhat guilty of wishing HTML mail would just go away... However, in all fairness, HTML mail is not often used with PGP today and is somewhat of a "luxury" item, not a critical part of how people communicate. I did consider embedding a full message/rfc822 part instead, and that is also what Werner (the GnuPG author) prefers as well. If PGP/MIME had been implemented that way in the first place, and clients had evolved with that in mind, I'd probably just be happily using that. Unfortunately, the way message/rfc2822 attachments are handled by current mail clients, is not nearly streamlined enough that I'd be happy making people jump through those hoops for every single message. I'm trying to find a sweet spot of working well enough with existing PGP-aware clients, better with PGP-unaware clients, and addressing the limitations of PGP/MIME at the same time. It's a bit of a balancing act and so far the easy/elegant solutions don't seem to pass muster when used in the real world. But I'd love to be proven wrong about that.