Configurar alertas de cuota e informes de envío en Mail Ticket Limits


#1

Configurar alertas de cuota e informes de envío en Mail Ticket Limits

Introducción

Mail Ticket Limits de Core-Admin permite definir límites de envío de correo (diarios y mensuales) por dominio o por cuenta SASL. Sobre estos tickets se puede configurar un sistema de informes y alertas que avisa por correo electrónico cuando una cuenta se acerca a su cuota o cuando se desea recibir periódicamente un resumen de los envíos realizados.

Este artículo explica los seis tipos de regla disponibles y cómo configurarlos paso a paso desde la interfaz web. También cubre el uso del CLI (crad-mail-ticket-limits-mgr.pyc) para listar, ejecutar y eliminar reglas, así como para forzar el envío manual de una notificación a fin de verificar que el correo llega correctamente.

Requisitos previos

  • Core-Admin instalado con el módulo Mail Ticket Limits activo
  • Tener al menos un Ticket Plan y un Ticket ya creados sobre un dominio o cuenta SASL
  • Acceso a un correo electrónico válido donde se entregarán las notificaciones
  • El servidor debe tener salida SMTP por localhost:25 (configuración por defecto)

Tipos de regla disponibles

El sistema soporta seis tipos de regla, agrupados en dos familias:

Alertas de cuota (avisan cuando se alcanza un porcentaje)

Id Nombre Cuándo se dispara
10 Daily quota usage above 95% Cuota diaria alcanza el 95% del límite del plan
70 Daily quota usage reached 100% Cuota diaria alcanza el 100% del límite del plan
20 Weekly quota usage above 95% Suma de los últimos 7 días alcanza el 95% de límite_diario × 7
80 Weekly quota usage reached 100% Suma de los últimos 7 días alcanza el 100% de límite_diario × 7
30 Monthly quota usage above 95% Cuota mensual alcanza el 95% del límite del plan
90 Monthly quota usage reached 100% Cuota mensual alcanza el 100% del límite del plan

Las alertas de cuota se evalúan cada 5 minutos mediante una entrada cron generada automáticamente. Cuando la regla dispara, se envía un correo a los destinatarios configurados y la regla queda marcada como notificada para el periodo actual (día, semana ISO o mes), de modo que no se envía más de una notificación por periodo aunque la condición se siga cumpliendo.

Nota sobre 95% y 100%: las dos reglas son independientes. Si configura ambas (recomendado), recibirá un primer aviso al alcanzar el 95% y un segundo aviso, distinto, cuando la cuenta consuma el 100% de su cuota.

Informes periódicos de envío

Id Nombre Cuándo se envía
40 Daily sent mail report Todos los días a las 06:00 (envíos de las últimas 24h)
50 Weekly sent mail report Cada lunes a las 06:00 (envíos de los últimos 7 días)
60 Monthly sent mail report Día 1 de cada mes a las 06:00 (envíos del mes anterior)

Los informes se generan ejecutando crad-log-search.pyc --sent-mail-report=<sasl_user> -D<días>, se comprimen en un fichero .zip y se envían como adjunto al correo del destinatario. Solo se generan para tickets que tengan una cuenta SASL definida: tickets configurados solo por dominio quedan registrados en el log y se omiten silenciosamente.

Configurar una regla desde la interfaz web

Paso 1: abrir el ticket

  1. Inicia sesión en el panel web de Core-Admin
  2. Navega hasta el módulo Mail Ticket Limits
  3. Selecciona la sección Tickets y haz clic sobre el ticket sobre el que quieres añadir la regla
  4. Dentro de la vista del ticket, abre la pestaña Reports & alerts

[PANTALLAZO: vista del ticket con la pestaña “Reports & alerts” seleccionada y mostrando la lista de reglas existentes (puede estar vacía la primera vez)]

Paso 2: añadir una nueva regla

  1. Pulsa el botón Add report or alert
  2. En el diálogo:
    • Type: selecciona el tipo de regla (combobox con las seis opciones de la tabla anterior)
    • Recipients: lista de direcciones de correo separadas por coma que recibirán la notificación
    • Active: marcado por defecto
  3. Confirma para crear la regla

Tras crear la regla, el sistema actualiza automáticamente el fichero cron /etc/cron.d/crad-mail-ticket-limits-alerts para que las verificaciones queden activadas.

Restricción: solo puede haber una regla por tipo y ticket. Si se intenta añadir una segunda regla del mismo tipo sobre el mismo ticket, el sistema devuelve un error.

Paso 3: editar destinatarios o desactivar una regla

Haz clic sobre la regla en el listado para abrir su vista de edición. Desde ahí puedes:

  • Modificar la lista de destinatarios
  • Marcar la regla como inactiva (sin necesidad de eliminarla)

El campo Type no es editable: si necesitas cambiar el tipo, elimina la regla y crea una nueva.

Paso 4: ejecutar una regla manualmente (verificación de entrega)

