...

Rspamd en lugar de SpamAssassin: una comparación útil de los filtros de spam modernos

No siempre merece la pena cambiar a Rspamd. SpamAssassin Puede seguir siendo adecuado si las reglas son estables y el esfuerzo de mantenimiento es manejable; Rspamd resulta especialmente interesante para nuevas implementaciones, la integración con Milter y entornos escalables de forma controlada. Lo decisivo no son las puntuaciones heredadas, sino las clasificaciones erróneas, las dependencias y un funcionamiento paralelo seguro. Rspamd evalúa los mensajes mediante símbolos y propone acciones cuya aplicación solo determina la integración con el MTA.

Objetivos de los filtros antispam y errores inevitables

Un filtro de spam evalúa los mensajes del flujo de correo en función de características técnicas y de contenido. Entre ellas se incluyen, según el producto, datos del remitente y de autenticación, encabezados, URL, texto del mensaje, estructura HTML, clasificaciones estadísticas y consultas externas. El objetivo no es determinar la veracidad de un correo electrónico, sino clasificar de forma transparente el riesgo de entrega. Rspamd Para ello, también agrupa numerosos módulos de comprobación y puede reunir los resultados en un documento de apoyo a la toma de decisiones.

Hay varios pasos que deben mantenerse separados: el MTA acepta primero un mensaje SMTP o lo rechaza durante la transmisión. A continuación, el filtro calcula una puntuación, ya sea durante la integración o posteriormente. Una marca añade, por ejemplo, información al encabezado o, mediante reglas posteriores, desplaza el mensaje a una carpeta de correo no deseado. Por el contrario, un rechazo pone fin a la aceptación; por lo tanto, es la medida con mayores consecuencias y no se trata simplemente de una marca más destacada.

A Falso positivo Se produce cuando un mensaje legítimo se clasifica erróneamente como spam. Esto puede afectar, por ejemplo, a una factura auténtica de un proveedor cuyo archivo PDF adjunto, solicitud de pago o dominio de envío poco habitual active varios controles. Si solo se marca como spam, el destinatario aún puede encontrarla; si se rechaza, ni siquiera llega al buzón. En la comunicación empresarial, esta diferencia es decisiva.

Por el contrario, un Falso negativo Un mensaje de spam que burla el filtro. Un ejemplo típico sería una campaña con textos ligeramente modificados, enlaces cambiantes y encabezados que parecen técnicamente correctos. Este tipo de mensajes aumentan el riesgo de phishing, malware o publicidad no deseada, pero no implican automáticamente que esté justificado rechazarlos de forma tajante. Un filtro de spam de correo electrónico busca siempre el equilibrio entre ambos tipos de errores, no una tasa de acierto del 100 %.

Por lo tanto, los umbrales son una decisión de riesgo operativo. Un valor bajo para los rechazos puede reducir el spam que se deja pasar, pero aumenta el riesgo de perder correo legítimo. Un valor más alto traslada una mayor responsabilidad al marcado, la cuarentena y la revisión por parte del usuario. Lo más sensato es aplicar una estrategia por etapas: primero, el marcado y la observación; después, la lista gris o medidas más estrictas, pero solo en aquellos casos en los que los registros, los comentarios y el propio tráfico de correo justifiquen la decisión.

SpamAssassin: reglas, puntuaciones y modelo de funcionamiento

SpamAssassin Es un filtro ampliable, basado en reglas y puntos. Analiza, entre otros, los encabezados, el cuerpo del texto, el HTML y las URL; además, dispone de métodos estadísticos, consultas de red y complementos para funciones como Bayes, SPF, DKIM o DMARC. Cada coincidencia aporta puntos al resultado. La suma de estos puntos da lugar a una puntuación que puede compararse con un umbral configurado.

Las personalizaciones propias se realizan, como es habitual, en .cf-Archivos. Esto permite, por ejemplo, definir reglas de encabezado, cuerpo y URI con puntuaciones propias. Este modelo resulta especialmente transparente cuando un equipo necesita comprender por qué se ha activado una regla concreta. Al mismo tiempo, el esfuerzo de mantenimiento aumenta a medida que crecen el número de excepciones, los paquetes de reglas locales y las diferentes valoraciones: cada regla requiere una justificación técnica, un efecto documentado y un control periódico.

