Email and the inbox

Some vendors only notify by email. Each project has a private inbound address for them, and the inbox shows what arrived, who really sent it, and what the rules made of it.

The inbound address

Every project gets an address of the form <token>@dependency.observer, shown on its Settings page and returned by GET /v1/projects as inbound_address. Subscribe to a vendor’s notifications with it. You can rotate it at any time (POST /v1/projects/{id}/inbound/rotate); the old address stops routing at once.

Verified senders

The mail gateway’s authentication results (SPF, DKIM, DMARC) are read for every message. A message is verified when it authenticates and the authenticated domain belongs to a vendor the project depends on, to a sender you trusted with a sender rule, or to the platform itself. Verified mail may become an event of any priority and may alert immediately.

Unverified mail (not authenticated, or authenticated but from nobody the project knows) is still stored and shown, becomes an event capped at normal priority, and never alerts immediately. Only you can decide to trust the sender.

Quarantine

Unverified mail with a risk signal is held instead:

• a vendor’s name in the display name or subject from a domain that is not the vendor’s;
• a DMARC failure;
• content that reads like instructions to a person or an agent, or hidden text;
• an unknown sender using severe vocabulary (outage, breach, urgent) that would otherwise raise priority.

A quarantined message is visible under Inbox → Quarantine with its reasons, creates no event, and waits for you to release it (classify it once) or trust its sender (from now on). Through the API: POST …/inbox/{messageId}/release and …/trust.

Content warnings

Mail that contains instruction-like or hidden content carries a content_warning on the inbox row and provenance.warnings on any event derived from it, through the API and MCP. Agents are told to summarise such content and never act on it. Nothing in a message is ever executed, and links are never fetched, with one gated exception below.

Subscription confirmations

Many vendors answer a subscription with a “confirm” link. That mail becomes an action under Inbox → Action needed, with the link for a person to click. A project can opt in to letting the platform follow such links itself (confirm_subscription / POST …/actions/{actionId}/confirm), and then only when the mail was verified for the vendor’s own domain and every hop of the link stays on an allowed host. Unsubscribe links are never followed.

Sender rules

Teach the inbox about a sender or a whole domain:

The pattern is an address or @domain. The product proposes classify rules when you mark an email event as misclassified, and suppress rules from what you marked irrelevant; your agent can create them with your say-so.

Platform subscriptions

For many catalogued vendors the platform is subscribed to the vendor’s notifications once, through its own mailboxes, and fans the mail out to every project that depends on the vendor. GET /v1/catalog/vendors marks those with platform_subscription; you need not register anything for them. Those mailboxes and their mail are never visible to users; what you see is the event with its provenance.

Retention and size

• Mail over the size cap is refused. Attachments are not stored; only their names are kept.
• The raw message is kept in object storage for the project’s retention period (thirty days by default), then dropped. The extracted text (capped), a header subset, the links and the authentication results stay with the event.
• A project can switch raw retention off (retain_raw_mail: false) or delete its stored raw mail now from Settings.

See the security page for the whole picture of what is stored where.