<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In the past, I've wondered if one should separate the mail receiving<br>
functionality from the mail archival functionality. </blockquote><div><br></div><div>Yes. I had the same thought about a year ago. The justification is simple:</div><div><ol><li>Building a full blown mail UA with all the features needed is a ton of work.</li><li>End to end encrypted email is really hard.</li><li>Much mail of interest to adversaries is old, rather than communication happening right now.</li></ol>Thus an obvious solution presents itself: write a program that downloads old mail via POP or IMAP, erases it from the server, encrypts it and then reuploads the now encrypted archives to some sort of cloud store like Google Drive. The app can also build a (possibly also encrypted) local search index so you can easily find old mails again.</div><div><br></div><div>I even started building it, but in the end decided to work on other projects.</div><div><br></div><div>It'd make a nice little (possibly commercial) product for one or two people. I'd write it in Kotlin, using JavaFX+WebView for rendering the mails, Lucene for implement the local search engine, a Bitcoin style "here are your 12 secret words" private key, and I've had UI flows optimised for Gmail users as that way you can assume they have a GDrive for storing the backups as well.<br></div><div><br></div><div>Finally, I'd make a mobile version that knows how to sync the encrypted backups so you can rummage through your archives on the phone too.</div><div><br></div><div>The crypto isn't the hard part of all this, of course. Making it convenient is.</div></div></div></div>