Para comprobar que el correo llega correctamente sin esperar a que se cumpla la condición o llegue la hora del cron:

  1. Selecciona la regla en el listado
  2. Pulsa el botón Run now
  3. Confirma el diálogo

Esto fuerza la ejecución de la regla como si la condición se hubiese cumplido. Para alertas de cuota, si el uso real no llega al umbral, se envía la notificación con valores sintéticos al 100% para que pueda verificarse el formato del correo.

Contenido de las notificaciones

Alertas de cuota (95% / 100%)

El correo es bilingüe (español primero, inglés a continuación) y contiene:

  • Asunto: [mail_ticket_limits] Daily/Weekly/Monthly quota above 95% -- <ticket> -- <host> o ... reached 100% ...
  • Cuerpo con: nombre del servidor, ticket, uso actual, límite y porcentaje alcanzado

Informes de envío (diario / semanal / mensual)

  • Asunto: [mail_ticket_limits] Sent mail report (daily|weekly|monthly) -- <sasl_user> -- <host>
  • Cuerpo bilingüe describiendo la cuenta SASL y el periodo cubierto
  • Adjunto: fichero sent-mail-report-<periodo>-<sasl>-<timestamp>.zip con el informe en texto plano generado por crad-log-search

Gestión desde la línea de comandos

Todas las operaciones disponibles en la interfaz web (y algunas adicionales) pueden ejecutarse mediante crad-mail-ticket-limits-mgr.pyc. Es la misma herramienta que llama el cron internamente.

Listar reglas configuradas

crad-mail-ticket-limits-mgr.pyc --list-rules

Muestra una tabla con todas las reglas: id, ticket asociado, tipo, descripción, estado activo/inactivo, destinatarios y último periodo notificado.

Forzar la verificación de cuotas

crad-mail-ticket-limits-mgr.pyc --check-quota-alerts

Recorre todas las reglas activas de tipos 10/20/30/70/80/90, evalúa el porcentaje real de uso y envía notificaciones a las que cumplan la condición y aún no hayan sido notificadas en el periodo actual.

Forzar el envío de informes

crad-mail-ticket-limits-mgr.pyc --send-daily-reports
crad-mail-ticket-limits-mgr.pyc --send-weekly-reports
crad-mail-ticket-limits-mgr.pyc --send-monthly-reports

Ejecutar una regla concreta

crad-mail-ticket-limits-mgr.pyc --run-rule <RULE_ID>

Equivale al botón Run now de la web. Útil para verificar la entrega del correo sin esperar al cron y sin necesidad de que se cumpla la condición.

Eliminar una regla

crad-mail-ticket-limits-mgr.pyc --remove-rule <RULE_ID>

Borra la regla y refresca el cron para que, si era la última de su tipo, deje de programarse esa verificación.

Refrescar el cron manualmente

crad-mail-ticket-limits-mgr.pyc --refresh-cron

Reconstruye /etc/cron.d/crad-mail-ticket-limits-alerts a partir del estado actual de la base de datos. Se llama automáticamente al crear/editar/eliminar reglas, pero puede invocarse manualmente si se sospecha que el cron está desincronizado. Además, el propio cron incluye una entrada de auto-refresco diario a las 05:00.

Trazabilidad y diagnóstico

Cada notificación enviada queda registrada en dos sitios:

  • En ticket_log (visible desde la pestaña Logs del ticket en la web), con detalle del tipo, periodo, uso, límite, porcentaje y destinatarios
  • En el log del agente (report.log), accesible mediante journalctl o el visor de logs de Core-Admin

[PANTALLAZO: pestaña “Logs” de un ticket mostrando entradas con formato “Quota alert notified: type=10 period=2026-04-29 used=950 limit=1000 (95%) recipients=[admin@dominio.com]”]

Si una notificación no llega:

  1. Comprueba que la regla esté activa (is_active = 1)
  2. Comprueba el campo Recipients: debe contener al menos una dirección válida
  3. Mira en ticket_log si la regla disparó (puede haber sido bloqueada por idempotencia: ya notificada en el periodo actual)
  4. Para descartar problemas de evaluación, ejecuta --run-rule <id> y confirma que el correo llega
  5. Si el correo no sale, revisa el agente MTA local (postfix o equivalente) escuchando en localhost:25

Resumen de buenas prácticas

  • Configura la pareja 95% + 100% sobre la misma cuenta para tener un aviso preventivo y otro confirmatorio
  • Para cuentas críticas, añade además el informe diario o semanal para tener visibilidad de la actividad real
  • Mantén la lista de destinatarios corta y dirigida a buzones que se lean (típicamente, el administrador del dominio y el equipo de soporte)
  • Usa Run now tras crear cualquier regla para confirmar que el correo se entrega antes de depender de ella en producción
  • Revisa periódicamente los logs del ticket para detectar cuentas que disparan alertas de forma recurrente: pueden estar mal dimensionadas o estar siendo abusadas