Correo distribuido/es

<languages/>

Idea para infraestructura segura, resiliente y distribuida para entrega de correo, unida al Correo local. Es similar a Owns en DNS con un poco de MixMinion pero sin requisitos especiales ni software nuevo.

Hackers: Hacker:Fauno, Hacker:Matus

Objetivo

Aprovechar la capacidad infraestructural actual de los servidores de correo (MTA) y sus estándares (MX, prioridades, etc.) para armar una infraestructura distribuida de entrega de correo.

Que las rutas por las que pase el correo sean lo más diversas posible, tanto para que no sea posible interceptar el 100% del correo como para tener servidores alternativos si nuestro servidor personal/principal tiene algún problema.

Infraestructura

Siguiendo las ideas aplicadas en Correo local, multiplicar los gateways/relays disponibles con una prioridad igual, de forma que los servidores externos elijan al azar uno de ellos para hacer la entrega. Esto se logra:

• Configurando distintos MTAs independientes/autónomos para actuar de relays de los mismos dominios

• Configurando estos MTAs como servidores de nuestro dominio, utilizando la infraestructura de DNS estándar, los registros MX.
  Esto se puede lograr tanto creando varios registros MX para el mismo dominio con la misma prioridad (el estándar dice que si varios MTAs tienen la misma prioridad, el MTA externo debe elegir uno al azar) o creando registros con bajo tiempo de vida (TTL) y actualizándolos a partir de un pool de MTAs disponibles (o las dos cosas si tenemos muchos más servidores de los que conviene poner en DNS.)

• Conectando los MTAs gateway con los internos vía LibreVPN, como en Correo local.

Explicación

Al configurar muchos servidores independientes para que actúen de servidores del mismo dominio, pero haciendo la entrega final en uno dentro de LibreVPN (o a otro MTA público), multiplicamos las rutas por las que pasa un correo, volviendo más difícil la intercepción. Se aprovechan las capacidades actuales del software, es decir todos los MTAs libres poseen la capacidad de ser un relay de otro servidor (o sea ser servidores secundarios) y por otro lado se aprovechan los registros MX y sus prioridades para hacer este intercambio de rutas.

Es importante que los servidores sean autónomos para evitar caídas o toma de control en conjunto, perdiendo autonomía y anonimato la red. Proponemos una red de MTAs independientes que se ayudan entre sí para dar lugar a una infraestructura más estable, resiliente y escalable a la vez que distribuida entre pares.

Es decir, se trata de la misma infraestructura que utilizan los grandes proveedores de correo utilizada para nuestros fines.

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.

-- Lo del repositorio es mejor para saber quién subió un dominio y tener cambios locales, la otra opción es más automática y dentro de un clúster de otras cosas (granja de bases de datos, etc.) Fauno (discusión) 16:40 11 dic 2013 (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)