A support inbox receives a lot of mail that nobody on your team wrote to and nobody needs to answer. Out-of-office replies, bounces, newsletters, mailing-list confirmations, password-reset notices from a tool someone signed up for with the support address. A helpdesk has to decide what to do with all of it, and every decision it makes for you is one you can’t see.

This post walks through what Scitor does with a message between “arrived at your inbound address” and “became a GitHub Issue or Discussion”. It also introduces a new setting that puts one of those decisions in your hands.

The rule: label, don’t drop

There are two ways to handle a message that might not be real support mail. You can drop it, so your queue stays clean and you never know what you missed. Or you can label it: it shows up, clearly marked, and you decide.

We default to labelling. A support tool that loses one real customer email has failed at its only job, and a few extra labelled tickets cost far less than that. So we drop mail only when there’s no judgement to make, and even then we keep it around long enough to undo a mistake.

Step by step

1. Is the sender blocked?

If someone on your team ran /block-sender on an earlier ticket, mail from that address stops here. The block list stores a SHA-256 hash of the address, not the address itself. This is the one place we discard mail without keeping a copy: you asked for it explicitly, and holding on to mail from someone you blocked would only be a privacy liability.

2. Was it written by a person?

Next, Scitor checks whether software sent the message. It reads the standard headers that mail systems add for this purpose, not the message content:

Auto-Submitted (vacation responders, bounce notices, notifications)
Precedence: bulk or junk (newsletters, mailing-list admin mail)
out-of-office markers such as X-Autoreply
an empty return address (a bounce)
mail from your own Scitor sender address coming back

What happens next depends on where the message is going.

If it’s a reply to a ticket, it’s dropped. When you answer a customer, the reply-to address points back at that ticket. If the customer is on holiday, their out-of-office notice goes there too. Let it through and it shows up as a customer comment and reopens the ticket. If your side has an auto-acknowledgement too, two robots can answer each other forever. No team wants that, so it isn’t a setting. It also covers automated replies that arrive at your main address but reference a message Scitor sent.

If it’s a new message, you decide.

3. A new automated message: label or drop

Whether a newsletter belongs in your support queue depends on your team. Some teams subscribe their support address to a vendor’s status list or a data provider’s announcement list on purpose, and want every message as a ticket. Others never act on that mail and would rather not see it. That’s not a decision a helpdesk should make for you, so it’s a setting, in the inbound section of .github/scitor.yaml:

inbound:
  auto_generated: label   # default
  # auto_generated: drop

With label, the default, the message becomes a ticket labelled auto-generated. It’s handled a little differently from customer mail, because nobody is waiting on an answer:

No spam label. Automations that fire on spam:clean, like an auto-acknowledgement, don’t reply to a robot.
No SLA clock, so a newsletter can’t breach your response targets.
No CSAT survey when you close it.
No merging. A recurring alert is never added to an existing customer conversation, and never reopens one.
AI analysis still runs if you’ve turned it on, so it gets a category and a summary like everything else.

With drop, no ticket is created. Forwarding confirmations are the exception: they always come through, because you can’t finish setup without them.

4. Analysis, if you’ve opted in

AI is off by default. If you’ve enabled it with ai: true, a bounded slice of the message is analysed for sentiment, category, priority, language and a one-line summary. The output becomes labels and a short note on the ticket. The input isn’t kept. How we handle AI has the details.

5. Rate limiting

A single sender can create at most 5 messages a minute and 30 an hour by default (configurable, or switch it off). This stops a misbehaving script or a mail loop from flooding your repository. When a sender hits the limit, Scitor posts one notice per day on their most recent ticket, so you notice.

6. Threading

Scitor then checks whether the message belongs to an existing ticket. It first looks for an exact match on the In-Reply-To and References headers, scoped to your repository, and only when the sender was a recipient of the message they’re replying to. Failing that, it matches on sender and subject within a look-back window (7 days by default). A match becomes a comment on that ticket, and reopens it if it was closed and you’ve enabled reopen_on_reply.

7. The ticket

Finally, the GitHub Issue or Discussion is created with the sender, subject, body and links to attachments, which are stored separately. Labels are applied: a spam-score label (spam:clean to spam:high) on every human message, plus AI and priority labels if enabled. Routing rules assign it if you’ve configured them.

The spam score deserves a note: it’s a label, never a reason to drop. A high score is a strong hint, but we’ve all seen legitimate mail with a high score. You can close those tickets with a short GitHub Action, or block a repeat offender. We won’t make that call for you.

Nothing disappears silently

Everything that’s held back for a fixable reason is kept for 7 days and then deleted. That includes automated replies to tickets, new automated mail under drop, rate-limited mail, and mail we couldn’t parse. We review a daily summary of what was held back and why, so a rule that starts catching real mail gets noticed quickly. If you think something of yours was held back by mistake, tell us within that week and we can deliver it to your repository.

After 7 days it’s gone. Once a ticket exists, the raw email isn’t kept anywhere else: what remains is the ticket in your repository and its attachments, under the retention rules on our security page.

In short

Scitor drops mail only when keeping it would clearly hurt you: an out-of-office loop, a sender you blocked, a flood from one address. Everything else is labelled so you can see and filter it, automated mail included. If your inbox gets a lot of newsletters you’ll never act on, auto_generated: drop is one line away. The default just doesn’t hide anything from you.

The full reference is in the Automated Email docs.

What Happens to an Email Before It Becomes a Ticket