Ejecutamos el correo. Envío transaccional y masivo saliente a través de instancias separadas Postfix, envío entrante a través de su propio, buzones en Dovecot, filtrado y puntuación a través de Rspamd. La identidad del remitente se comprueba con el DNS en vivo antes de que se permita que un mensaje reclame el dominio de un cliente.
| Medida | Valor | Fuente | Medido |
|---|---|---|---|
| Componentes de correo en producción | 5 (Postfix outbound, Postfix bulk, Postfix inbound, Dovecot, Rspamd) | kubectl get deployments -n mail | |
| Envío de rutas separadas por clase de reputación | 2 (transactional and bulk, on distinct instances) | kubectl get deployments -n mail | |
| Comprobaciones del dominio del remitente realizadas antes de que se autorice un envío | 2 (domain ownership proven by DNS record, and SPF authorisation verified live) | transactional sender-identity resolution in the email service |
Qué edificio nos enseñó
Cuando un correo electrónico de marketing no llega, la herramienta de campaña lo reporta como enviado. Esto es técnicamente cierto y completamente inútil. El mensaje fue aceptado para entrega y luego descartado, diferido o archivado como spam por un sistema receptor de acuerdo con reglas que la herramienta de campaña no puede ver y su proveedor no explicará.
La ejecución de la infraestructura cambia lo que se puede conocer. Separamos el envío masivo del envío transaccional para que un boletín no pueda dañar la reputación de la que dependen los restablecimientos de contraseña. Comprobamos, en el DNS en vivo en el momento del envío, si realmente se ha demostrado que un dominio pertenece al inquilino que lo reclama y si su registro SPF realmente nos autoriza. Si esa búsqueda falla, no registramos ningún veredicto en lugar de adivinar, porque una conjetura aquí envía correo que falla la autenticación y enseña a los sistemas receptores a desconfiar del dominio.
Una vez perdimos una clase de mensaje entrante porque un webhook publicó datos codificados en formulario y el controlador intentó analizarlo como JSON, devolviendo un alegre 200 mientras descartaba el contenido. Existían tres caídas silenciosas separadas en esa ruta. Nada alertó, porque todo informó éxito. Los sistemas que fallan por tener éxito son los más difíciles de encontrar y la razón por la que instrumentamos las rutas de ingestión obsesivamente en el trabajo del cliente.
Hay un límite de conexiones que también vale la pena mencionar, porque es el tipo de detalle que solo aparece bajo carga real: un servidor de correo permite un número limitado de conexiones simultáneas por usuario y dirección, por proceso, si se excede, las cosas dejan de funcionar de maneras que parecen fallos de autenticación. La planificación de la capacidad para el correo es una ingeniería real, y casi nadie presupuesta para ello.
Construido con
- Postfix
- Dovecot
- Rspamd
- SPF
- DKIM
- DMARC
- IMAP
- Java
- Spring Boot
Cuéntanos lo que estás tratando de hacer
Una breve conversación suele ser suficiente para saber si somos las personas adecuadas, si no lo somos, lo diremos y le indicaremos un lugar mejor.