|
Dear Robert, Dear All, let me try to give, my again personal, answers to your questions. I don't think you can make HTML and attachments work with inline PGP, so this probably means PGP/MIME or S/MIME.Looking at the Enigmail settings usually recommended by "encryption made easy" kind of tutorials, PGP/MIME seems to be most-used and working "good enough". But "just works" is tricky -- do we just support one and hope your recipient also supports that?Why not? If someone tells me "you know, I'd like to encrypt but Thunderbird is too clumsy and Enigmail seems to complicated" and I can tell them to just give Geary a try, a lot is won already. And once one is supported there's either quietness about it on the mailing list or people start asking for other options which conveniently tells you whether or not the one choice was enough. Do we support both and make you choose each time you send?That doesn't seem to be Geary's philosophy, so I'd say no. Keep track of your last choice and use that one? What about multiple recipients?So if all three (inline PGP, PGP/MIME, S/MIME) where supported at some point, and, say PGP/MIME was the sensible default and now someone complains to you that they're rather get your mails as inline PGP or S/MIME, a good way to handle that would be a list of recipient preferences, just like whether a person prefers text messages to HTML messages or vice versa. Does "just works" include you being able to read this email in your "Sent" folder?Yes, definitely! How do we do that with servers that automatically populate your sent mail for you?I'm not sure if I understand what you mean? Are we talking about something other than IMAP? I.e. whatever client application is used, sent mails go to the sent folder. So if there's a mail in the sent folder and you can detect that it's encrypted and you have all you need to decrypt it, then decrypt it. It seems I'm missing something here... I notice that you didn't include "receiving encrypted email" as a requirement. Is that not important, or is it assumed under "just works"?I thought it to be assumed. It of course brings us back to the inline PGP vs. PGP/MIME vs. S/MIME question, since ultimately what you want to be able to do is you want to be able to read your email, period, and it should be as transparent as possible what method it was encrypted with. Personally I would still be very happy if only one of them worked at all. I'm not expecting you, or anyone, to answer all of these questions. This is more to illustrate the complexity we face and show why we're not jumping on this straight away. We need to spec out quite a bit before we can start attacking it.Well, I hope my thoughts can contribute a little bit. If there starts to be a discussion, that's all I could have hoped for :-) One thing that might help us is to learn how other clients deal with these sorts of problems. If you're familiar with some, please comment here or on the bug. If it turns out everyone supports PGP/MIME, for example, we should probably do that as well.FWIW, all non-technical people I know who like to encrypt, they use Thunderbird+Enigmail on their computers for lack of a better option. On Android phones the landscape is more diverse with some clients supporting PGP/MIME and some not (yet). On iOS devices, a thing called iPGMail seems to be the way to go and it does have PGP/MIME support. As for more technical *NIX people, MUTT is still incredibly popular and given its age and maturity, it does all three variants. <off-topic> This is getting a rather of topic, but nowadays email is usually encrypted end-to-end at the transport layer. (And if your mail provider isn't doing this, get yourself a new provider!) The people who can just take a look at your email are your email provider and your recipient's email provider. If you don't trust them, why are you trusting them to deliver the email you sent?The only provider I'd personally trust (if I wasn't hosting myself) not to hand information to third parties would be the German Posteo. That said, in my opinion you're answering your own question since noone has any say in what mail provider their recipients choose (or don't choose!) to choose. Understandable. Eventually we'll figure out how to make bug trackers work without requiring accounts, I hope.Well, there is a GitHub project. Unfortunately it has the "issues" feature disabled... </off-topic> All the best, Jonathan |
Attachment:
0x53847E3F.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature