Guess there are several options here.
1. A user's alias could have a rule that forwards incoming mail to other tutanota users (but maybe not to external users) based on set filters.
2. Tutanota enable an email forwarding function so that a particular tutanota address is automatically forwarded to selected recipients.
Item (2) is particularly useful when implementing a custom domain where TutaNota are already forcing increased paid subscriptions. As the MX is fully controlled by TutaNota's servers we need to have some control over the routing. Other competing services are already starting to implement this function or have it planned later this year, so important TutaNota stay ahead of the pack!
An absolute must have.
One way round this with the current app version is to leave the Name field in Settings blank so the receiver gets the full email address in the From field.
Agree too on having "per alias" settings for the signature.
I agree. If image display is switched off, why not just grey out the image boxes. More neutral and blends in with overall look at feel.
This is an awesome idea we were already thinking about. It will be optional.
Great if this could be a default standard setting as it increases security. At the moment anyone can use any tutanota email aliases to login.
If I'm not mistaken this is also about adding security policies to sent emails - if not I'll open a new feature suggestion thread.
I've used Cirius secure email messaging in the past which allows the sender of a secure message to RESTRICT what the recipient can do with the email. For example: reply freeze (they can't reply) and forward freeze (they can't forward the email on). It also allows for "e-discovery and tracking" to allow the sender to see which of the recipients has opened and forwarded the email.
I think some of these features are relevant here where users are potentially external to Tuta and reply via unsecured channels.
Similarly as Tuta currently offers the recipient of the message to "download" a local copy of the message, maybe this option can be controlled by the sender so that for secure content, the recipient's option to download a local copy is DISABLED.
Whilst I think this thread is for server generated incoming read receipts, a feature that would be useful is the ability for a Tuta sender to see if the confidential email they sent has been opened.
Please stick to email.
Whatsup is now end to end encrypted with signal and their core focus is chat.
There are few workable zero-knowledge storage and file sharing services out there at present, principally as security is a trade off for team share features.
Tutanota clearly has something to offer, but I'd be worried if they get overly distracted delivering a file sharing service when there are others doing this. Tutanota's forte is email. Maybe a well designed "light touch" solution is the way forward - but rely on other providers to offer the team share function (such as Sync.com or SpiderOak)
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.
Thank you very much for your continuous support.
Be great if this calendar feature would support SHARED calendars between other users on a shared premium account. So a team can share key dates as opposed to just an individual calendar.
Think this could do with a sender paraphrase: something that can be used to confirm the sender is legit. Banks use this with apps by default so that a user knows the app isn't compromised.
It won't be long before spammers duplicate the default tutanota notification email and clinking on the link may take someone to a compromised web page.
Tell users to use the most recent email as links in the old ones will have expired anyway.
Agree with others. Subject should be masked. However maybe there could be a "tag" field descriptor to give the receiver some indication of subject theme. There are other way more important features to implement first.
Yes this is important. There is little point having visible CC where those in the chain cannot respond to whole group - but only to the original sender. I appreciate the key purpose of this is to get those in the CC list to sign up as registered users, then they will be able to reply all. It just adds an unnecessary step.