En el funcionamiento continuo del servidor, el servicio suele spamd Recibe órdenes de inspección, mientras que el cliente ligero spamc Le envía mensajes. Esta separación evita el esfuerzo que supone iniciar el programa por completo cada vez que se envía un mensaje y está pensada para comprobaciones periódicas. Además, el servicio puede incorporar configuraciones SQL o LDAP, así como ajustes específicos para cada usuario.

Esto es relevante para los entornos de alojamiento: un dominio puede necesitar listas blancas diferentes, mientras que cada buzón de correo tiene sus propias preferencias o niveles de aprendizaje. Estas estructuras que han ido surgiendo con el tiempo no son un defecto técnico, pero dificultan la migración. Por lo tanto, antes de realizar una migración, debe quedar claro qué reglas son realmente críticas para el negocio, cuáles se han mantenido únicamente por motivos históricos y qué tareas ya realiza el MTA u otro servicio.

No es necesario sustituir una instalación de SpamAssassin bien mantenida solo por su antigüedad. Si las reglas son comprensibles, la integración funciona de forma estable y el esfuerzo administrativo se ajusta al volumen de correo, puede tener más sentido un mantenimiento específico que una migración. Por el contrario, una alta proporción de reglas especiales difíciles de mantener no es un argumento para copiarlas a ciegas: es un motivo para que el Existencias habituales ajustar de forma crítica, independientemente del filtro que se elija posteriormente.

Rspamd: trabajadores, iconos y acciones

Rspamd funciona con un modelo maestro-trabajador. El maestro gestiona los procesos y la configuración, mientras que los trabajadores normales revisan los mensajes. Un «proxy-worker» puede, entre otras cosas, recibir solicitudes de Milter y distribuirlas entre los «scanners». El «controller» proporciona funciones de administración y una interfaz web, pero no debe conectarse sin protección a la red pública. Estas funciones separan más claramente el tráfico de correo, el procesamiento y la administración.

Un aspecto importante para la arquitectura es la entrada y salida sin bloqueo. Las consultas DNS, Redis o HTTP pueden realizarse de forma asíncrona. Si una comprobación está a la espera de una respuesta externa, esto no tiene por qué detener necesariamente otros análisis del mismo trabajador. De ello no se deriva ninguna garantía general de rendimiento: los resultados reales siguen dependiendo del conjunto de reglas, el hardware, las latencias del DNS, Redis, la conexión al MTA y la composición real de los mensajes.

Generar comprobaciones en Rspamd Símbolos con valoraciones e información adicional. El filtro las sintetiza en una puntuación global y puede sugerir una acción, como por ejemplo add header, greylist o reject. Esta acción no es una decisión de entrega obligatoria: solo la configuración y la integración concreta en Postfix, Exim o Sendmail determinan si el MTA la aplica y de qué manera.

Precisamente por eso, los umbrales existentes de SpamAssassin no deben adoptarse tal cual como valores numéricos. Cada puntuación refleja la interacción entre las reglas activadas, su ponderación y las fuentes de datos disponibles. Incluso las comprobaciones con el mismo nombre pueden ponderarse de forma diferente en ambos sistemas, agregarse de manera distinta o ejecutarse en momentos distintos. Una comparación directa de required_score Utilizar un umbral de Rspamd resultaría técnicamente engañoso.

Para la gestión, la separación entre la evaluación y la aplicación supone una ventaja: primero puedes observar las publicaciones de símbolos y las acciones propuestas sin rechazarlas de inmediato. Solo a partir de tus propios mensajes legítimos, de las campañas detectadas y de los comentarios recibidos se puede determinar qué Umbrales de actuación son aceptables. De este modo, lo que era un ajuste predeterminado técnico se convierte en una directriz de entrega verificable, en lugar de un límite de spam supuestamente objetivo.

Comparación para el uso diario del correo electrónico

Las diferencias entre SpamAssassin y Rspamd no residen tanto en una regla de detección concreta como en el modelo de funcionamiento. Ambos evalúan los correos electrónicos basándose en numerosas señales, pero los métodos de configuración, integración y funcionamiento distribuido difieren. La siguiente comparación clasifica estos puntos como base para la planificación; no sustituye a un análisis del propio tráfico de correo electrónico.

