This week we connected [email protected] to our GLPI 11: an email becomes a ticket, and the customer's reply becomes a follow-up on the same ticket. But with the default configuration, when someone without a GLPI account writes in, the email goes to the refused folder and nobody receives anything. This guide shows the configuration we use, what changes between Gmail and Microsoft 365, and the rules that decide whether an email becomes a ticket or disappears.
How the mail receiver works
GLPI reads a mailbox over IMAP at fixed intervals. For each message:
- A new email becomes a ticket, with the subject as the title and the body as the description. Attachments come along, up to the configured limit.
- A reply to a ticket becomes a follow-up. GLPI recognizes the reply by the message headers, not just by the subject.
- Anyone in CC can be added as an observer.
- Once processed, the message is moved to an accepted or a refused folder, and the inbox stays clean.
Collection is an automatic action (mailgate) that, by default, runs every 10 minutes and reads up to 10 emails at a time. In other words, a ticket sent by email can take up to 10 minutes to show up.
The configuration we use
In Setup > Receivers:
| Field | What we use |
|---|---|
| Server | imap.gmail.com, port 993, IMAP with SSL and certificate validation |
| Login | The account that receives chamados@ (an alias that delivers to this mailbox) |
| Accepted mail archive folder (optional) | GLPI-Importados |
| Refused mail archive folder (optional) | GLPI-Recusados |
| Maximum size of each file imported by the mails receiver | 10 MB |
| Add CC users as observer | Yes |
| Collect only unread mail | No (the folders already separate what has been processed) |
Plus a receiver rule that sets the ticket's entity. Without a rule, the email has nowhere to go.
Gmail or Microsoft 365: authentication changes everything
GLPI 11 connects over IMAP with a username and password. What changes is what each provider accepts:
- Gmail / Google Workspace: works with an app password (the account needs 2-Step Verification), which is what we use. For those who prefer OAuth, there is the official OAuthIMAP plugin.
- Microsoft 365 / Exchange Online: Microsoft has turned off basic authentication for IMAP; username and password no longer work. The way forward is the OAuthIMAP plugin (version 1.5 for GLPI 11), with an application registered in Microsoft Entra ID.
OAuth does not come built into GLPI 11. Our own GLPI had an old receiver with Google OAuth that depended on the plugin. The plugin was removed, the receiver went inactive and piled up 1,846 errors without anyone noticing. If you use OAuth, keep the plugin in your update plan and keep an eye on the receiver's error counter.
Who gets a ticket: the rules that catch you off guard
| What arrives | What GLPI does |
|---|---|
| Email from someone who has an account and can open tickets in the entity | Creates the ticket |
| Email from someone without an account, with anonymous tickets turned off (the default) | Refuses: the message goes to the refused folder and is logged under "Not imported emails" |
| Email from someone who has an account but no right to open tickets in that entity | Refuses, the same way |
| Reply to an open ticket | Becomes a follow-up |
| Reply to a closed ticket | Creates a new ticket, linked to the old one |
| Notification sent by GLPI itself | Ignores it, to avoid a loop |
| Sender on the Blacklist | Ignores it |
The row that catches people out most is the second one. In an internal service desk, everyone has an account and the default works. In customer support, half of the emails may come from people who have never logged into GLPI. And the refusal is silent: nobody replies to the sender unless a rule says so.
The three ways out, from the most open to the most controlled:
- Automatically create user from email (an option of the receiver itself): whoever writes in gets an account and the ticket is opened. It is the one we use on our support instance.
- Allow anonymous ticket creation (receiver) (general Assistance setting): the ticket is opened with the sender's email address, without creating an account.
- Receiver rule that refuses with a reply: the sender gets a notice ("open your ticket through the portal") instead of getting nothing.
Pick one on purpose. The worst scenario is the default with nobody aware of it.
How we tested
With the receiver enabled on our support GLPI:
- A test email to
chamados@became a ticket on the next collection run, with the sender recognized as the requester. - The email reply to the ticket notification came in as a follow-up on the same ticket.
- The message left the inbox and went to
GLPI-Importados. - We checked in the GLPI 11 code the path of each case in the table above (unknown sender, no rights, closed ticket, anti-loop).
Checklist before publicizing the address
- Receiver with the accepted and refused folders created in the mailbox.
- Receiver rule setting the entity (and, if you want, category or group).
- Decision made for senders without an account: create the user, anonymous, or refuse with a reply.
- Attachment limit in line with what customers send (screenshots and PDFs often exceed 2 MB).
- GLPI cron running from the command line (see step 6 of how to install GLPI 11).
- Notifications configured, so the customer receives the ticket number and can reply: email notifications in GLPI.
- Check "Not imported emails" and the receiver's error counter once a week during the first month.
To remove duplicates, signatures and auto-replies before they become tickets, see the Mail Analyzer.
Configured and tested by NexTool on October 4, 2026, on the GLPI 11.0.7 of our support desk, with the address [email protected]. Refusal, reply and anti-loop behaviors checked in the GLPI 11 source code. OAuthIMAP plugin: version 1.5.4 (GLPI 11.0.x), according to the official repository.
