Channels
How tickets arrive - mail, web form and customer portal - and what each channel does and does not trust.
A ticket belongs to a mailbox. Three channels create or extend tickets in it.
The IMAP worker reads each mailbox and turns mails into tickets or replies to existing ones. Mailboxes sign in with a password or with OAuth2 (XOAUTH2) for Google and Microsoft 365; refresh tokens are stored encrypted and never returned by the API. Admins start the browser consent flow through the API (POST /api/mailboxes/:id/oauth/start); there is no settings page for it yet.
Mails whose Authentication-Results header reports spf=fail, dkim=fail or dmarc=fail are accepted but flagged, and the ticket shows a warning. Helpdesk does not validate SPF, DKIM or DMARC itself, it only reads the header your receiving mail server writes.
Web form
Each mailbox can enable a public contact form at /contact/<mailboxId>, embeddable as an iframe. It is off by default. A honeypot field and rate limits (5 submissions per 10 minutes per IP, 30 per hour per mailbox) protect it. The sender address is only claimed, so tickets from the form are marked as unverified, and an existing customer matched by address is not trusted.
Customer portal
The portal at /portal is off by default (PORTAL_ENABLED, PORTAL_MAILBOX_ID). Customers sign in with a one-time link sent to the address of an existing customer record. The link works once and for 15 minutes, and it is redeemed by a button, so mail scanners cannot use it up. The request gets the same answer whether the address is known or not.
In the portal customers see their own tickets and those of their organization, only the published messages (no notes, drafts, tags or assignees), and answers from staff appear as “Support”. They can reply, attach files and open new tickets. The portal session is separate from the agent session, and neither is accepted by the other’s API.
All limits, cookie settings and the setup steps are in the deployment guide.