I suggest you ...

self-elimination of encrypted email / set expiration date

That sensitive email is deleted once the link is open, so that you can not share that link with unwanted people

398 votes
Vote
Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Mauricio Vicencio Aravena shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

23 comments

Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
Submitting...
  • ASAP commented  ·   ·  Flag as inappropriate

    I would like autoexpire feature for sent emails. I use protonmail which is good. But I like also Tutanota and would like that feature too.

  • Marcua commented  ·   ·  Flag as inappropriate

    Is this two separate things? One is an experation date say an hour, day a week after that email was sent to delete/expire and the other make the link not work after it's opened once.

    Seems like a merge of topics

  • James commented  ·   ·  Flag as inappropriate

    I just switched over from protonmail. I have to say most things are better here at tutanota.

    The one thing missing is the autodelete feature.

    Really miss it

  • honig commented  ·   ·  Flag as inappropriate

    The lack of this self-destruct feature is the only thing that prevents me from using Tutanota as the primary email.

  • Chris Cantwell commented  ·   ·  Flag as inappropriate

    In my comparisons between Tutanota and Protonmail, this makes Protonmail the hands down winner. Please implement this feature without undue delay.

  • Jean commented  ·   ·  Flag as inappropriate

    Hi, guys!

    In the next updates they think to include the option of self-elimination of encrypted email / set expiration date??

  • Anonymous commented  ·   ·  Flag as inappropriate

    Agree this feature is essential. Maybe sometimes one wants to allow access forever but the threat model for expiring messages is some people cannot be counted on for security on their end (or most people do not care). This is where see expiring messages as an essential optional feature. Not for security from the receiver. But for security if someone else recovers messages (email with link to the encrypted email) or passwords belonging to the receiver.

  • Anonymous commented  ·   ·  Flag as inappropriate

    I fully support this. I was going to pay for Tutanota but because of this feature lacking I've to go to Protonmail.

  • MA commented  ·   ·  Flag as inappropriate

    I'm considering changing my email client and I've narrowed my choices to protonmail an tutanota. An expiration date setting, along with other tiny improvements i've already voted for, would be a game changer for me.

  • Tutanota Contributor commented  ·   ·  Flag as inappropriate

    I wanted to open a similar suggestion, but it seems, it already existed. I post the arguments here.

    Important arguments:

    1) Message destruction timer is already a widely practiced key solution in free E2EE messaging to minimize data breach risk. ( Examples: Protonmail, Telegram, Wire )

    2) It would be ideal to be able to destroy it after first access ( Instant ), so noone can access the encryped storage / message later, also if the recipient can not access it, that suggests a previous data breach.

    3) Delete message / conversation deletes from recipient too. Than you could really delete the sent message from a virtual inbox instead of being stored on Gmail servers forever and being handed out for companies and governments.

    The range should look like :
    Set destruction time to:
    xx Minutes, xx Hours and xx Days
    ( default: 0 = After first acccess - records acces time and date )
    ( if you set a longer time, but you made up your mind: "erase now" button )

    This would be a realistic, practical solution for communicating in insecure channels, like sending a CV to a non-tuta company, or sharing a password instruction with a non-tuta friend.
    This way you can be sure, that even if an entity does not respect your privacy, your documents and datas are stored temporally and encrypted on the Tutanota server.

    ( Google stores everything for ever, against the new EU privacy sanctions, and it will even after EU GDPR - than it is threatened/hacked by state agencies and criminals, and stored for ever in criminal datacenters, and they are used to commit crimes in the victims name, or against the victims. The more biometric "security" was applied, the more you have to lose. )

    ( hacking phones and computers is not a tutanota issue, but we should definitely spread awareness
    Recommendation: FLOSS GNU/Linux OS with FLOSS hardware. Until it is not reality, encryption is just an illusion, since billions of people are backdoored, spywares are hardware implanted before purchase. )

  • Anonymous commented  ·   ·  Flag as inappropriate

    The ability to delete e-mail from the receiver inbox

    Like you've sent an e-mail, you made a mistake but you can't just delete it from the receiver inbox. That would be awesome if you could do so. And also having the possibility to set a expiration date on the e-mail you have sent.

  • Shayan commented  ·   ·  Flag as inappropriate

    This feature is absolutely vital for a secure email service like Tutanota. Confidential emails should also have the ability to Self-destruct themselves after a certain amount of time.

  • Mike Light commented  ·   ·  Flag as inappropriate

    The Tutanota email account holder must have full control over the content of the guest account which is created to communicate with the user of regular email. ThreadThat an example of what is needed for Tutanota. With ThreadThat the creator of the thread may delete any portion of the thread at any time, or set a self destruct time limit to it. The rich text editing of the main page is better in ThreadThat. Editable control over the invitation message content which will be sent to the regular email recipient is also better in ThreadThat. Tutanota is easier to use than ThreadThat, but less secure if there is no control over the storage of content.

  • Anonymous commented  ·   ·  Flag as inappropriate

    É uma ótima alternativa ter um recurso para determinar o período que uma mensagem de e-mail vai durar. O modelo disponibilizado pelo ProtonMail é interessante e muito útil. Um grande avanço!

  • annonymous commented  ·   ·  Flag as inappropriate

    Expiration date for email deletion is needed because the external mail box is not in email owner's control at the moment. The recipient does not own the external mail box and is only using it to communicate with Tutanota. Once he/she is done, he would forget about it. The mail would be sitting there for ages. It needs to be deleted once it has served its purpose. A timed expiration with control over the timing is best. At the moment the only solution is to send the recipient a new email with a new password so the previous email on the recipient side is secured. However the email would still be residing somewhere on the hard drive. It is not practical to change passwords all the time. For example you are communicating with a lawyer whose charges are very high, you want to communicate as little as possible, then this sort of technical problem is both time consuming and can become expensive. It would probably be better for Tutanota servers as well to delete unwanted files. currently another email provider (Proton mail) has this feature.

  • pathfinderjcm commented  ·   ·  Flag as inappropriate

    self destruct emails would be nice... sometimes we send an email that we want to keep secret (between the sender and receiver) ... and the receiver later decides to share to someone who we don't want it to be shown to. This would allow it to be deleted before they can think about showing it to anyone.

← Previous 1

Feedback and Knowledge Base