Comparación de las características operativas principales de SpamAssassin y Rspamd
CriterioSpamAssassinRspamdImportancia para el funcionamiento
ArquitecturaServicio spamd con el cliente spamcModelo «master-worker» con workers normales y proxyInfluye en la ejecución en paralelo y en la integración en el flujo de correo.
Modelo de configuración.Archivos .cf, complementos y, opcionalmente, configuración de SQL o LDAPConfiguración basada en módulos; las adaptaciones locales complementan los parámetros predeterminadosLas reglas existentes no se pueden transferir sin una revisión previa.
Conexión MTANormalmente se transfiere a spamdMilter para Postfix y Sendmail; Exim a través de spamd_addressLa interfaz adecuada depende del MTA utilizado.
Modelo de regulaciónReglas con puntuaciones numéricas para encabezados, cuerpo y URISímbolos, puntuación total y acciones recomendadasLos umbrales y las puntuaciones no son comparables entre distintos productos.
Funciones de aprendizajeBayes y otros complementos disponiblesBayes, clasificación neuronal y otros módulosLos procesos de aprendizaje requieren una retroalimentación contrastada, en lugar de un autoaprendizaje a ciegas.
Memoria necesariaEn función de las funciones activadas y de la configuraciónRedis está previsto para varios módulos productivos con estadoEs necesario supervisar y proteger la infraestructura adicional.
Interfaz webNo existe una función de controlador equivalente en el modelo básicoControlador con interfaz web y API de administraciónEl acceso administrativo requiere un control de acceso restrictivo.
EscalaFuncionamiento orientado a servicios; la configuración se puede centralizarEl proxy puede distribuir las solicitudes entre los escáneresLa arquitectura distribuida ofrece nuevas posibilidades, pero también genera más dependencias.
Esfuerzo de migraciónLas normas y los datos existentes ya están establecidosAplicación parcial de las reglas, reentrenamiento de los datos de BayesEl funcionamiento en paralelo reduce el riesgo de que se tomen decisiones erróneas sin que se detecte.

Por lo tanto, en el caso de un pequeño servidor independiente, una instalación de SpamAssassin bien mantenida no supone una emergencia técnica. Si las reglas propias son comprensibles, el servicio funciona de forma estable y se corrigen las clasificaciones erróneas, mantenerlo puede suponer un menor esfuerzo de modificación. No obstante, una reconfiguración con Rspamd sigue siendo una opción plausible si su integración con Milter y sus módulos agrupados de forma centralizada se adaptan mejor al entorno previsto.

En entornos de alojamiento con varios escáneres, la Escala más importante que el mero número de reglas instaladas. El proxy-worker de Rspamd puede reenviar las solicitudes de Milter a otros workers; las consultas externas asíncronas no deben bloquear al worker en su totalidad. Sin embargo, esto no supone una garantía general de rendimiento: las latencias del DNS, las reglas, el hardware y la composición de los mensajes determinan el rendimiento real.

Integración con MTA, Redis y módulos basados en el estado

La integración técnica determina en qué punto un filtro antispam de correo electrónico devuelve su evaluación al agente de transferencia de correo. Rspamd puede conectarse a Postfix y Sendmail a través de Milter. Exim utiliza para ello su integración a través de spamd_address. El filtro ofrece un resultado, pero el MTA y la configuración seleccionada siguen siendo los que determinan si un mensaje se marca, se retrasa o se rechaza.

No todas las comprobaciones requieren un estado común. SPF, DKIM y DMARC evalúan la información de autenticación; las listas basadas en DNS y las expresiones regulares comprueban otras características de un mensaje concreto. Aunque estas comprobaciones pueden requerir respuestas DNS externas, no generan automáticamente un historial de aprendizaje. Su fiabilidad depende, entre otras cosas, del correcto funcionamiento del DNS y de una ponderación adecuada en el conjunto de reglas.

Trabajar de otra manera módulos basados en el estado. La clasificación bayesiana almacena las características aprendidas, la lista gris debe reconocer los intentos de entrega anteriores y los límites de frecuencia requieren contadores que abarquen varias conexiones. Rspamd prevé el uso de Redis en la arquitectura documentada para la clasificación bayesiana, la clasificación neuronal, la lista gris y otros estados. De este modo, varias instancias pueden acceder a información compartida.

Por lo tanto, Redis no es ni un detalle prescindible ni un requisito imprescindible para cada una de las comprobaciones de Rspamd. Sin memoria disponible, los módulos estáticos pueden seguir siendo utilizables, mientras que las funciones de aprendizaje y reputación se ven limitadas o dejan de funcionar. Por lo tanto, los operadores deben definir la disponibilidad, la conexión a la red, la protección del acceso, las copias de seguridad y el comportamiento en caso de fallo de Redis antes de la puesta en producción.

