NexTool Solutions

No GLPI, "configurar o correio" não é só apontar para um servidor SMTP - é garantir que o evento se torna mensagem, entra na fila e sai mesmo. Na sustentação de ambientes de clientes, a maioria dos casos de "o GLPI deixou de enviar correio" não tem nada de errado no SMTP: o que quebrou foi o esvaziamento da fila ou o cron. Este guia cobre a configuração completa e, sobretudo, os pontos onde a entrega falha a sério.

O modelo mental: evento, fila e envio

Uma notificação percorre três etapas, e cada uma falha de forma diferente:

1. Evento - algo acontece (novo chamado, seguimento, resolução) e uma Notificação associa o evento a um Modelo e aos destinatários.
2. Fila - a mensagem é gravada na tabela glpi_queuednotifications, não enviada de imediato.
3. Envio - a ação automática queuednotification, despoletada pelo cron, esvazia a fila via SMTP.

Guarde esta separação: a maioria dos incidentes que atendemos está na etapa 3 (a fila enche e ninguém a esvazia), não na etapa 1 (SMTP). Configurar um SMTP perfeito sem assegurar o cron é a receita clássica do "configurei tudo e não chega nada".

Configuração base do SMTP

Em Configurar > Notificações > Configuração de seguimentos por correio (Setup > Notifications), ative os seguimentos por correio e preencha:

• Modo de envio: SMTP+TLS na maioria dos casos - evite o mail() do PHP em produção.
• Servidor e porta: o anfitrião do relay + 587 (STARTTLS) ou 465 (SSL).
• Utilizador/palavra-passe ou OAuth: conforme o fornecedor.
• Correio do administrador e do remetente: um endereço que o relay esteja autorizado a enviar como - esse detalhe decide se o correio chega ou cai em spam.

A palavra-passe é gravada cifrada (GLPIKey) na coluna smtp_passwd. Nunca a leia por SQL: vem baralhada e não ajuda no diagnóstico. Para verificar o resto da configuração diretamente na base de dados:

-- Diagnóstico da configuração de envio (nunca leia smtp_passwd: vem 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');

Se notifications_mailing devolver 0, as notificações por correio estão desligadas globalmente - nenhuma configuração de SMTP importa até ligar isso.

Escolher o modo de envio

Esta é a matriz que usamos para decidir o modo por cenário:

Gmail e Microsoft 365 por OAuth 2.0

O Gmail e o Microsoft 365 bloquearam a autenticação básica (utilizador + palavra-passe). O caminho suportado é o OAuth 2.0 (GLPI 10.0.7+). No fornecedor regista uma aplicação (Google Cloud Console ou Azure App Registrations), gera um Client ID e um Client Secret, indica a redirect URI do GLPI e autoriza. No GLPI, escolha o modo SMTP+OAuth, selecione o fornecedor e cole as credenciais.

A armadilha que mais tempo consome no Microsoft 365: mesmo com o OAuth correto, o M365 desativa o SMTP AUTH por predefinição na caixa de correio. Sem ativar, a autenticação passa e o envio falha. Ative na caixa usada:

# Microsoft 365: ativa o SMTP AUTH na caixa usada pelo OAuth (desativado por predefinição)
Set-CASMailbox -Identity [email protected] -SmtpClientAuthenticationDisabled $false

No Gmail/Workspace, o âmbito é https://mail.google.com/ e, em contas Workspace, o administrador pode ter de autorizar a aplicação. As contas com 2FA ainda aceitam uma palavra-passe de aplicação como plano B, mas a Google está a descontinuar esse caminho.

A fila e o cron: onde realmente quebra

Aqui está o detalhe que só aparece na operação. A ação automática queuednotification pode correr em dois modos: GLPI (despoletada por acesso à interface) ou CLI (por cron externo). Numa instância de baixo tráfego - o cliente que só usa o GLPI em horário laboral - o modo GLPI faz com que as notificações da madrugada só saiam quando alguém abre o sistema de manhã. O sintoma chega como "correio atrasado" ou "não chega". A decisão que padronizámos na sustentação: todas as ações automáticas em modo CLI, com o front/cron.php chamado por cron externo a cada minuto.

# GLPI - esvazia a fila de notificações a cada minuto (utilizador do servidor web)
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

# Em Docker: dispare o cron do GLPI como o utilizador do servidor web (ajuste nome/caminho)
* * * * * root docker exec -u www-data glpi php /var/www/glpi/front/cron.php >/dev/null 2>&1

Para ver se a fila está a esvaziar, olhe para o que está preso sem sent_time:

-- Notificações presas na fila (fila cheia = o cron não a está a esvaziar)
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;

Uma pilha grande e crescente aqui, com o SMTP intacto, é quase sempre cron parado ou em modo GLPI. Também dá para acompanhar pela interface em Administração > Fila de notificações.

Modelos e variáveis

Em Configurar > Notificações > Modelos de notificação edita o corpo de cada evento. As variáveis usam a sintaxe ##...##:

<!-- Modelo "Novo chamado" - corpo HTML com as variáveis do GLPI -->
<p>Olá ##ticket.author##,</p>
<p>O seu chamado <strong>##ticket.id##</strong> foi registado:</p>
<ul>
  <li>Título: ##ticket.title##</li>
  <li>Prioridade: ##ticket.priority##</li>
  <li>Acompanhe em: ##ticket.url##</li>
</ul>

Um modelo pode ter versões por idioma; sem a versão do idioma do destinatário, o GLPI usa a predefinida. O erro comum aqui é editar só o corpo em português e estranhar que o técnico com perfil em inglês recebe o modelo antigo.

Armadilhas de terreno

Os sintomas que mais vemos e onde investigar cada um:

Vale um alerta sobre o último caso: por predefinição o GLPI não notifica o autor da própria ação. O técnico que atualiza o chamado não recebe o eco da própria atualização - isto é comportamento esperado, não um bug. Confundir isto com "notificação partida" já custou uma madrugada de diagnóstico atrás de um problema que não existia.

Para além do correio

O correio é assíncrono e disputa atenção com a caixa de entrada. Para o técnico ver o chamado no instante em que ele muda, o correio não é o melhor canal. Considere notificação em tempo real com o módulo Smart Notify (sino na barra) ou envio por WhatsApp e Telegram para os eventos que não podem esperar pelo próximo ciclo de correio.

Se o correio do GLPI do seu ambiente vive intermitente - ora chega, ora não - normalmente é a fila e o cron, não o SMTP. A NexTool trata da sustentação de GLPI com monitorização da fila de notificações e o cron sob controlo. Fale connosco sobre suporte e sustentação de GLPI.

Revisto pela equipa NexTool Solutions.