Administration

Email channel

Inbound email becomes tickets, outbound email goes through an outbox.

The email channel turns email sent to your helpdesk address into tickets, and sends replies and notifications back by email. This page explains how an admin connects a mailbox and monitors incoming and outgoing messages.

All settings are under Administration → Email channels. The page has three tabs: Mailbox, Inbound messages, and Notifications.

Before you start

The server operator must have set the two email channel secret keys. Without them, mailbox passwords cannot be saved. See Installation.
Prepare a dedicated helpdesk mailbox with POP3 and SMTP access. RANCAQ deletes messages from the POP3 server after they have been processed, so do not use a personal mailbox.
Changing mailboxes and notifications requires the channel.manage permission.

Connecting a mailbox

On the Mailbox tab, click New mailbox.
Fill in Name and Email address. This is the address requesters write to, and the sender address used for replies.
Leave Enabled on. A disabled mailbox is neither polled nor used to send, but its configuration stays saved.
In the Receiving (POP3) section, fill in Host, Port, Encryption, Username, and Password. The encryption options are Direct TLS (implicit), STARTTLS, or No encryption.
In the Sending (SMTP) section, fill in the same details for the outgoing server. You can also fill in Sender name and Reply-To.
In the Inbound email handling section, choose the Default ticket type (Incident or Service request), Default responsible team, Default site, and the Unknown sender policy.
Click Save.
Open the mailbox again with Edit, then click Test receiving and Test sending. These tests use the credentials saved on the server and do not send any email.

Passwords are stored encrypted. When editing a mailbox, leave the password field blank if you do not want to change it.

Unknown senders

Senders are recognized by their email address. For an address that does not match any user, choose one of:

Option	Result
Hold for review	The email goes into the held queue and waits for an admin decision.
Create ticket with external requester	A ticket is created immediately. Suited to a mailbox that serves outside parties.
Reject	The email is logged, then ignored. The sender receives no reply.

From email to ticket

The worker polls every enabled mailbox at a regular interval. The interval is set by the server operator; the default is 60 seconds. Each email is processed in this order:

Duplicate. An email with a Message-ID that was already processed is not processed again, so no ticket is created twice.
Auto-reply. Machine replies, such as out-of-office messages or bounce notices, are logged, then ignored to avoid an email loop.
Sender. The sender is matched to a user. If unknown, the policy above applies.
Reply or new ticket. An email counts as a reply to an existing ticket if its reply headers match an email that was sent or received earlier, if its recipient address carries a reply token, or if its subject contains a ticket number. The sender must also be a party to that ticket, for example the requester or an authorized agent.
A reply becomes a public comment on that ticket. Any other email becomes a new ticket with the mailbox's default type, team, and site. The email subject becomes the ticket title, the body becomes the description, and attachments are stored with it.

Incidents from email use the default incident SLA policy. Service requests from email get no SLA target.

Inbound messages tab

This tab logs every email that was pulled, together with its Outcome: Ticket created, Reply added to ticket, Duplicate, Held, Rejected, Failed to process, or the outcome for auto-replies. You can filter by outcome and search by subject or sender address. Click a row to see the Inbound email detail.

For Held messages, users with the channel.quarantine.review permission can choose:

Make ticket: the message becomes a new ticket on behalf of its sender and enters the mailbox team's queue. The sender receives a reply with the ticket number.
Discard: the message does not become a ticket. This cannot be undone, and the sender is not notified.

Outgoing notifications

Email notifications are not sent in the middle of a user's request. Each event is recorded first, then the worker composes and sends the email. Tickets that came in by email are answered through their original mailbox; other tickets use an available enabled mailbox.

The Notifications tab contains the Email notification categories, which can be turned on or off for the whole tenant: Ticket received confirmation, New reply, Status & resolution changes, Assignment, Approval request, Approval outcome, SLA approaching deadline, and SLA breached. SLA approaching deadline is off by default. Internal notes are never sent to the requester.

Delivery status and retries

In the ticket detail, the Email delivery card shows the status of each delivery:

Waiting to send and Sent.
Failed, will retry: retried with increasingly long delays, about 7 hours in total.
Stopped retrying: the retries have run out.
Not sent: delivery to that address was stopped after repeated bounces.

For the last two statuses, users with the channel.manage permission can click Try again once the cause has been fixed. The delivery is queued again and sent by the worker on its next cycle.

Mailbox health

Each mailbox card shows the status Healthy, Having issues, Never run, or Disabled, along with the last Fetch and Send times. If a mailbox has problems, a warning with its error message appears above all three tabs. A failure in one mailbox does not stop the others.