Servidores compactos y tecnología de redes como símbolo de la separación entre los servicios de filtrado de correo y los de almacenamiento.
Imagen ilustrativa generada por IA: los servicios de estado adicionales aumentan los requisitos de funcionamiento y supervisión.

En la práctica, resulta conveniente separar las responsabilidades: el MTA acepta las conexiones SMTP y aplica la decisión de filtrado, Rspamd evalúa los mensajes y Redis mantiene los estados necesarios. Esta distribución facilita la localización de errores, pero aumenta el número de servicios que hay que supervisar. No se debe compensar una dependencia lenta o inaccesible con rechazos precipitados.

Transferir las reglas y los datos de aprendizaje de forma controlada

Una migración comienza con un análisis de la situación actual, no con la copia de todos los archivos. Es especialmente importante revisar las reglas propias: pueden reflejar requisitos empresariales, pero también contener excepciones obsoletas. Rspamd ofrece un módulo de SpamAssassin que solo procesa una parte de las reglas. Por lo tanto, la similitud técnica de una regla no garantiza que tenga el mismo efecto.

Asignación de componentes seleccionados de SpamAssassin en una migración a Rspamd
Módulo de SpamAssassinPosible equivalente de RspamdAdquisiciónComprobación necesaria
spamd y spamcWorker, Proxy-Worker y rspamcNo hay una transferencia directaConfigurar de nuevo la interfaz MTA, el tiempo de espera y el comportamiento ante errores.
Reglas propias para «body», «header» y «uri»Módulo de SpamAssassin o reglas nativas de RspamdParcialmente posibleComprobar la sintaxis admitida y los símbolos activados con mensajes de prueba.
AWLFunciones relacionadas con la reputación y el estadoNo es una migración 1:1Reevaluar el objetivo y las repercusiones en los remitentes conocidos.
Base de datos de BayesEntrenamiento de Rspamd-BayesNo se puede importarReentrenar con corpus de mensajes legítimos y spam verificados.

El módulo puede, entre otras cosas, determinar ciertos body-, rawbody-, header-, meta- y uri-Procesar reglas. Por el contrario, los complementos específicos de redes y HTML no están totalmente cubiertos. Cargar conjuntos de reglas externos extensos sin comprobarlos puede complicar la configuración y sobrecargar el procesamiento. Es mejor incorporar solo las reglas propias que se demuestre que son necesarias y dar prioridad a los módulos nativos.

Esto requiere un cuidado especial: Entrenamiento bayesiano. Según la documentación de Rspamd, no es posible importar las bases de datos bayesianas de SpamAssassin. Por ello, Rspamd necesita nuevos corpus verificados, compuestos por mensajes deseados y spam. Las facturas, los boletines informativos o las campañas clasificadas erróneamente sesgan la clasificación en la dirección equivocada y pueden agravar los errores de clasificación posteriores.

AWL tampoco debe tratarse como una transferencia de archivos. Aunque el historial de remitentes anterior y la valoración actual de la reputación persiguen objetivos similares, pueden utilizar diferentes fuentes de datos y ponderaciones. Por lo tanto, documenta primero qué efecto debe tener una excepción o una regla de confianza existente. Solo después se podrá decidir si es más adecuado utilizar una función nativa de Rspamd o una regla propia específica.

Implementar Rspamd de forma segura en un entorno paralelo

Una transición productiva no comienza sustituyendo el filtro actual, sino realizando un análisis de la situación. Documenta la conexión MTA, las reglas de SpamAssassin, las excepciones específicas de cada usuario, las dependencias de DNS, los remitentes aceptados y el tratamiento actual de los mensajes sospechosos. Además, determina qué indicadores serán relevantes más adelante: por ejemplo, los correos comerciales marcados erróneamente, las campañas que se han dejado pasar y el esfuerzo de procesamiento manual.

En primer lugar, instala Rspamd por separado de la ruta de correo principal e intégralo de tal forma que se registre su evaluación, pero sin modificar ninguna entrega. El «modo sombra» documentado permite precisamente esta observación: Rspamd comprueba los mensajes sin aplicar las acciones que propone. De este modo, SpamAssassin sigue siendo el único responsable de la toma de decisiones durante la fase de comparación.

