Relay Backup
El problema
Cuando hacemos de MX secundario para un servidor de correo si este se cae nos vemos obligados a aceptar todas las direcciones de correo del domini, ya que no podemos validar si estas direcciones existen o no en el servidor que tiene registradas realmente las cuentas de correo.
La solución
Para que esto no sea un problema, lo que vamos a hacer será mantener un cache local de las direcciones de correo de los servidores sobre los que les vamos ha hacer mail backup. A través de una interface de administración se podrán 'lockear' las direcciones de correo de un cliente, para que estas no dependan del cache, sino que siempre esten registradas en el servidor y se haga backup de las mismas. Esto nos va a permitir no tener que almacenar correos que vayan dirigidos a usuarios erroneos del dominio sobre el que estamos haciendo backup.
Como funcionará …
El sistema de cache de recipients funcionará según se esquematiza a continuación:
Como se puede apreciar en el esquema el flujo de este sistema se activaría cuando un MTA o un MUA intentan inyectar un correo en el servidor postfix del Gat, entonces al introducir el comando RCPT y antes de procesar el comando DATA se desencadenarían las siguientes acciones.
Validamos con una query en la bbdd si el correo que aparece en RCPT es un correo real del dominio. La validación comprueba que exista el correo y que no haya expirado el TTL de la entrada en la BBDD. Un TTL a caducado si el TS actual es mayor que el TS de la última vez que se recibió un correo para esta cuenta, el valor que define si se esta fuera de este rango debe estar en la base de datos donde estan los parámetros de cada dominio. También se comprueba si el campo 'locked' esta a 'true', si es así la validación del TTL se pasa por alto ya que el administrador del dominio/sistema han definido esta dirección como existente de forma permanente.
En caso negativo, es decir, que la dirección no este en la BBDD se lanza una pregunta al transport map del backend, por defecto definido en el puerto 25403. A través de esta petición sabremos si el dominio es o no local (gestionado por nosotros), en caso de ser local nos especificará cual es la IP del servidor de backend que lo gestiona. Esta será la IP a la que deberemos preguntar si existe o no el email que nos han definido en el RCPT. En caso de que el servicio de transport nos informe que no es un servidor local devolvermos un '450 Try Again later'.
Para hacer la comprobación nos conectmos al SMTP especificado por el servicio de transport e intentamos mandar un correo usando la dirección de remitente por defecto y la misma dirección RCPT que nos han mandado a nosotros. Si llegamos al punto de instroducción del comando DATA sin errores sabemos que la dirección es legítima, en caso contrario la dirección es falsa. En ambos casos mandamos un RESET y cerramos la conexión.
En caso de que la dirección no existiera la borraremos de la tabla 'dspam_virtual_uid', junto con toda la información sobre 'signatures' y 'tokens'. Después denegaremos la recepción del correo que nos intentaban mandar mandando un '550 Requested action not taken: mailbox unavailable'.
Si la dirección efectivamente existe, entonces haremos una de las siguientes dos cosas o insertar el email en la tabla 'dspam_virtual_uid' o actualizar el campo TS del registro que tiene el email en la tabla recien mencionada. En cualquier caso, se mandará un mensaje de '220 Service ready' para permitir al cliente seguir mandado su correo.
Rendimiento
Se estima un coste de entre 100ms y 3s dependiendo de la casuística que tengamos que resolver en cada uno de los casos. Teniendo en cuenta que este tiempo puede aumentar por retrasos en la carga de los servidores, pero sobretodo por el tiempo de las resoluciones de nombres de los DNS.
