Los servidores de correo en oficina… Menudo calvario

En los tiempos que corren, en que la oferta de servicios en «la nube» es variada, rica, de calidad y barata, cada vez se destacan más, como los irreductibles galos del bravo Astérix, los servicios que se resisten, ahora y siempre, a lo lógico e inexorable.

No se me entienda mal. Casi en cualquier esquina de una oficina hay un pequeño almacenamiento para compartir ficheros grandes que no necesitan estar en la nube; y muchas empresas tienen servidores para hacer pruebas, o porque por mil motivos les conviene tener algunos en su tradicional cuartito de servidores.

Pero hay un servicio que destaca como un grano en la punta de la nariz: Los servidores de correo electrónico «en casa».
Tener un servidor de correo electrónico es, de por sí, una fuente inagotable de problemas, básicamente por dos motivos:

1. Por el extenso problema del spam, sobre el cual se han subido otros aún más graves como malware, intentos de estafa y robo de información, y mil intentos criminales más.
2. Porque, y derivado de lo anterior, se hace imprescindible en cualquier servidor guardar ya no solamente los RFC básicos (con el 5321, heredero del mítico 821, a la cabeza). No, también hay que implantar una serie de prácticas, que son casi de obligado cumplimiento para un funcionamiento medianamente razonable. Con este último término definido como lo más fiable y libre de bichos posible.

Estas prácticas comprenden cosas como:

• SPF (RFC7208)
• DKIM (RFC6376)
• DMARC (RFC7489, que se apoya en los dos anteriores)
• DNS inversa y otra información del DNS (del venerable RFC2505)

El problema con todo esto, es que no hay un producto que lo tenga todo y lo mantenga, él solito, pulsando un botón. Las implementaciones son tan variadas y complejas como la casuística; los registros SPF, por ir al ejemplo más sencillo, dependen de dónde está el servidor de correo, pero también de dónde más puede salir correo. ¿Y de dónde más va a salir correo? De servidores de ERP, de usuarios móviles, de proveedores de envíos masivos… ¡De mil sitios! Y no hemos hecho más que empezar. ¿DNS? Eso depende de otras dos organizaciones totalmente diferentes: la que suministra la conectividad, y la que suministra el alojamiento del dominio. Nada que ver con el software del servidor. Y suma y sigue.

Todo esto hace muy difícil que un servidor, especialmente en una organización mediana o pequeña, pueda ser mantenido con el nivel de exigencia que la complejidad implica.
Por eso, no es de extrañar que haya cada vez más problemas con los servidores de correo que en algunas organizaciones se van transmutando en máquinas de escribir: Cogiendo polvo en algún rincón, todavía útiles, pero cada vez más abandonados… Con la diferencia de que el correo electrónico, cada vez es más importante, y no menos.

Hoy, el servidor de correo puede entregar correos a Google. Sin problema, manifiesta, cansado pero satisfecho, el administrador. Lo que no sabe, es que como su inversa no está bien configurada («llevo tres meses detrás del proveedor»), Google (o Microsoft, nuestra Neodigit, o quien sea) lo acepta, pero lo marca como «spam con certificado de origen». Y esos correos, se van directos a los buzones de spam de los destinatarios. Y, ¿qué pasa cuando esos correos contienen un pedido, un contrato, un comprobante de transferencia…?

La vida ya es lo bastante complicada como para no aprovechar las oportunidades de deshacerse de la complejidad innecesaria. Los servicios de correo en la nube de cualquier buen proveedor son eficaces, baratos y fiables; en Neodigit, un alojamiento para un puñado de usuarios, vale solo un desayunobar al mes. Elija uno bueno, úselo, y dele un digno retiro a ese servidor que lleva ahí diez años requiriendo atención, como un bebé que nunca ha crecido.