No solo evalúa la puntuación total, sino, sobre todo, los que se han activado Símbolos y la acción derivada de ello. Un valor elevado puede deberse a errores de autenticación, características de la URL, datos de reputación o reglas locales; estas causas requieren correcciones diferentes. Por lo tanto, comprueba para cada mensaje sospechoso el encabezado, el grupo de destinatarios y la acción propuesta por el filtro antes de modificar las puntuaciones o los módulos.

El administrador comprueba en papel los resultados de una comparación de filtros de correo antes de la transición.
Imagen ilustrativa generada por IA: antes de la conmutación, se comprueban de forma comprensible las decisiones más destacadas relativas a los filtros.

Una comparación válida incluye casos límite específicos, tanto deseados como indeseados. Por ejemplo, una factura legítima de un proveedor conocido puede contener un archivo PDF y un enlace de seguimiento externo. Por el contrario, una campaña de spam con gran variedad de variantes cambia constantemente el asunto, los fragmentos de texto y el remitente, pero mantiene las URL típicas o las características estructurales. Ambos tipos de mensajes permiten determinar si determinados símbolos contribuyen de forma comprensible a la detección o si una regla es demasiado general.

Yugo Valores umbral solo cuando se disponga de suficientes ejemplos verificables. La escala de puntuación de Rspamd no es equiparable a ningún valor anterior de SpamAssassin; por lo tanto, una aplicación directa puede provocar acciones inadecuadas. Decide por separado en qué casos solo se deben completar los encabezados, cuándo se debe incluir temporalmente en la lista gris y en qué condiciones se debe rechazar el correo. La integración con el MTA determina si una acción se lleva a cabo realmente y de qué manera.

Tras una fase de observación planificada, la transición se lleva a cabo de forma controlada: Rspamd pasa a ser el filtro activo, mientras que SpamAssassin permanece instalado y configurable, pero ya no interviene en el flujo de correo. Este periodo de transición debe incluir las responsabilidades, un método documentado para volver a la configuración anterior y los criterios para interrumpir el proceso. Además, resulta útil contar con una configuración del cortafuegos claramente delimitada; en el artículo se explican los fundamentos para una migración gradual de las reglas. Netfilter frente a nftables.

Funcionamiento, registro y resolución sistemática de errores

En caso de un rechazo inesperado, el diagnóstico comienza por el mensaje concreto y su cadena de procesamiento, no con una relajación general del umbral del filtro. Comprueba el protocolo del MTA, el resultado de Rspamd, los símbolos activados, la puntuación y la acción propuesta. Solo esta asignación permite determinar si, por ejemplo, una regla local, una comprobación basada en DNS o la aplicación del MTA ha provocado el rechazo.

El spam que se ha colado requiere un análisis inverso. Comprueba si el mensaje llegó siquiera a Rspamd, qué símbolos faltan y si no se ha ejecutado una acción configurada debido a la puntuación. Si faltan los resultados de DNS esperados, comprueba los resolutores, la accesibilidad y los tiempos de respuesta antes de crear nuevas reglas de contenido. No todas las campañas pueden detectarse de forma adecuada con un único valor límite.

Una caída de Redis debe tratarse por separado, ya que puede afectar a las funciones basadas en el estado. Comprueba la conexión del filtro con el almacenamiento, los registros del servicio Redis y, a continuación, qué módulos dependen de este estado. Las comprobaciones estáticas pueden seguir proporcionando resultados, pero el entrenamiento bayesiano, las listas grises u otras evaluaciones dependientes del estado requieren un almacenamiento de datos que funcione correctamente.

Si una regla esperada no se activa, comprueba primero su ubicación real de carga, la sintaxis y el formato del mensaje con el que debe funcionar. Las comprobaciones de encabezados, texto sin formato, HTML y URL analizan datos diferentes. En SpamAssassin, los archivos de reglas se pueden comprobar con una comprobación sintáctica antes de su aplicación; el siguiente comando comprueba la configuración y no altera el envío de correo en producción.

Terminal
spamassassin --lint

Para los fallos recurrentes, mantén en una vista conjunta las marcas de tiempo, el comportamiento de la cola, las consultas DNS y los errores de respuesta. De este modo, se puede distinguir si un retraso en la entrega se debe al MTA, a una consulta externa o al proceso de filtrado. Para obtener información más detallada sobre la telemetría de Linux y la supervisión de sistemas en funcionamiento, consulta el artículo complementario bpftool para el análisis moderno del núcleo Fundamentos técnicos.

