Correo distribuido/en

<languages/>

Idea for a secure, resilient and distributed infrastructure for email delivery, along with Correo local/en. It's similar to Owns/en for DNS with a little of MixMinion but without the special requisites or new software.

Hackers: Hacker:Fauno, Hacker:Matus

Goal

To take advantage of the infrastructural capacity of current email servers (MTAs) and their standards (MX, priorities, etc.) to device a distributed infrastructura for email delivery.

That the routes an email takes be as diverse as possible, to make impossible to intercept 100% of the incoming email or to have alternative backups for our personal servers as well.

Infrastructure

Following ideas from Correo local/en, multiply available gateways/relays with equal priority, in such way that external servers pick one at random to make the delivery. This is achieved by:

• Configuring several independent/autonomous MTAs who act as relays of the same domains

• Configuring these MTAs as servers of our domains, using the standar DNS infrastructure, the MX records.
  This can be achieved by creating several MX records for the same domain under the same priority (standards say that given the same priority for different MTAs, the connecting MTA must pick one at random) or by creating low time-to-live (TTL) records and updating them from a pool of available MTAs (or both if we have much more servers than it's convenient for DNS).

• By connecting gateway MTAs via LibreVPN/en, like in Correo local/en.

Explanation

When many independent servers are configured to act under the same domain, but making the final delivery to another inside LibreVPN/en (or another public MTA), we can multiply the routes through which email is sent, making interception more difficult. We take advantage of current email features, since every libre MTA is able to act as a relay to another server (or to act as secondary servers) and DNS' MX records and their priorities to achieve route switching.

It's important that servers are autonomous to avoid failures or complete seizing, losing autonomy and anonimacy in the network. We proppose a network of independent MTAs cooperating to give place to a more stable, resilient and scalable infrastructure while being distributed among peers.

That is, it's the same infrastructure the big email providers uses but turned around to suit our ends.

TODO

• Distribuir la lista de dominios dinámicamente, estuvimos charlando de usar bases de datos distribuidas (ver Integrar wordpress con correo) o bien con un repositorio git actualizado regularmente.

-- The repository approach is best to know who put up a given domain and to maintain local changes, the other option is more automated and only possible in a cluster of other things (database farm, etc.) FuzzyBot (discusión) 02:37 24 mayo 2014 (ART)

Problemas a resolver

• Cuando se cae el enlace por LibreVPN, el relay acumula correos pero no puede hacer el delivery.
  • Para dejar de recibir correos en este servidor, sacarlo del pool de relays (o dejar que se venza el registro, lo que sea más fácil de implementar, ver pool de IPs en Owns)
  • Cuando vuelve la conexión, ejecutar un flush de la cola de correos para recibirlos de inmediato (ver eventos en LibreVPN, hay uno que se llama postqueue)

Ideas

Para hacer pruebas

• Anunciar dinámicamente relays en un registro DNS-SD con un pool de IPs. Ejemplo:

 drill _relays._smtp._tcp.librevpn.com.ar

 500 IN A x.x.x.x
 500 IN A y.y.y.y

Los registros tienen que ser de poca duración para que la rotación sea alta. La idea es que solo se configura un relay fijo y los servidores van cambiando segun cambien los registros del pool y el round robin de dns. Los DNS se administrarían con Owns.

NOTA: no es así como se usa DNS-SD igual :P

este link prueba que la idea funciona!

• Usar headers_check de postfix para anonimizar los saltos

• Probar hacer saltos al salir, no sólo al entrar (con transport y la misma idea de relay por dns-sd)