Ole, thanks for the idea, but I think you over looked some details in your plan.
Relative links aside, what you are suggesting will actually serve to deanonymize you, and is worse than accessing the service over tor. With tor, your connection would be like so:
you → tor guard node → tor middle node → tor exit node → tutanota server
But you are suggesting the following flow:
you → tor client guard → tor client middle → tor client exit → tor onion exit → tor onion middle → tor onion guard → your server → tutanota server
The only advantages you would see are if you and your server come from different locations, you do not trust the ISP/nation-state you are connecting to, but are fine giving up anonymity between your server and tutanota, because your server will connect directly to tutanota.
As a general rule hidden services are most practical when run on the same host (or internal network for load-balanced servers) as the server that hosts the content.
to clear up some misconceptions,
0) tutanota accounts are pseudonymous; while they ask for a name, they do no kind of formal verification and would only have access to the ip logs and cleartext mail, as they cannot access the content of your encrypted of messages.
1) tor encrypts traffic within its network but not as it leaves [technically it is exit node to tor client, but this is a minor distinction and I can discuss it further offline], as such an exit node operator can sniff as much as your telco provider or the nsa can. I much prefer having the exit node threat model as it reminds you that there could be a real person watching your traffic. any service that uses tls protects from malicious exit node operators
2) tor hidden services encrypt from end to end, this is the reason that most do not use tls, [again this is really hidden server to tor client]. the network diagram is somewhat different, because the traffic never leaves the tor network, and this allows for a server to become anonymous, but also prevents the server from generating any ip logs as all connections to the hidden service show up with ip 127.0.0.1 finally hidden services do not need to rely on dns or dane: the address is a hash of the server's crypto public key, thus its name is already tied in with its crypto
3) what you are describing with a "specific exit node" is an exit enclave, they sort of work in concept, but have large flaws because of how tor works
4) to implement this tutanota would need to run the tor software, but need not operate a tor relay; internal, exit or guard. the tor hidden service code is completely separate from the relay code
tl;dr go to uvcdn.com first, submit the captcha solution; then load tutanota.uservoice.com, submit second captcha solution. Happy browsing over tor.Colin Arnott supported this idea ·
This request is for a hidden service in addition to a standard TLS connection, so it will not force any users to have or use tor. If a user wants to use the standard TLS connection they will still be able to.
There are plenty of other services that have tor hidden services, and running one does in no way correlate one to questionable activities. Consider the following:
This is not a request for access to app.tutanota.de over the tor network, instead it is a request for tutanota.de to run a tor hidden service like https://facebookcorewwwi.onion/ or http://3g2upl4pq6kufc4m.onion , for more information see https://www.torproject.org/docs/tor-hidden-service.html.enColin Arnott shared this idea ·
There are plans for a full feature html editor that may superseded the need for markdown. At the same point this will likely support an HTML option, plaintext, and markdown would be a nice third option.
As most SMTP servers do not support files of this size, realize that this would only work seamlessly for encrypted mail and for cleartext mail require some linking to a file-server for consistent behaviour.
I understand your concerns however as a user of tor, CAPTCHAs are the bane of my existence and I would rather such measures not be implemented on tutanota.
This appears to be a duplicate: https://tutanota.uservoice.com/forums/237921-general/suggestions/6925513-we-need-a-system-for-recovery-reset-password
This is already a feature, if you delete your account and it cannot be recovered or reused by anyone.
are you proposing a hidden service or that tutanota add a SMTorP server?
while you are correct that hidden services are popular for hiding the location of a server, they also provide the following features:
Hidden services provide a variety of useful security properties. First — and the one that most people think of — because the design uses Tor circuits, it's hard to discover where the service is located in the world. But second, because the address of the service is the hash of its key, they are self-authenticating: if you type in a given .onion address, your Tor client guarantees that it really is talking to the service that knows the private key that corresponds to the address. A third nice feature is that the rendezvous process provides end-to-end encryption, even when the application-level traffic is unencrypted.
Thanks for the support, but this is a duplicate of a request currently under review: https://tutanota.uservoice.com/forums/237921-general/suggestions/6916068-tor-hidden-service
I have implemented this in [ https://github.com/tutao/tutanota/pull/23 ], the only downside is that the names are now so long that you only really can fit one per line. Feel free to give feedback and I can try to improve.
You are aware that you can select a particular email address when you type a contact's name, and after it is entered and just shows their name you can still hover or click on the name to get the full email address. While it could be nice to show this, I feel like it clutters the interface and for most cases it is not necessary.
my registrar has a different format than what tutanota describes. I tried a few things and this works, free free to correct me if I got something wrong; hope this helps:
HOST NAME MAILSERVER HOST NAME
HOST NAME IP ADDRESS/ URL RECORD TYPE
@ v=spf1 include:spf.tutanota.de -all TXT Record
tutao: feel free to add this to your tutorial
This feature is currently implemented but can be unreliable when network connection is lost.
This feature would require root access and I believe is outside of the scope of the current development goals.
In order to deliver your data to you in the DAV protocol, the tutao server needs to have access to the plaintext. This is something tutao does not want to support; a similar request is for IMAP support, you can see their response here: https://tutanota.uservoice.com/knowledgebase/articles/470761-can-i-retrieve-my-tutanota-emails-via-imap-to-anot
In order to deliver your mail to you in the IMAP protocol, the tutao server needs to have access to the plaintext; SMTP is simply the reverse, in order to accept data the server must read in plaintext.
This is something tutao does not want to support, there are many other webmail providers that offer this feature if required. https://tutanota.uservoice.com/knowledgebase/articles/470761-can-i-retrieve-my-tutanota-emails-via-imap-to-anot
Finally this is not a good idea for you, as this key sharing or decryption is likely a one way process, and if you ever enabled IMAP you would never get full protection of your data back.
58 votesAdminTutanota Support (Admin, Tutanota) responded
this sounds like a duplicate of https://tutanota.uservoice.com/forums/237921-general/suggestions/6724234-build-in-search
This sounds like a duplicate of https://tutanota.uservoice.com/forums/237921-general/suggestions/6724234-build-in-search