No modifiques de forma impulsiva ni las puntuaciones globales ni los conjuntos de reglas extensos tras un solo incidente. En su lugar, guarda el mensaje en cuestión respetando la normativa de protección de datos, compáralo con casos similares y documenta la causa junto con el cambio. Esto Análisis de errores permite realizar correcciones transparentes y reduce el riesgo de que una regla de excepción trate posteriormente de forma errónea grandes cantidades de correos electrónicos legítimos o no deseados.

Tomar una decisión en función del perfil del servidor

Seguir utilizando SpamAssassin de forma específica resulta plausible si el servidor de correo existente se gestiona de forma fiable con sus propias reglas, ajustes por usuario y procedimientos operativos. El sistema es ampliable mediante reglas y puntos, y admite complementos, así como diversas opciones de configuración y almacenamiento. Un cambio motivado únicamente por la antigüedad de una instalación no aporta ningún beneficio técnico si no existe ningún problema operativo concreto.

Rspamd es una opción obvia para una nueva implementación cuando la integración con Milter, los controles de autenticación modernos, el control centralizado y los módulos basados en el estado se planifican conjuntamente desde el principio. Su arquitectura incluye roles de «worker» para el procesamiento, conexiones proxy y administración; al mismo tiempo, es necesario que el DNS y, en su caso, Redis funcionen de forma fiable como dependencias operativas. Se trata de una decisión arquitectónica, no de una garantía general de rendimiento.

Para entornos de alojamiento consolidados con muchos casos especiales, el Funcionamiento en paralelo suele ser la opción más flexible. Permite identificar qué reglas propias de SpamAssassin siguen siendo necesarias, si los símbolos de Rspamd reflejan las causas esperadas y qué grupos de destinatarios son especialmente sensibles a las clasificaciones erróneas. Solo sobre esta base se puede decidir si se lleva a cabo una transición completa o si se mantiene deliberadamente el sistema actual.

Por lo tanto, la elección depende menos del número de buzones en sí que de la capacidad de mantenimiento y las dependencias. Quien pueda asumir de forma permanente la responsabilidad de Redis, el resolutor de DNS, el análisis de registros y las actualizaciones, podrá gestionar de forma coherente Rspamd, incluidas sus funciones de aprendizaje y basadas en el estado. Si no se dispone de estos recursos, un conjunto reducido y bien documentado con reglas claras puede suponer un menor riesgo operativo.

Independientemente del producto, se aplica lo siguiente: no pongas el controlador Rspamd en la red sin protección. La documentación recomienda una conexión local o protección mediante cortafuegos; en caso de acceso remoto, es necesario proteger el acceso y utilizar un hash de contraseña. Además, no apliques reglas ajenas ni puntuaciones históricas sin verificarlas previamente. Las mediciones aisladas o las campañas que llamen la atención no constituyen una base para una política de filtrado global.

Por lo tanto, la decisión correcta es una Evaluación de riesgos: La protección frente a los mensajes no deseados se contrapone a las consecuencias de la pérdida de correos electrónicos legítimos. Define para cada acción quién es el responsable, cómo se supervisa y cómo se puede volver al estado anterior. De este modo, el filtro de spam del correo electrónico seguirá siendo una parte controlable del funcionamiento del correo, en lugar de una instancia automática difícil de comprender.

Fuentes y estado actual de los conocimientos

Estado de la investigación:

Marco de versiones de la investigación: documentación de SpamAssassin para la rama estable 4.0.x; Rspamd según las funciones estables documentadas, con la versión 4.2.2 como publicación de GitHub indicada para el 20 de octubre de 2026. No se tienen en cuenta las ramas de desarrollo ni las confirmaciones no documentadas.

https://docs.rspamd.com/tutorials/migrate_sa/

https://docs.rspamd.com/getting-started/

https://spamassassin.apache.org/full/4.0.x/doc/spamassassin.html

https://spamassassin.apache.org/full/4.0.x/doc/spamd.html

https://docs.rspamd.com/developers/architecture/

https://docs.rspamd.com/getting-started/understanding-rspamd/

https://docs.rspamd.com/

https://spamassassin.apache.org/full/4.0.x/doc/Mail_SpamAssassin_Conf.html

Artículos de actualidad

Puesto vacante con pantalla para el diseño de un panel de control de alojamiento web
Administración

Crear paneles de Grafana para infraestructuras de alojamiento

Así se diseñan los paneles de Grafana para infraestructuras de alojamiento con Prometheus: paneles informativos, consultas PromQL correctas, variables adecuadas y límites de interpretación claros.