NexTool Solutions

En GLPI, "configurar el correo" no es solo apuntar a un servidor SMTP: es garantizar que el evento se convierta en mensaje, entre en la cola y realmente salga. En el mantenimiento de entornos de clientes, la mayoría de los casos de "GLPI dejó de enviar correo" no tienen nada mal en el SMTP: lo que se rompió fue el vaciado de la cola o el cron. Esta guía cubre la configuración completa y, sobre todo, los puntos donde la entrega falla de verdad.

El modelo mental: evento, cola y envío

Una notificación pasa por tres etapas, y cada una falla de forma distinta:

1. Evento - algo ocurre (nuevo ticket, seguimiento, resolución) y una Notificación asocia el evento con una Plantilla y los destinatarios.
2. Cola - el mensaje se guarda en la tabla glpi_queuednotifications, no se envía al instante.
3. Envío - la acción automática queuednotification, disparada por el cron, vacía la cola vía SMTP.

Guarda esa separación: la mayoría de los incidentes que atendemos están en la etapa 3 (la cola se llena y nadie la vacía), no en la etapa 1 (SMTP). Configurar un SMTP perfecto sin asegurar el cron es la receta clásica del "lo configuré todo y no llega nada".

Configuración base del SMTP

En Configurar > Notificaciones > Configuración de seguimientos por correo (Setup > Notifications), habilita los seguimientos por correo y completa:

• Modo de envío: SMTP+TLS en la mayoría de los casos - evita el mail() de PHP en producción.
• Servidor y puerto: el host del relay + 587 (STARTTLS) o 465 (SSL).
• Usuario/contraseña u OAuth: según el proveedor.
• Correo del administrador y del remitente: una dirección que el relay esté autorizado a enviar como - ese detalle decide si el correo llega o cae en spam.

La contraseña se guarda cifrada (GLPIKey) en la columna smtp_passwd. Nunca la leas por SQL: viene revuelta y no ayuda al diagnóstico. Para revisar el resto de la configuración directamente en la base de datos:

-- Diagnóstico de la configuración de envío (nunca leas smtp_passwd: viene cifrado)
SELECT name, value
FROM glpi_configs
WHERE context = 'core'
  AND name IN ('smtp_mode','smtp_host','smtp_port','smtp_username',
               'smtp_check_certificate','admin_email','from_email',
               'notifications_mailing','use_notifications');

Si notifications_mailing devuelve 0, las notificaciones por correo están desactivadas globalmente - ninguna configuración de SMTP importa hasta activarlo.

Eligiendo el modo de envío

Esta es la matriz que usamos para decidir el modo por escenario:

Gmail y Microsoft 365 con OAuth 2.0

Gmail y Microsoft 365 bloquearon la autenticación básica (usuario + contraseña). El camino soportado es OAuth 2.0 (GLPI 10.0.7+). En el proveedor registras una aplicación (Google Cloud Console o Azure App Registrations), generas un Client ID y un Client Secret, indicas la redirect URI de GLPI y autorizas. En GLPI, elige el modo SMTP+OAuth, selecciona el proveedor y pega las credenciales.

La trampa que más tiempo consume en Microsoft 365: incluso con el OAuth correcto, M365 deshabilita SMTP AUTH por defecto en el buzón. Sin habilitarlo, la autenticación pasa y el envío falla. Habilítalo en el buzón usado:

# Microsoft 365: habilita SMTP AUTH en el buzón usado por OAuth (deshabilitado por defecto)
Set-CASMailbox -Identity [email protected] -SmtpClientAuthenticationDisabled $false

En Gmail/Workspace el ámbito es https://mail.google.com/ y, en cuentas Workspace, el administrador puede necesitar autorizar la app. Las cuentas con 2FA aún aceptan una contraseña de aplicación como plan B, pero Google está retirando ese camino.

La cola y el cron: donde de verdad se rompe

Aquí está el detalle que solo aparece en la operación. La acción automática queuednotification puede correr en dos modos: GLPI (disparada por acceso a la interfaz) o CLI (por cron externo). En una instancia de bajo tráfico - el cliente que solo usa GLPI en horario laboral - el modo GLPI hace que las notificaciones de la madrugada solo salgan cuando alguien abre el sistema por la mañana. El síntoma llega como "correo atrasado" o "no llega". La decisión que estandarizamos en el mantenimiento: todas las acciones automáticas en modo CLI, con front/cron.php llamado por cron externo cada minuto.

# GLPI - vacía la cola de notificaciones cada minuto (usuario del servidor web)
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

# En Docker: dispara el cron de GLPI como el usuario del servidor web (ajusta nombre/ruta)
* * * * * root docker exec -u www-data glpi php /var/www/glpi/front/cron.php >/dev/null 2>&1

Para ver si la cola se vacía, mira lo que está atascado sin sent_time:

-- Notificaciones atascadas en la cola (cola llena = el cron no la está vaciando)
SELECT id, itemtype, recipient, create_time, send_time, sent_time, sent_try
FROM glpi_queuednotifications
WHERE sent_time IS NULL
ORDER BY send_time ASC
LIMIT 20;

Una pila grande y creciente aquí, con el SMTP intacto, casi siempre es cron detenido o en modo GLPI. También puedes seguirlo en la interfaz en Administración > Cola de notificaciones.

Plantillas y variables

En Configurar > Notificaciones > Plantillas de notificación editas el cuerpo de cada evento. Las variables usan la sintaxis ##...##:

<!-- Plantilla "Nuevo ticket" - cuerpo HTML con variables de GLPI -->
<p>Hola ##ticket.author##,</p>
<p>Tu ticket <strong>##ticket.id##</strong> ha sido registrado:</p>
<ul>
  <li>Título: ##ticket.title##</li>
  <li>Prioridad: ##ticket.priority##</li>
  <li>Síguelo en: ##ticket.url##</li>
</ul>

Una plantilla puede tener versiones por idioma; sin la versión del idioma del destinatario, GLPI usa la predeterminada. El error común aquí es editar solo el cuerpo en portugués y extrañarse de que el técnico con perfil en inglés reciba la plantilla vieja.

Trampas de campo

Los síntomas que más vemos y dónde investigar cada uno:

Un aviso sobre el último caso: por defecto GLPI no notifica al autor de su propia acción. El técnico que actualiza el ticket no recibe el eco de su propia actualización - eso es comportamiento esperado, no un bug. Confundirlo con "notificación rota" ya costó una madrugada de diagnóstico persiguiendo un problema que no existía.

Más allá del correo

El correo es asíncrono y compite por atención con la bandeja de entrada. Para que el técnico vea el ticket en el instante en que cambia, el correo no es el mejor canal. Considera notificación en tiempo real con el módulo Smart Notify (campana en la barra) o envío por WhatsApp y Telegram para los eventos que no pueden esperar al próximo ciclo de correo.

Si el correo de tu GLPI vive intermitente - a veces llega, a veces no - normalmente es la cola y el cron, no el SMTP. NexTool se encarga del mantenimiento de GLPI con monitorización de la cola de notificaciones y el cron bajo control. Habla con nosotros sobre soporte y mantenimiento de GLPI.

Revisado por el equipo de NexTool Solutions.