Email to ticket in WordPress, without the usual email failures

Support rarely arrives at one address. Returns go to returns@, billing questions go to accounts@, resellers write to wholesale@, and a handful of named accounts have been given a vip@ address that somebody promised would be answered faster. In most WordPress ticket systems that reality is flattened into one inbox and then patched up with rules, which is why replies start going out from a generic system address nobody recognises.

In Stillpoint each mailbox is a first-class object. It carries its own team, its own brand, its own SLA policy, its own signature, its own auto-reply text, its own ticket-number prefix and its own default priority. A ticket that arrives at returns@ is numbered RET-1042, sits in the returns queue, is measured against the returns SLA and is answered with the returns signature.

The part that matters to the customer is simpler: a reply always leaves from the address they wrote to. If they emailed accounts@, the answer comes from accounts@, and their own reply-to-that-thread behaviour keeps working the way they expect.

Different organisations have different constraints. A small store with a cPanel mailbox wants to be collecting mail in five minutes. A 900-seat Microsoft estate will not hand out an app password, and needs OAuth signed off by a tenant administrator. Somebody else does not want the helpdesk touching the mailbox at all and would rather forward a copy. All of those are supported, and none of them is a second-class path.

IMAP is the fastest route and needs no registration anywhere. It is worth being explicit about one detail: TLS certificate verification is always on and there is no setting to switch it off. A helpdesk that offers a checkbox to accept an invalid certificate is offering to accept anyone's mail, and that checkbox is usually ticked during a hurried setup and never unticked.

OAuth is worth the paperwork for large Google or Microsoft estates, where central credential policy makes app passwords a dead end. In both cases the application is registered in your own tenant, so the trust relationship is between your mailbox and your own site — not between your mailbox and us.

A customer replies to your answer, their mail client rewrites the subject line, and their reply arrives as a brand new ticket. Two agents now answer the same person separately, and the customer concludes you are not paying attention. This is the single most common complaint about email piping plugins, and it happens because the subject line is being used as the primary thread signal when it is the weakest one available.

Stillpoint matches inbound mail through an ordered cascade, strongest signal first. Each step is something we either control cryptographically or can verify against messages we have actually sent.

Step five is where other systems open a security hole. If a ticket number in the subject is on its own enough to attach a message to a conversation, then anybody who learns a ticket number — a forwarded email, a screenshot, a guessed sequence — can inject a message into that conversation and, depending on the system, read the reply. In Stillpoint a matching ticket number from an unrecognised sender opens their own ticket instead. Nothing is lost, and nothing leaks.

Every message records how it was matched. When a thread does go somewhere unexpected, you can open the message and see which signal was used, which makes a mis-thread a diagnosable event rather than a mystery you argue about.

The second classic failure is the same email becoming two or three tickets. It happens when two cron runs overlap, when a webhook provider retries a delivery it believes failed, or when an IMAP session is interrupted after reading but before marking. Any of those can be papered over with careful code — until somebody edits that code.

Stillpoint does not rely on careful code here. Deduplication is a UNIQUE constraint in the database on the mailbox plus a delivery key: the provider message id where one exists, else the RFC Message-ID, else the IMAP UIDVALIDITY:UID pair, else a content hash. The record is written before any parsing work happens, so a duplicate delivery is rejected at the cheapest possible moment rather than after a megabyte of MIME has been decoded.

Stated plainly: this is a schema guarantee, not a code path. A future logic bug cannot reintroduce duplicate tickets, because the database will refuse the insert.

A support mailbox does not receive a tidy stream of customer questions. It receives out-of-office replies, bounce notifications, mailing-list traffic, spam, messages far larger than your upload limit, and the occasional message whose MIME structure is simply broken. How a helpdesk behaves on those is the difference between a queue you can trust and a queue somebody has to clean out every morning.

Nothing in this table is silently deleted. Every non-standard outcome leaves a record with a stated reason, and anything quarantined can be inspected and released.

Customers explain problems with screenshots, and screenshots pasted out of Outlook arrive as inline CID references rather than ordinary attachments. If a helpdesk does not rewrite those references, the agent sees a broken image icon and asks the customer to send it again. Stillpoint rewrites inline images to authorised URLs so they render in the conversation the way the sender intended.

Attachment handling is deliberately suspicious. Files are checked by magic bytes as well as by file extension, so a file called invoice.pdf that begins with a Windows executable header is rejected regardless of its name. And attachments are only ever served as downloads, with nosniff, never rendered inline — which is what stops a stored SVG or HTML attachment from executing script in your site's origin.

A remote image in an email is a tracking device. When your agent opens a message and the client loads that image, the sender learns the exact moment it was read and the IP address it was read from. For a support team that is a genuine problem: it tells anyone who emails you when your staff are working, how quickly they triage, and roughly where they are.

Stillpoint neutralises external image sources by default and shows a labelled placeholder instead. An agent who needs to see the image can choose to load it, which is a deliberate decision rather than an accident of opening a ticket.

Anyone who has run a helpdesk knows the real question is not whether email collection will break, but how long it takes to discover that it has. A red dot that says "error" is not an answer. This is the part of the system built for the person who gets asked why a customer's email never turned into a ticket.

Each mailbox has a health panel: connected state, last successful sync, current lag, messages processed today, problems today, queue backlog, send failures in the last 24 hours, authentication state and consecutive failure count. Every non-healthy state carries a stated reason — authentication rejected, connection timed out, certificate mismatch — rather than a colour.

Alongside it there is a searchable mail log, filterable by mailbox, state, classification, ticket and Message-ID. It deliberately does not contain message bodies: an administrator browsing a diagnostic log should not be reading customers' mail. And there is a failed-mail queue you can inspect and retry. Nothing is ever silently discarded; a message that exhausts its retries is marked and kept rather than deleted. Service managers are notified after three consecutive mailbox failures, so an expired password is a notification rather than a discovery.

Replies go out through the mailbox's own SMTP configuration, which is also how you use a delivery provider: point the mailbox at SendGrid, Mailgun, Postmark or Amazon SES as an SMTP relay and your From address stays yours. There is no separate sending identity to explain to customers.

Then the honesty point. When a provider accepts a message, Stillpoint reports "Accepted by <provider>. Delivery to the recipient is not confirmed." It does not print "Delivered", because that is not what the provider told us — acceptance by a relay is not arrival in a mailbox, and a helpdesk that conflates the two teaches agents to trust a status that does not mean what it says.

Temporary failures retry with exponential backoff. Permanent failures — a bad address, an authentication rejection — stop immediately rather than burning your sending reputation on a message that will never arrive, and the agent is told the customer did not receive the reply so somebody can pick up the phone.

WordPress cron only fires when somebody visits the site. For a scheduled report that is tolerable; for collecting support mail it is not, because a quiet Sunday night means nothing is collected until the first visitor arrives on Monday.

Stillpoint therefore exposes a token-authenticated collection endpoint you can point a real system cron at. One line in crontab, and collection runs on a schedule that does not depend on traffic. There is also a "Run collection now" button for when somebody is standing over your shoulder asking where their email went.