New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TLS verification #6
Comments
I guess you are talking about the SRV proposal. So to validate that the onion domain appearing in the DNS record you do first a connection to the 'normal' MX and check if the TLS key matches with the one of the onion address. Isn't it? I see few problems with this approach:
|
Let me try to clarify my idea: The server should authenticate itself like when a connection goes in on the classic way (MX). For this you don't need a connection to the smtp service over the clearnet, and you have additional authentication on the onion service. You just need to check whether the certificate the server presents on its onion service would be accepted by the sender server if it would connect directly (match domains) |
In general we saw MX records as a possible solution, but we were worrying how different MTAs are dealing with such records. Given that we need to anyway setup a dedicated route within MTAs configuration and they won't just transparently route email towards onion services (remember this is a solution where 99% of the traffic still flows over clearnet), we didn't really see anymore an advantage in an already occupied and very specific DNS type. SRV records are in our opinion a more generic and better approach to model such lookups. We are working on a more formal document that describes our reasoning and also how we envision tranports to use SRV records. I will close this ticket and like to ask any further disucssion to happen on the mailinglist: https://lists.immerda.ch/mailman/listinfo/onionmx |
Why don't you verify the smtp server's onion service with the tls certificate they offer on direct connect? This would make trolling etc harder
The text was updated successfully, but these errors were encountered: