Skip to main content

​
Inbound attachment threat scan

Every inbound email attachment that arrives at a domain you point at Orbit passes through a byte-level threat scan — the same gate inbound MMS media passes — before it reaches your agents or your recipients. One action follows a part’s verdict: allow and archived to the media store, or quarantine and dropped before any byte is uploaded. The scan is a tenant-owned intake control: your account’s policy decides which verdicts reach your agents, and the metadata keys below are the audit record of every drop.
Own this control. Orbit enforces the verdict your policy accepts and keeps the audit ledger, but the posture — which files your intake admits, which findings you tolerate as advisory, and which trigger a hard quarantine — is yours. The scan is a tenant-owned intake control in the same sense as the rest of your compliance posture: Orbit is the conduit and the ledger, not the compliance owner.

​
Intake gates — what a part must clear before the scan decides

The scan decides on the parts your intake admits. Two tenant-owned gates run first, at intake, before a part ever reaches the scanner — so the scan rate is a knob you hold, not a platform mandate. The metadata contract names what the scanner can see; the gates name what it never sees because intake rejects it. Only what your intake admits reaches the scanner — your intake policy is the tenant-owned surface you tune. The Email attachments guide documents the full intake contract (the 25 MB per-part ceiling, the MIME rules, and the multipart envelope) your policy reads.

​
Finding-code vocabulary

Every quarantined message records the per-part breakdown as machine-readable finding_codes on metadata.email_attachments_quarantined. Read them with the audit map below: this is the complete enumeration of the signal classes the composite scorer can raise, in the fixed evaluation order the scorer runs them (external AV verdicts first, then byte-signature checks, then markup / active-content, then metadata name-checks).

​
Verdict bands — clean, suspicious, malicious

The scan composite-scores the signal classes above and cuts the score into three bands. The bands are coarse by design — you see a verdict, not a wiring diagram. Each matched class adds points; the band is the cutoff the score crosses. Two actions follow from the band:
  • allow — archived to the tenant’s media store. A suspicious part still archives — your agent sees it, and the flag tells your team to look.
  • quarantine — the part is dropped before it is uploaded: it never reaches the media bucket, never lands in an agent inbox, and serves no bytes to your recipients. The message metadata below carries only PII-safe finding codes.

​
Operator workflow — detect → inspect → decide → tune

Work every quarantined part to closure with this four-step loop. The scan drops the part; this runbook is what closes the finding.
  1. Detect. A recipient reports a missing attachment, or you watch the quarantine counter on the inbound-parse payload. Open the message and check metadata.email_attachments_quarantined — if the key is absent the part archived and the issue is elsewhere (the media-store URL, or the view the recipient uses).
  2. Inspect the audit record. Read the entry’s finding_codes and band. The codes name exactly which signal classes matched; the band is the score cutoff they crossed. Use the vocabulary table above to read what each code caught.
  3. Decide release or re-upload cleaned. A quarantined part is never re-hosted — it carries no URL on purpose. Ask the sender to re-send a cleaned file, or upload a cleaned replacement through the Files API if your flow requires one. If the verdict looks wrong on a business-critical part, escalate the finding_codes and the message id to support — do not re-upload the same bytes; the same gate will drop them.
  4. Tune your intake policy. When quarantines cluster, they cluster on what your intake admits. Tighten the allow-list to the content types and sizes your flows genuinely use in your tenant-owned intake rules — point your inbound at a smaller admitted surface and the scanner sees less. The Email attachments guide documents the limits your policy reads.

​
The metadata contract

The scan stamps onto each message row in one pass, so the audit trail shows both outcomes:
  • metadata.email_attachments — the archived allow parts, in the same { filename, url, content_type, size } shape the outbound send path writes, so the message detail view renders each entry with a re-freshed download URL.
  • metadata.email_attachments_quarantined — the quarantined parts, one entry per part: filename, content_type, size, score, the band, and the finding_codes of each matched signal. No raw bytes, no sender content.
A message whose inbound email declared attachments stays metadata-only in the inbound-parse webhook payload — the keys above are the archive/audit contract the forward cannot inline.

​
Worked JSON sample

​
Troubleshooting

My recipient says an attachment is missing. Check metadata.email_attachments_quarantined before treating the send as a delivery failure — a quarantined part’s entry names the part and the finding codes. If the key is absent, the part archived and the recipient-side issue is elsewhere (the media-store URL, or the view the recipient uses). The operator workflow above is the full loop for a confirmed quarantine.

​
See also

Inbound email and SMS routing

The end-to-end inbound email guide this quarantine model plugs into.

Email attachments

The intake limits and MIME rules your policy reads.

Your Tenant Compliance Posture

The control map this tenant-owned intake control sits under.

Settings → Media

Work quarantined uploads under Settings → Media.