This is really essential for archiving emails by downloading folder or entire inbox. Additional login and multifactor authentication can be also requested by Tuta before actually downloading the content (as extra security). If you, the user, trust username and password combination in addition to MFA to access your email account on Tuta servers, then you also may trust it to download your emails to a local storage of your choice. What you do with the downloaded file and how you store it afterwards is your responsibility as a user.

Interesting! I've been a paying Tuta Nota user for quite sometime, and I just realized that I cannot download all my emails for backup. This calls my use of Tuta Nota to question again. Because this effectively locks in all my communications and contacts in Tuta Nota.

Weird not to have such a vital feature developed or at least more upvoted.

Thank you all for your feedback. Please let us explain in more detail why we don’t plan to add pgp-support at the moment:

Current encryption standards like pgp and S/MIME have several issue that we plan to address with Tutanota. These standards do not support forward secrecy and are not resistant to attacks from quantum computers.

In addition, it is important to us that the subject line in emails is also encrypted. That’s why we have developed a solution that is also based on recognized algorithms (RSA and AES) and that automatically encrypts the subject, the content and the attachments. In the future, we plan to upgrade these algorithms to quantum-resistant ones that also support forward secrecy.

We also see the importance that Tutanota needs to be interoperable with other encryption solutions. We will develop an API so that Tutanota users can communicate with users of other secure services confidentially in the future.

Thank you all for your feedback. Please let us explain in more detail why we don’t plan to add pgp-support at the moment:

Current encryption standards like pgp and S/MIME have several issue that we plan to address with Tutanota. These standards do not support forward secrecy and are not resistant to attacks from quantum computers.

In addition, it is important to us that the subject line in emails is also encrypted. That’s why we have developed a solution that is also based on recognized algorithms (RSA and AES) and that automatically encrypts the subject, the content and the attachments. In the future, we plan to upgrade these algorithms to quantum-resistant ones that also support forward secrecy.

We also see the importance that Tutanota needs to be interoperable with other encryption solutions. We will develop an API so that Tutanota users can communicate with users of other…

Recycling usernames is a bad idea. Especially given the amount of trust that is put these days on each unique address. This should go without explaining, but imagine a long forgotten app which you have authorized to make payments through email requests (for example) or even receiving some sensitive information from an unaware sender to some new owner after you have decomissioned an email address. These are just a couple of simple scenarios, let alone more serious one such as a government identity system linked with a personal email account...etc

Google isn't really an example for any privacy concerns, but their policy to not recycle email addresses for ever after a user deletes them seems to be spot on.

I wish Tuta Nota follows a similar policy in not allowing recycled email addresses. Instead, adding more @domains.xy to the list can return massive scalability. With that, there would be no need whatsoever to recycle email addresses.

Building an encrypted calendar is at the top of our to-do list right now as we desperately need a solution to schedule and share calendar entries securely ourselves. However, first, we have to finish the new client to push it our of beta and update the Tutanota Android and iOS apps so that you can use your encrypted mailbox with very good speeds and many more features on all your devices. Once we are done with that, we will build the encrypted calendar.