How email-to-ticket receivers turn a shared mailbox into a service desk queue
A GLPI mail receiver lets a service desk turn messages arriving in a mailbox into tickets, so requests sent to a shared address are tracked, assigned and measured like any other ticket. Teams need this when requests already arrive by email and they want those requests recorded in GLPI instead of living in an inbox that nobody can report on. In GLPI terms, a collector is the configured connection to one mailbox over IMAP or POP, and the mailgate automatic action is the scheduled task that polls each collector and creates or updates tickets from the messages it finds. The receiver is not a separate product. It is a configuration of GLPI's own mail feature plus a scheduling decision about how often the task runs.
Most of the work is decided before any GLPI screen is touched. The mail provider and the authentication method determine what the collector can connect to. A mailbox on an on-premises server, a Microsoft 365 tenant and a Gmail account each have different rules for password-based access, and providers have been moving away from basic authentication, so the OAuth path has to be confirmed against the current provider documentation before the collector is designed. Ask the mail administrator which protocols are enabled for the shared mailbox, who can grant application consent, and whether the mailbox is dedicated to the service desk. Those three answers decide whether the collector can be set up as a simple password connection, needs an OAuth client, or needs a mailbox change first.
Before you build the collector, write down how the mailbox will be shared across entities, which GLPI user the tickets will be attributed to, and what should happen to messages from unknown senders. Confirm the GLPI version you run, because receiver options and the way plugins are handled differ between releases, and check the mail server's limits on message size and attachments with both the mail team and your GLPI administrators. A test with a dedicated mailbox and a handful of messages will show whether senders are matched to the right users and whether replies stay on the right ticket before the real queue is connected.
Which receiver setup fits which mailbox
This table compares IMAP and POP receivers, password and OAuth connections for Microsoft 365 and Gmail, and dedicated versus shared mailboxes. Read each row against the mailbox your service desk actually uses, because folder handling and retention decide whether tickets are created once and whether messages stay available for audit. Confirm each provider setting before you build the receiver.
| Option | When it fits | Folder and retention effect | What to confirm with the mail provider |
|---|---|---|---|
| IMAP receiver | Mailbox where ticket emails should stay visible in the mail client after GLPI reads them | Messages can stay in the folder and be marked, so reprocessing and manual review remain possible | Folder names, IMAP access enabled for the account, and whether messages are marked read or moved |
| POP receiver | Simple inbox where GLPI is the only consumer and the mailbox does not need to keep copies | Messages are typically removed from the server after download, so the mailbox is not a retention record | Whether the provider still offers POP for the account and how long copies remain on the server |
| Password-based connection | Legacy or on-premises mail servers where the provider accepts a stored credential | Folder handling depends on the mailbox settings chosen in GLPI, not on the authentication method | Whether the provider still accepts basic password logins for this account type and any app-specific credential it requires |
| OAuth-based connection (Microsoft 365 or Gmail) | Tenant or Google Workspace mailboxes where the organization controls app consent and wants no stored mailbox password | Authentication method changes only, so folder and retention behavior should be tested the same way as the password option | Tenant app registration, consent scopes, redirect settings and the GLPI version that supports the OAuth option |
| Dedicated mailbox | Support address used only for ticket intake, with one owner and clear rules for who reads it | Easy to reason about: every message in the folder is a ticket candidate, so retention rules are simple | Mailbox licensing, retention or litigation holds set by your mail administrator, and who owns the credential |
| Shared mailbox | Team or department address where people also reply and triage by hand | Messages may be moved or read by humans before GLPI fetches them, which can skip or duplicate tickets | Delegation rights, whether the connection can read the shared folder, and how replies are kept out of the intake folder |
| Shared mailbox with a filtered folder | Shared address that needs only a subset of messages turned into tickets | A dedicated sub-folder with mail rules limits what GLPI reads and keeps the rest untouched | Whether server-side rules can move messages into the intake folder for every sender |
Configuring a receiver and testing it before go-live
This sequence takes a mailbox from creation to a verified GLPI receiver that turns incoming messages into tickets in the right entity. Each step ends with a check, so the team knows the receiver works before users are told to email the service desk.
Create a dedicated service mailbox
The client's mail administrator creates a mailbox used only by GLPI, such as a shared service address for the service desk. Keep it separate from personal accounts so that GLPI can read it without exposing an individual's mail. Confirm that the mailbox accepts external mail, that the protocol you plan to use (IMAP or POP) is enabled for it, and that the account can log in from the GLPI server's network location. Record the exact login name, server host and folder you will read from. Done when a test message sent from outside the organization lands in the mailbox's inbox.
Create the collector receiver in GLPI
A GLPI administrator opens the setup menu for collectors and creates a receiver. Enter the mail server host, choose IMAP or POP according to what the mail provider supports, and set the folder GLPI should read. Use the service mailbox credentials and confirm the encryption and certificate options match the provider's requirements. Save the receiver and use GLPI's connection test. Done when the test reports a successful connection and the folder is recognized, with no authentication errors.
Set attachment size and type limits
Before any live mail is processed, the administrator reviews the attachment settings on the receiver. Set a maximum attachment size that suits the service desk's storage and the mail system's own limits, and list the file types that should be accepted. Decide what happens to messages with rejected attachments, and confirm with the mail administrator that the sending side will not silently strip files first. Ask the vendor or the GLPI documentation for the current option names in your version, since they can change between releases. Done when the settings are saved and documented in the runbook.
Define entity routing rules
The service owner decides which entity each incoming message should land in. In GLPI, routing rules can place tickets by the sender's address, the recipient address or the subject, so write rules that match the service mailboxes in use. Add a default entity for messages that match nothing, so no ticket is lost. Test rule order carefully, because the first matching rule usually wins. Done when a rule preview or a test message shows the expected entity for each sample address.
Enable and schedule the mailgate action
The administrator turns on the mailgate automatic action, which is the background task that polls the receiver and creates tickets. Set its frequency to match how quickly the business expects tickets to appear, and confirm the task is running under the scheduled task runner used by the installation. Check the automatic actions list for the last run time and any error status. Done when the mailgate task shows a recent successful run and the receiver is linked to it.
Send test messages with and without attachments
A tester sends at least two messages to the service address from an external account: one plain message and one with a permitted attachment. Send a third with a file that exceeds or violates the limits to confirm rejection behaves as designed. Wait for the next mailgate run, then open the tickets in GLPI. Check that each ticket exists, sits in the expected entity, carries the requester from the sender address, and that the attachments are present or correctly rejected. Done when all test results match the expected outcome.
Check the notification queue for errors
After the test messages are processed, the administrator reviews the notification queue and the automatic actions log for failures. Confirm that no notifications are stuck or failing, since a clean ticket can still hide a broken outbound mail path. Remove or correct the test tickets so they do not reach the live reporting. Record the results, the receiver settings and the rule order in the go-live record. Done when the queue shows no errors related to the test and the record is signed off by the service owner.
How routing rules and attachment limits shape which tickets get created
A receiver decides which tickets exist before any agent sees them, so the first design decision is how an incoming message is matched to an entity and a requester. In GLPI, the receiver's collector reads the mailbox, and the mail is then tested against the rules that apply to incoming mail. Those rules can place a ticket in a specific entity based on the recipient address, the sender domain or a header value. Match on the address that customers actually use, not only the address your team created. Forwarded mail, aliases and distribution lists often change the visible recipient, so a rule written for a single mailbox can silently send tickets to the wrong entity or to the root entity. Confirm the exact fields your rules can read in your GLPI version before you write them.
Messages from unknown senders need a deliberate outcome. Depending on your configuration, GLPI can create the ticket under an anonymous or default requester, reject it, or hold it for review. Each choice has a cost: accepting everything fills the queue with spam and automated notices, while rejecting unknown senders can drop a legitimate request from a new customer or a supplier who has never written to you before. Attachment limits work the same way. Large or unusual files, such as archives, scanned drawings or executables, can exceed the size your mail server or GLPI accepts, and the message may arrive with the body but without the file, which agents then mistake for a complete request. Ask your mail administrator what the maximum message size is at each hop, and decide whether a ticket with a missing attachment should be flagged.
Strict filtering reduces noise but increases the chance of losing a real request, so tune it against evidence, not intuition. Build a test set from real sample mail: a few months of messages from known and new senders, replies with long quoted threads, mail with large or blocked attachments, out-of-office responses and messages sent to every alias that feeds the mailbox. Run the receiver against a non-production mailbox, record which tickets are created, which entity and requester each one receives, and which messages are dropped or held. Review the dropped set with the service desk before you enable filtering in production. Keep the rules under version control or at least documented, because each new alias or customer domain will change the outcome.
Moving Microsoft 365 and Gmail mailboxes to OAuth
A username and password used for IMAP access to a Microsoft 365 mailbox grant broad access to that mailbox, and the same secret is often reused by scripts, service accounts and other receivers. Moving to OAuth 2.0 changes the identity behind the receiver: the receiver authenticates as an application registered in Microsoft Entra ID, and it obtains tokens after an administrator has granted consent. Treat this as an identity change with its own owner, not only a settings edit.
- App registration: Register the application in Microsoft Entra ID, record the tenant and client identifiers, and decide whether the receiver uses delegated permissions for a mailbox user or application permissions.
- Consent: Application permissions for mail usually require an administrator to grant consent. Confirm who can do this in your tenant and whether an access policy can limit the application to a defined set of mailboxes.
- Credential storage: If the app uses a client secret or certificate, keep it in your secrets system, record its expiry and set a rotation owner before it lapses.
- Mailbox scope: Use a dedicated support mailbox rather than a personal account, and confirm which server, port and authentication fields the GLPI receiver expects for OAuth.
Confirm the permission type, consent model and authentication protocol against Microsoft's current documentation for your tenant before you change the receiver.
Gmail mailboxes accessed with an account password or an app-specific password carry the same risk: the credential grants access to the whole mailbox and does not limit it to what the receiver needs. The OAuth move routes access through a Google Cloud project, an OAuth client and a user or administrator consent step for the mail access scope that Google documents for IMAP. The receiver then works with tokens, and the mailbox owner or an administrator controls whether access continues.
- Cloud project: Create or select a project under your organization, configure the OAuth consent screen and create an OAuth client that matches the flow GLPI uses in your version.
- Internal or external app: Internal apps in a Google Workspace organization follow a different path from external apps. External apps that request sensitive mail scopes may need a verification review, so confirm the path early.
- Consent holder: Decide who grants consent, usually a service mailbox owner or a delegated administrator, and record how that consent is renewed or revoked.
- Workspace policy: Check that your Workspace admin settings allow the app and that IMAP access is enabled for the mailbox in question.
Confirm the consent screen, scope and client type against Google's current OAuth documentation and the GLPI release in use before you schedule the cutover.
Switching a receiver from password access to OAuth is a cutover. During the change, mail can stop arriving or arrive without a ticket, so the work needs a test path, an overlap period and a recorded way back. This applies to both providers and should be planned before anyone edits the production receiver.
- Version check: Confirm in the GLPI user documentation and the release notes for your exact version which OAuth options the mail receiver exposes, because support differs between releases and between plugins.
- Test mailbox: Send known messages to a test mailbox through the new receiver and verify the ticket, sender, attachment handling and entity routing before production use.
- Overlap: Keep the old credential valid until the new path has collected mail over a full working cycle, then remove it.
- Rollback record: Save the previous server, port, authentication method and receiver settings so the change can be reverted with a known configuration.
- Monitoring: After cutover, check the mailgate automatic action and the notification queue, and alert on repeated fetch failures.
Confirm each step against the provider's current documentation and the GLPI version in use, since exact OAuth settings change over time.
Security and operational risks of mail-driven ticket intake
A mail receiver turns an inbox into an unauthenticated entry point for your service desk. The cards below cover the risks that come with that design: the mailbox credential, untrusted attachments, reply loops, mailbox growth, silent poll failures and who can see the resulting tickets.
Mailbox credential storage
The receiver logs in to the mailbox with a stored password or token, so anyone who reads the GLPI database or its configuration can reach the mailbox. Use a dedicated service account that can read only the intake folder, not a personal user account. Confirm where GLPI stores the receiver credential and who holds database and file access. Plan a rotation step for the credential, and check that the glpi.key encryption key is backed up with the rest of the configuration, because the stored secret depends on it.
Spoofed or malicious attachments
Anyone who can send mail to the intake address can attach a file, and the sender address is not proof of identity. Set the attachment size limit and the allowed document types for the receiver, and decide whether executable or archive files are accepted at all. Test with a harmless file of each blocked type to confirm the rejection behavior. Treat ticket attachments as untrusted content when staff open them, and keep antivirus or mail gateway scanning in front of the mailbox.
Mail loops from auto-replies
Out-of-office replies, bounce messages and notifications sent from GLPI can return to the intake mailbox and create tickets that open new notifications, which then loop. Check the receiver and mailbox settings for handling of automatic replies, and confirm that GLPI notification addresses are not the same as the intake address. Watch for bursts of tickets from one sender or with the same subject in a short period. Test a loop scenario in a staging instance before go-live.
Mailbox growth and retention
Processed messages stay in the mailbox unless something moves or deletes them, so the intake folder grows and the receiver takes longer on each poll. Decide whether GLPI should delete, move or leave messages after import, and align that with the retention rules your organization applies to email and tickets. Ask your mail administrator what quota and retention policy applies to the service account. Include attachment storage in the GLPI backup plan, since ticket files can grow faster than the mailbox.
Failed polls going unnoticed
If the mailbox login fails, a certificate expires or the IMAP server changes, the receiver stops creating tickets and nothing in the ticket queue signals the gap. The mailgate automatic action runs on a schedule, so review its last run and its errors as part of routine operations. Define a check that compares inbound mail volume with tickets created, and route alerts to a person who owns the service desk. Test the alert by changing the password in a staging mailbox.
Ticket access by entity
Tickets created from mail land in the entity chosen by the receiver's routing rules, and a wrong rule can expose one customer's requests to another entity's staff. Review the routing rules that map sender domains or recipient addresses to entities, and test each mapping with a sample message from each sender group. Confirm that the profiles and entity rights for the service desk limit visibility to the entities they support. Check the rule order, because the first matching rule usually wins.
Questions teams ask before setting up email intake
How much effort does a GLPI mail receiver setup take?
Effort depends mainly on how many mailboxes feed GLPI, how many entities and request types they map to, and how much of the routing you want to automate. A single shared support mailbox with one entity is a small job. Several mailboxes that route to different entities, with attachment limits, reply handling and testing across each path, takes considerably more. The main cost components are internal time from your mail and service desk staff, any partner time for a fixed-scope configuration and testing plan, and ongoing review. Ask any quote to list the mailboxes, the routing rules, the test cases and who signs off on each step.
Can our own team set up GLPI email receivers in-house?
Yes, if your team has someone comfortable with GLPI administration, mail protocols and your mail provider's settings. The GLPI configuration itself, meaning receivers for IMAP or POP, attachment limits and routing to entities, is documented in the GLPI user documentation and the admin interface. The harder parts are usually outside GLPI: mailbox permissions, app passwords or OAuth registration, and confirming that routing rules behave correctly for real messages. If nobody on your team has done this before, a fixed-scope engagement can cover the build and hand over documentation so your team can run it afterward.
What do our mail administrators need to provide?
Your mail administrators need to provide the mailbox addresses, the protocol and server details GLPI will connect to, and an account with the access GLPI needs to read and mark messages. For Microsoft 365 or Gmail, they also need to decide how authentication will work, since modern tenants may restrict basic password logins and require OAuth-based access. They should confirm which folders GLPI may read, how spam and automatic replies are handled, and who approves changes to mailbox permissions. Ask them to review the plan before the first test message is sent.
How do we move a Microsoft 365 or Gmail mailbox to OAuth without losing tickets?
Plan the cutover as a parallel test, not a switch. Create and test the OAuth-based receiver on a non-production or test mailbox first, confirm that new messages create tickets and that replies are threaded correctly, and only then point the production receiver at the new authentication method. Keep the old receiver disabled but available for a rollback window, and record which messages were processed so none are read twice or skipped. Confirm the exact registration and consent steps with Microsoft and Google for your tenant, because their requirements change.
What ongoing checks does a GLPI email intake need?
Check that the mailgate automatic action runs on schedule, that new messages turn into tickets, and that failed or rejected messages are visible to someone who acts on them. Review attachment limits after any change to mail size policies, and recheck routing rules when entities, groups or request types change. Mail tokens, app passwords and OAuth consents can expire or be revoked, so add them to your credential review calendar. After each GLPI upgrade, confirm that receivers and plugins still work, because plugins are suspended after a new version is detected and must be reactivated after major updates.
Does email intake raise security or compliance concerns?
It can. Mail often contains personal data and attachments that may carry malware, so limit attachment sizes and types to what your service desk needs, and make sure the mailbox credentials are stored and rotated under your normal secrets practice. Give the GLPI receiver the narrowest mailbox access that works. For compliance, your auditors will want evidence of who can change routing and how changes are approved, so keep the configuration and its change history. DeployOpen prepares systems and evidence for assessments, but independent auditors issue any audit reports.
Should we use IMAP or POP for GLPI email receivers?
Choose IMAP unless your mail provider only offers POP or you have a specific reason to leave messages on the server. IMAP keeps messages in the mailbox and lets you control folders and read state, which makes it easier to see what has been processed and to recover from errors. POP downloads messages and can make troubleshooting harder when a message is missed. Confirm which protocols your mail provider currently supports and how they authenticate, since this decision also affects the OAuth move later.
How DeployOpen scopes and delivers email-to-ticket intake
Every email-to-ticket engagement starts with a written scope agreed before any mailbox is touched. That scope names each receiver, the mailbox it reads, the protocol (IMAP or POP), the entity each mailbox routes into, the attachment and size limits, and who approves go-live. DeployOpen reviews the mailbox provider with your team first. For Microsoft 365 or Gmail, that review covers whether the mailbox still relies on basic authentication, which OAuth app registration or consent path applies, who holds the tenant or workspace administrator role, and whether shared mailboxes, aliases or mail flow rules already forward mail somewhere else. Confirm these answers with your provider and your identity team before the receiver design is locked, because they decide whether the work is a configuration task or a migration.
The delivery plan then covers receiver and routing configuration, a test plan built from sample mail, and handover. Test mail should include plain replies, messages with large or blocked attachments, forwarded threads, messages from unknown senders, and mail to addresses that should be rejected. Each case gets an expected result: which entity the ticket lands in, whether the requester is matched, and what the notification queue shows. Handover documentation records the receiver settings, routing rules and mailgate automatic action schedule, along with the runbook for reactivating plugins after a GLPI major update, which is required in GLPI 11 and later. Teams that want help with upgrades, plugin reactivation or changes to mailbox policy after go-live can add an optional retainer, scoped in writing like the initial work.
