Una cantidad sorprendente de equipos solo sabe comunicarse mediante correo electrónico. Dispositivos de copia de seguridad, monitores de red, sistemas de gestión de edificios, impresoras, controladores industriales e instrumentos antiguos envían alertas por SMTP porque era la integración disponible cuando se diseñaron. Asignar un buzón a cada dispositivo convierte esa limitación en una configuración manejable.
La alternativa habitual consiste en que todas las máquinas envíen a una dirección compartida. Funciona hasta que necesitas saber cuál de los cuarenta dispositivos está notificando un problema.
Por qué falla una única dirección compartida
Apuntar todos los equipos a alertas@ parece la opción más evidente, pero se deteriora de una forma previsible.
Los mensajes llegan con asuntos y nombres de remitente distintos porque cada fabricante utiliza su propio formato. Separarlos después exige crear reglas basadas en el texto que emita cada equipo. Cuando una actualización del firmware cambia las palabras sin previo aviso, esas reglas dejan de funcionar.
El volumen agrava el problema. Un solo dispositivo especialmente ruidoso, como un monitor que cambia de estado constantemente o un equipo que reintenta una tarea fallida, puede generar cientos de mensajes y ocultar todos los demás. Con una dirección compartida no es posible silenciar una fuente sin desactivar la regla que recoge al resto.
También se pierde la atribución. Con un buzón por dispositivo, la propia dirección identifica al remitente antes de leer una sola palabra del mensaje.
Enrutamiento sin conjeturas
La principal ventaja de usar un buzón por dispositivo es que el enrutamiento pasa a depender de la estructura y no de interpretar el contenido.
Identificación sin analizar el texto. Un mensaje que llega a sai-sotano@ procede del SAI del sótano. No hacen falta reglas ni coincidencias del asunto, y un cambio en la plantilla del fabricante no genera ambigüedad.
Tratamiento independiente. Puedes silenciar, limitar o ignorar un dispositivo sin afectar a los demás porque cada uno utiliza su propio destino.
Retirada sencilla. Cuando se deja de utilizar una máquina, basta con eliminar un buzón en vez de modificar un filtro y esperar que ningún otro equipo dependiera de él.
Procesamiento por scripts según el origen. Un script que consulta el buzón de un solo dispositivo sabe qué formato debe esperar. El análisis es mucho más fiable que en un flujo formado por mensajes de distintas procedencias. Es el patrón descrito en la ingesta de correo.
La cuestión del coste
Un buzón por dispositivo solo resulta razonable cuando no se cobra cada cuenta como una licencia, que es precisamente el motivo por el que esta solución se utiliza tan poco.
A 7 dólares por usuario, cuarenta dispositivos costarían 3.360 dólares al año solo para recibir alertas, algo que nadie aprobaría. En planes que limitan el número de cuentas por nivel, los cuarenta buzones no cuestan más que el plan contratado. Pro admite 300 por dominio y Agency, 1.000.
Lo que sí consumen es el almacenamiento compartido. Los mensajes de los equipos se acumulan sin descanso porque las máquinas nunca dejan de enviarlos. En este caso, una cuota por buzón y una política de conservación son imprescindibles. La guía sobre cuotas de almacenamiento por buzón explica por qué.
Normalmente, un alias es suficiente
Para ser claros, en muchos entornos la solución correcta no es crear un buzón por dispositivo, sino un alias por dispositivo.
Si ningún proceso consulta por separado el correo de cada equipo y solo necesitas identificar el origen, los alias proporcionan una dirección reconocible sin añadir otro buzón que administrar ni otro almacén que pueda llenarse. Todo llega al mismo lugar, mientras la dirección de destino sigue identificando al dispositivo.
Elige buzones reales si un sistema procesa por separado los mensajes de cada máquina, si los dispositivos pertenecen a equipos que no deben ver las alertas de los demás o si cada dispositivo necesita un plazo de conservación distinto. Elige alias si una sola persona lee todo y la única exigencia es saber qué equipo ha enviado cada aviso.
Los límites son de 30 alias por buzón en Starter, 50 en Pro y 100 en Agency. Estas cantidades cubren la mayoría de los parques de equipos sin multiplicar el número de buzones.
Cómo configurar los dispositivos
La principal dificultad práctica de esta configuración suele estar en los propios equipos y conviene conocerla antes de adoptar el modelo.
Los fabricantes ofrecen niveles muy distintos de compatibilidad con los protocolos modernos de envío. La antigüedad del parque determina el trabajo necesario. En un entorno con equipos comprados durante los últimos cinco años, casi todo funcionará sin problemas. Un sistema de gestión de edificios de hace veinte años será distinto, y utilizar el relé que describimos a continuación es la solución habitual, no una excepción.
Los dispositivos antiguos suelen admitir únicamente SMTP sin autenticación por el puerto 25, en lugar del envío autenticado definido en RFC 6409, o utilizan métodos de autenticación obsoletos. Algunos ni siquiera son compatibles con TLS. Esas máquinas no pueden conectarse directamente a un servicio de correo moderno. La solución normal es instalar en la red un relé local que acepte sus mensajes sin autenticar y los reenvíe con una autenticación correcta.
Cuando un dispositivo sea compatible con el envío moderno, asígnale sus propias credenciales en vez de compartirlas. Guardar una contraseña común en un equipo conectado a un segmento de red que no controlas por completo supone un riesgo. Las credenciales individuales lo eliminan y permiten cambiar la contraseña de una sola máquina sin interrumpir al resto.
Prueba cada equipo generando una alerta real, no mediante su botón de prueba. Los mensajes de prueba de los fabricantes suelen recorrer una ruta de código distinta a la de las alertas reales y pueden funcionar aunque estas fallen.
Nombres que mantienen comprensible el parque de equipos
La dirección es la única etiqueta disponible, por lo que debe indicar el lugar y el tipo de equipo sin obligar a nadie a consultar una lista.
Un nombre como sai-sotano@ o nas-oficina2@ seguirá siendo claro dentro de dos años. dispositivo7@ no lo será. Si ya existe un inventario de activos, es mejor reutilizar sus identificadores que inventar otro sistema paralelo que acabará desincronizado en menos de un año.
Qué hacer con las alertas recibidas
Un buzón por dispositivo solo sirve si alguien o algo actúa sobre sus mensajes. El peor resultado es acabar con un conjunto de buzones que nadie abre.
Decide para cada equipo si una persona leerá las alertas, un script las procesará o simplemente se archivarán para consultar el historial cuando haya un problema. Las tres opciones son válidas. Lo que no debe hacerse es dejarlo sin decidir, porque el correo no leído crea una falsa sensación de supervisión.
Para cualquier aviso realmente urgente, el correo electrónico no es ni ha sido nunca el canal adecuado. Una máquina que deba despertar a alguien tiene que comunicarse con un sistema de guardias o avisos inmediatos. El buzón debe conservar el registro, no transportar la alarma.
