Creación de reglas de filtrado de contenido a nivel de servidor (Sieve)

Creación de reglas de filtrado de contenido a nivel de servidor (Sieve)

Las reglas Sieve permiten filtrar y gestionar el correo en el servidor antes de que llegue al cliente. En esta guía técnica veremos sintaxis, ejemplos prácticos, integración con el LDA, pruebas, rendimiento y buenas prácticas de seguridad para desplegar filtros Sieve robustos en infraestructuras de correo empresarial.

Qué es Sieve y por qué usarlo en el servidor

Sieve es un lenguaje de scripts diseñado específicamente para filtrar mensajes de correo en el servidor. A diferencia de las reglas del cliente (Thunderbird, Outlook), Sieve actúa en el punto donde se entrega el correo (Local Delivery Agent — LDA), lo que permite:

  • Aplicar políticas corporativas de forma centralizada.
  • Reducir tráfico innecesario hacia dispositivos móviles o clientes web.
  • Evitar que amenazas o spam lleguen a los buzones de usuario.

Para una referencia técnica general sobre Sieve y su diseño, consulta la entrada en Wikipedia.

Sintaxis básica: tests y acciones

Un script Sieve combina pruebas (tests) y acciones. Los tests evalúan cabeceras, cuerpo o propiedades del mensaje; las acciones pueden ser fileinto, redirect, discard, reject, vacation, keep, entre otras.

Ejemplo mínimo

require "fileinto";

if header :contains "Subject" "Oferta" {
  fileinto "INBOX.Ofertas";
}

Este script mueve mensajes con «Oferta» en el asunto a la carpeta INBOX.Ofertas. La línea require declara extensiones que usamos (aquí fileinto).

Operadores comunes

  • header :contains — búsqueda de substring en cabeceras.
  • header :matches — coincidencias tipo shell/glob.
  • header :regex — expresiones regulares (si el servidor soporta la extensión).
  • body — pruebas sobre el cuerpo del mensaje (requiere soporte).
  • size — evaluar tamaño del mensaje.

Ejemplos prácticos de reglas Sieve

Presento ejemplos habituales y su justificación operativa.

Redirigir notificaciones automáticas

require "fileinto";
if address :domain :is "from" "no-reply@servicio.com" {
  fileinto "INBOX.Notificaciones";
  stop;
}

Útil para separar notificaciones del correo humano. El stop evita que otras reglas modifiquen el mensaje.

Responder con autorespuesta (vacation)

require "vacation";
if allof (not header :contains "Auto-Submitted" "auto-generated",
          not address :domain :is "from" "noreply@ejemplo.com") {
  vacation :days 7 :subject "Fuera de la oficina" "Estoy fuera de la oficina hasta el 10/xx."
}

Protege contra bucles comprobando cabeceras y evitando respuestas a auto-enviados.

Bloquear o rechazar spam conocido

require "reject";
if anyof (header :contains "X-Spam-Flag" "YES",
          header :contains "Subject" "Gana dinero") {
  reject "550 Mensaje rechazado: contenido sospechoso";
}

Rechazar en LDA libera recursos y evita almacenamiento de spam. Sin embargo, hace falta cuidado para no falsear falsos positivos.

Integración y despliegue

En la práctica Sieve se ejecuta mediante un LDA como Dovecot LDA o Cyrus. El flujo habitual:

  • MTA (Postfix/Exim) recibe el correo.
  • MTA entrega al LDA que ejecuta las reglas Sieve del usuario.
  • Las acciones de Sieve (fileinto/redirect) determinan la entrega final.

Para administrar scripts Sieve de usuarios se suele usar el protocolo ManageSieve (puede ser integrado en clientes web como Roundcube o administradores de hosting).

Pruebas, validación y depuración

Antes de activar reglas en producción conviene:

  • Validar sintaxis con el validador del LDA (muchos servidores devuelven errores al instalar scripts inválidos).
  • Probar con cuentas de laboratorio y mensajes de distintos orígenes.
  • Registrar acciones: activar logs detallados en LDA/MTA para ver qué regla coincidente procesa cada mensaje.

Si necesitas reproducir una entrega, envía un mensaje con cabeceras completas para testear cabeceras y patrones. Para problemas de coincidencias con regex, trabaja con herramientas locales de expresiones regulares antes de incorporarlas al script.

Rendimiento y límites prácticos

Al diseñar filtros en servidor hay que considerar eficiencia:

  • Evita pruebas costosas en todos los mensajes (p. ej. body regex extensos). Prefiere checks de cabeceras cuando sea suficiente.
  • Usa stop y estructura de reglas por prioridad para reducir número de tests por mensaje.
  • Limita scripts muy largos y mantén convenciones por usuario o por dominio.

En entornos con gran volumen, la carga de CPU y I/O puede aumentar si se procesan cuerpos pesados o archivos adjuntos. Monitoriza métricas del servidor y adapta la complejidad de las reglas.

Seguridad y buenas prácticas

El filtrado en servidor impacta la seguridad y la privacidad. Buenas prácticas:

  • Valida y limita quién puede usar redirecciones automáticas para evitar fugas de datos.
  • Evita respuestas automáticas a mails externos sin verificación para prevenir bucles y filtrado de información.
  • Audita scripts y mantiene control de cambios; traza qué reglas fueron añadidas y por quién.
  • Protege el servicio ManageSieve con TLS y autenticación robusta.

Para alinearte con controles de seguridad y amenazas comunes, consulta recomendaciones de seguridad relevantes como las de OWASP y guías de infraestructura que aborden la gestión de identidades y la protección de datos.

Errores comunes y soluciones

  • Reglas que no se ejecutan: verificar que el MTA entrega al LDA correcto y que ManageSieve está apuntando al repositorio del usuario.
  • Falsos positivos: añadir excepciones con not y listas blancas por dominio o cabecera.
  • Bucles de autoreply: añadir comprobaciones como not header :contains "Auto-Submitted" y limitar respuestas por días.

Checklist de despliegue

  • Definir políticas globales y locales: qué reglas aplica el administrador y cuáles puede crear el usuario.
  • Probar scripts en entorno de staging con logs activados.
  • Controlar extensiones Sieve disponibles (fileinto, vacation, regex, imapflags, etc.).
  • Documentar y versionar scripts para facilitar auditorías y restauración.

Recursos y referencias

Para profundizar en la implementación y prácticas de seguridad en servidores de correo revisa documentación técnica y estándares. Documentos y guías útiles incluyen la página de Sieve en Wikipedia y materiales sobre seguridad de aplicaciones en OWASP. Para aspectos de protección en la capa de red y políticas de correo, las guías de proveedores de infraestructura y DNS pueden complementar la configuración, como las recomendaciones generales de Cloudflare Docs.

Conclusión

Las reglas Sieve son una herramienta potente para controlar la entrega de correo desde el servidor. Bien diseñadas, reducen carga en clientes, evitan spam y permiten aplicar políticas corporativas con consistencia. Prioriza pruebas, rendimiento y seguridad: valida sintaxis, limita el uso de pruebas costosas sobre el cuerpo, audita scripts y protege el acceso a ManageSieve. Con una estrategia ordenada y scripts claros, Sieve mejora significativamente la calidad y seguridad del servicio de correo en infraestructuras profesionales.

Tags: