How SAGARIS classifies replies and marks opt-outs
One thread list over every mailbox in the workspace, and one send path underneath it. A reply is not just delivered to a folder: it is classified, and the classification decides what the system asks you to do next.
One list, three sources
The inbox is a merge rather than a folder. Mail synced from your connected mailbox, sends made by a sequence or a campaign, and messages handled by the SAGARIS mail platform are three different records in three different places, and the inbox resolves them into one sent-and-received history per thread.
That merge matters because campaign sends never landed in the provider mailbox cache. A view built on the provider sync alone shows you a conversation with half of your own side of it missing. Each row keeps its origin, so you can always tell whether a message came from the provider, a sequence, a campaign or a person typing.
What a reply becomes
Every inbound reply is classified, and each classification carries exactly one required action. This is the part that makes the inbox a queue rather than a pile.
- positive, question
- Book a meeting or reply.
- objection
- Handle the objection.
- not_now, future_interest
- Schedule the follow-up. A later or next-quarter reply is a live re-engage signal on the timeline the message itself gave, not a dead objection.
- competitive_opportunity
- Run the repositioning play. An incumbent mention is an active buyer to win. It is never collapsed into an objection and never suppressed.
- questions
- Draft an answer for review.
- out_of_office
- Pause until they return.
- unsubscribe
- Suppress the contact. An email reply saying the person has left the company, or that you have the wrong contact, is an unsubscribe too. On LinkedIn or SMS the same reply goes to a person to decide.
- bounce
- Suppress the bounced address.
- referral
- Route the referral.
- neutral
- Draft a reply.
- needs_human
- Review manually. The classifier says so rather than guessing.
Sending, and why volume starts low
A new sending identity does not start at full volume, because a cold mailbox that sends like a warm one is how a domain gets filtered. Volume ramps on a day-indexed curve, and the curve is one committed file that both the mail plane and the application read, so the two cannot disagree about what today's cap is.
- Per mailbox
- Weekly milestones of 5, 10, 20, 30 and 40 sends a day, plateauing there, with a hard ceiling of 50 a day.
- Per domain
- Weekly milestones of 15, 30, 60, 90 and 120 sends a day, with a hard ceiling of 150 a day.
The expansion between milestones is clamped so a cap can never more than double week over week, and a milestone that would dip below the previous one is raised to it rather than allowed to fall.
Unsubscribe and suppression
Commercial mail carries a signed RFC 8058 one-click unsubscribe: the List-Unsubscribe and List-Unsubscribe-Post headers a mailbox provider turns into an unsubscribe button in its own interface.
One provider is an exception and it is deliberate. Microsoft Graph rejects a custom header named List-Unsubscribe outright, and the Outlook send path throws on a rejected request, so setting it would turn every commercial Outlook send into a failure. The Gmail, SMTP and mail-platform routes carry the headers. A missing header on one connected provider costs a little deliverability; a thrown send is an outage.
An unsubscribe is not a flag on a contact row. It is written to a suppression store keyed on the email address or the phone number, so it survives the contact being edited, deleted or re-imported, and it applies across every channel: an opt-out on one channel suppresses the others. A suppressed contact also cannot be advanced through the pipeline, and that hold is not overridable.
AI-drafted mail is marked
A message whose body was drafted by an AI system carries a machine-readable X-AI-Generated header, and the same provenance is stored with the send record rather than only on the wire.
It is marked even when a person reviewed or edited the draft before it went, because AI-drafted and human-reviewed is the true provenance: the marker is a statement of origin, not of who pressed send. This over-discloses on purpose while the scope of the EU AI Act's Article 50(2) marking duty for a human-approval workflow is still an open question.
Behaviour on this page is read from
- src/lib/mailbox/unified-record.ts
- src/lib/unified-inbox.ts
- src/lib/inbound-reply.ts
- mail/mailconfig/mail-system.json
- src/lib/warmup-ramp.ts
- src/lib/mailbox/gmail-api.ts
- src/lib/mailbox/outlook.ts
- src/lib/suppression-store.ts
- src/lib/email/ai-provenance.ts
Was this page helpful?
In this topic