Ligámos o [email protected] ao nosso GLPI 11 esta semana: o e-mail passa a ticket e a resposta do cliente passa a acompanhamento no mesmo ticket. Mas, na configuração predefinida, quando alguém sem conta no GLPI escreve, o e-mail vai para a pasta de recusados e ninguém recebe nada. Este guia mostra a configuração que usamos, o que muda entre o Gmail e o Microsoft 365 e as regras que decidem se um e-mail passa a ticket ou desaparece.
Como funciona o coletor
O GLPI lê uma caixa de correio por IMAP em intervalos fixos. Para cada mensagem:
- Um e-mail novo passa a ticket, com o assunto como título e o corpo como descrição. Os anexos vêm junto, até ao limite configurado.
- Uma resposta a um ticket passa a acompanhamento. O GLPI reconhece a resposta pelos cabeçalhos da mensagem, não só pelo assunto.
- Quem estava em cópia pode entrar como observador.
- Depois de processada, a mensagem é movida para uma pasta de aceites ou de recusados, e a caixa de entrada fica limpa.
A recolha é uma ação automática (mailgate) que, por predefinição, corre a cada 10 minutos e lê até 10 e-mails de cada vez. Ou seja, um ticket por e-mail pode demorar até 10 minutos a aparecer.
A configuração que usamos
Em Configurar > Destinatários:
| Campo | O que usamos |
|---|---|
| Servidor | imap.gmail.com, porta 993, IMAP com SSL e validação de certificado |
| Login | A conta que recebe o chamados@ (um alias que entrega nessa caixa) |
| Pasta de arquivo de e-mails aceitos | GLPI-Importados |
| Pasta de arquivo de e-mails recusados | GLPI-Recusados |
| Tamanho máximo de cada arquivo importado | 10 MB |
| Adicionar usuários do campo "CC" como observador | Sim |
| Coletar apenas e-mails não lidos | Não (as pastas já separam o que foi processado) |
E uma regra de coletor que define a entidade do ticket. Sem regra, o e-mail não tem para onde ir.
Gmail ou Microsoft 365: a autenticação muda tudo
O GLPI 11 liga-se por IMAP com utilizador e palavra-passe. O que muda é o que cada fornecedor aceita:
- Gmail / Google Workspace: funciona com palavra-passe de aplicação (a conta precisa da verificação em dois passos), que é o que usamos. Para quem prefere OAuth, existe o plugin oficial OAuthIMAP.
- Microsoft 365 / Exchange Online: a Microsoft desativou a autenticação básica no IMAP; utilizador e palavra-passe já não funcionam. O caminho é o plugin OAuthIMAP (versão 1.5 para o GLPI 11), com uma aplicação registada no Microsoft Entra ID.
O OAuth não vem pronto no GLPI 11. No nosso próprio GLPI havia um coletor antigo com OAuth da Google que dependia do plugin. O plugin saiu, o coletor ficou inativo e acumulou 1.846 erros sem que ninguém desse por isso. Se usar OAuth, mantenha o plugin no plano de atualizações e vigie o contador de erros do coletor.
Quem passa a ticket: as regras que apanham de surpresa

| O que chega | O que o GLPI faz |
|---|---|
| E-mail de quem tem conta e pode abrir tickets na entidade | Cria o ticket |
| E-mail de quem não tem conta, com o ticket anónimo desativado (a predefinição) | Recusa: a mensagem vai para a pasta de recusados e fica registada em "E-mails não importados" |
| E-mail de quem tem conta, mas sem direito a abrir tickets nessa entidade | Recusa, pelo mesmo caminho |
| Resposta a um ticket aberto | Passa a acompanhamento |
| Resposta a um ticket fechado | Cria um ticket novo, ligado ao antigo |
| Notificação enviada pelo próprio GLPI | Ignora, para evitar um ciclo |
| Remetente na lista negra | Ignora |
A linha que mais apanha as pessoas é a segunda. Num service desk interno, toda a gente tem conta e a predefinição funciona. Num suporte a clientes, metade dos e-mails pode vir de quem nunca entrou no GLPI. E a recusa é silenciosa: ninguém responde ao remetente, a não ser que uma regra mande responder.
As três saídas, da mais aberta para a mais controlada:
- Criar automaticamente o usuário a partir do e-mail (opção do próprio coletor): quem escreve ganha uma conta e o ticket é aberto. No nosso suporte, é a que usamos.
- Permitir a criação de chamado anônimo (configuração geral de Assistência): o ticket é aberto com o e-mail do remetente, sem criar conta.
- Regra de coletor que recusa com resposta: o remetente recebe um aviso ("abra o seu ticket pelo portal"), em vez de ficar sem nada.
Escolha uma de propósito. O pior cenário é a predefinição sem que ninguém saiba dela.
Como testámos
Com o coletor ativo no nosso GLPI de suporte:
- Um e-mail de teste para o
chamados@passou a ticket na passagem seguinte da recolha, com o remetente reconhecido como requerente. - A resposta por e-mail à notificação do ticket entrou como acompanhamento no mesmo ticket.
- A mensagem saiu da caixa de entrada e foi para
GLPI-Importados. - Verificámos no código do GLPI 11 o caminho de cada caso da tabela acima (remetente desconhecido, sem direito, ticket fechado, anti-ciclo).
Checklist antes de divulgar o endereço
- Coletor com as pastas de aceites e recusados criadas na caixa.
- Regra de coletor a definir a entidade (e, se quiser, a categoria ou o grupo).
- Decisão tomada para o remetente sem conta: criar utilizador, anónimo ou recusar com resposta.
- Limite de anexos de acordo com o que os clientes enviam (capturas de ecrã e PDF costumam passar dos 2 MB).
- Cron do GLPI a correr pela linha de comandos (veja o passo 6 de como instalar o GLPI 11).
- Notificações configuradas, para o cliente receber o número do ticket e poder responder: notificações por e-mail no GLPI.
- Consultar "E-mails não importados" e o contador de erros do coletor uma vez por semana no primeiro mês.
Para eliminar duplicados, assinaturas e respostas automáticas antes de passarem a tickets, veja o Mail Analyzer.
Configuração e teste da NexTool a 4 de outubro de 2026, no GLPI 11.0.7 do nosso suporte, com o endereço [email protected]. Comportamentos de recusa, resposta e anti-ciclo verificados no código-fonte do GLPI 11. Plugin OAuthIMAP: versão 1.5.4 (GLPI 11.0.x), segundo o repositório oficial.