4 ms·

I feel like using something like TOR would help here: it would create a background noise of other traffic while also providing a way for other users to not have

I feel like using something like TOR would help here: it would create a background noise of other traffic while also providing a way for other users to not have to connect directly to the remote server. So I ask: is there a way to provide an optional TOR endpoint? e.g. can I have an MX record with high priority that points to a .onion address, and then have a backup (with lower priority) that points to the normal global IP?

palunon 10y ago
You can of course provide MX records of different priorities. I think the difficult part is getting outbound MTAs to actually understand that a .onion domain shouldn't be looked up over DNS.
- daurnimator 10y ago
  > I think the difficult part is getting outbound MTAs to actually understand that a .onion domain shouldn't be looked up over DNS. If you're running a local tor-compatible resolver they should be! However according to RFC 7686 https://tools.ietf.org/html/rfc7686 https://tools.ietf.org/html/rfc7686: "Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup"
nbraud 10y ago
I'm not sure MX records would work without either modifying SMTP servers or using Tor in transparent proxy mode. Postfix, for instance, has [transport maps](http://www.postfix.org/transport.5.html http://www.postfix.org/transport.5.html), but those let you pick a transport based on the email domain, not the MX host. Right now, some people use [onionmx](https://github.com/ehloonion/onionmx https://github.com/ehloonion/onionmx), which maintains both a [static mapping](https://github.com/ehloonion/onionmx/blob/master/sources/map.yml https://github.com/ehloonion/onionmx/blob/master/sources/map...) from domains to onion services, and a dynamic one using [SRV records](https://github.com/ehloonion/onionmx/blob/master/SRV.md https://github.com/ehloonion/onionmx/blob/master/SRV.md).
schoen 10y ago
Currently there is no support for this in MTA software. If it were supported, you could imagine having somewhat better privacy properties for e-mail with other people who also used this particular setup. However, if you simply re-decentralize your e-mail using today's e-mail technology, you won't get those benefits in the short term.
- daurnimator 10y ago
  Why would you need software for it in the MTA? Use a local resolver with tor's dns option + automapping

palunon 10y ago

You can of course provide MX records of different priorities. I think the difficult part is getting outbound MTAs to actually understand that a .onion domain shouldn't be looked up over DNS.

daurnimator 10y ago
> I think the difficult part is getting outbound MTAs to actually understand that a .onion domain shouldn't be looked up over DNS. If you're running a local tor-compatible resolver they should be! However according to RFC 7686 https://tools.ietf.org/html/rfc7686 https://tools.ietf.org/html/rfc7686: "Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup"

nbraud 10y ago

I'm not sure MX records would work without either modifying SMTP servers or using Tor in transparent proxy mode. Postfix, for instance, has [transport maps](http://www.postfix.org/transport.5.html http://www.postfix.org/transport.5.html), but those let you pick a transport based on the email domain, not the MX host. Right now, some people use [onionmx](https://github.com/ehloonion/onionmx https://github.com/ehloonion/onionmx), which maintains both a [static mapping](https://github.com/ehloonion/onionmx/blob/master/sources/map.yml https://github.com/ehloonion/onionmx/blob/master/sources/map...) from domains to onion services, and a dynamic one using [SRV records](https://github.com/ehloonion/onionmx/blob/master/SRV.md https://github.com/ehloonion/onionmx/blob/master/SRV.md).

schoen 10y ago

Currently there is no support for this in MTA software. If it were supported, you could imagine having somewhat better privacy properties for e-mail with other people who also used this particular setup. However, if you simply re-decentralize your e-mail using today's e-mail technology, you won't get those benefits in the short term.

daurnimator 10y ago
Why would you need software for it in the MTA? Use a local resolver with tor's dns option + automapping