feat(email): native SMTP-listener ingress (A3)
An opt-in receive-only SMTP listener (PICLOUD_SMTP_BIND) so an MX can point straight at PiCloud. It speaks minimal SMTP (HELO/EHLO/MAIL/RCPT/DATA/RSET/ NOOP/QUIT), resolves each RCPT TO mailbox to the app-owned email trigger that claims it, and inserts an Email outbox row the dispatcher fires — the same tail as the HMAC webhook, unchanged. - migration 0076: email_trigger_details.inbound_address (case-insensitively unique among app triggers) + TriggerRepo::email_inbound_target_by_address / SmtpInboundTarget; the interactive create-email API accepts inbound_address. - crates/picloud/src/smtp.rs: a small tokio accept loop + session state machine + a testable deliver() core + a minimal RFC-5322 header/body split. DATA is size-capped with dot-unstuffing; no AUTH/STARTTLS (TLS terminates upstream — the recipient address + per-app isolation are the boundary). - spawned in run_server alongside axum::serve, sharing the pool, on the same shutdown signal. Pinned by a picloud integration test (deliver → one Email outbox row for a known mailbox, none for an unknown one) + smtp.rs unit tests (address parse, header/body split). Multipart/MIME decoding is a documented follow-up. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -134,6 +134,7 @@ Environment variables consumed by the `picloud` binary:
|
||||
| `PICLOUD_DB_MAX_CONNECTIONS` | `32` | Postgres pool size. Matched to `PICLOUD_MAX_CONCURRENT_EXECUTIONS` so the data plane can't starve background workers. |
|
||||
| `PICLOUD_SESSION_TTL_HOURS` | `24` | Sliding-window admin session lifetime (idle timeout). |
|
||||
| `PICLOUD_SESSION_ABSOLUTE_TTL_HOURS` | `720` (30 days) | Absolute hard cap on an admin session's lifetime (audit 2026-07-11 C1). The sliding `touch` bump is clamped at `login_time + this`, so even a continuously-used or stolen-but-warm admin token self-expires. Mirrors the data-plane app-user session cap. |
|
||||
| `PICLOUD_SMTP_BIND` | — (off) | A3 native SMTP ingress. When set (e.g. `0.0.0.0:2525`), a receive-only SMTP listener binds alongside the HTTP server: it resolves each `RCPT TO` mailbox to the app-owned email trigger that claims it (`email_trigger_details.inbound_address`, unique) and writes an `Email` outbox row the dispatcher fires — same tail as the HMAC webhook. **No AUTH/STARTTLS at the listener** (TLS terminates upstream — Caddy/relay); the recipient address + per-app isolation are the boundary. `DATA` is size-capped. Unset = the webhook path only. Distinct from the outbound relay `PICLOUD_SMTP_*` vars (`SmtpConfig`). |
|
||||
| `PICLOUD_INTERCEPTOR_TIMEOUT_MS` | `5000` (5s) | §9.4 M5 default per-interceptor wall-clock timeout when a `[[interceptors]]` marker sets no `timeout_ms`. Bounds ONE hook run so a runaway guard (`loop {}`) is denied (fail closed) rather than hanging the guarded write. The effective deadline is always tightened to at most the caller's remaining budget — a hook can never EXTEND its caller's deadline. |
|
||||
| `PICLOUD_OUTBOX_CLAIM_TIMEOUT_SEC` | `600` (10 min) | How long a dispatcher may hold an OUTBOX claim before the reclaim task returns the row to the queue. **Without this a crash or restart mid-dispatch stranded every in-flight row permanently** — the dispatcher claims a row and only clears the claim on success (delete) or failure (reschedule), and `claim_due` selects `claimed_at IS NULL`, so a process that died in between left rows nothing would ever pick up again. Every other claim-based store (queue, group queue, workflow steps) already had a reclaimer; the outbox was the gap, and since it is the universal trigger path, the loss covered kv/docs/files/cron/pubsub/email/`invoke_async`/dead-letter alike. The default is deliberately generous: a script may run 300s, so a claim older than twice that is abandoned rather than slow. A reclaim does **not** bump `attempt_count` (the handler never ran — same reasoning as the transient queue `release`). Runs on the existing `PICLOUD_QUEUE_RECLAIM_INTERVAL_MS` ticker. |
|
||||
| `PICLOUD_REALTIME_BROADCAST_CAPACITY` | `64` | Per-channel SSE broadcast buffer depth (a slow consumer sees oldest events dropped). |
|
||||
@@ -156,6 +157,6 @@ Environment variables consumed by the `picloud` binary:
|
||||
|
||||
## Out of MVP
|
||||
|
||||
This section captured the original MVP cut. Most of it has since **shipped in v1.1.x**: queue triggers, cron triggers, inbound email (`email:receive`, HMAC-webhook model), KV / docs / email / users / HTTP SDKs, function-to-function `invoke()`, and secrets are all live (blueprint §12 Phase 4 table). The **Workflows** track (DAG + nested workflows) has since **shipped** (migrations `0071`/`0072`). The **§9.4 service-interceptor** track has since shipped in full (migrations `0073`–`0075`; before/after phases, data-transform, all six services, per-interceptor timeout, resolve cache, `pic interceptors ls`). A read-only **metrics/observability dashboard** has since shipped (A2): `GET /api/v1/admin/apps/{id}/metrics?window=` aggregates the existing `execution_logs` table (counts, error rate, latency avg/p50/p95, an hourly series) via `ExecutionLogRepository::summarize_for_app` + `metrics_api`, surfaced as the dashboard's per-app **Metrics** tab — no hot-path instrumentation. **Still deferred:** a raw SMTP-listener ingress, and **multi-node cluster mode**. Don't pre-build for them — but don't make decisions that close the door on them either.
|
||||
This section captured the original MVP cut. Most of it has since **shipped in v1.1.x**: queue triggers, cron triggers, inbound email (`email:receive`, HMAC-webhook model), KV / docs / email / users / HTTP SDKs, function-to-function `invoke()`, and secrets are all live (blueprint §12 Phase 4 table). The **Workflows** track (DAG + nested workflows) has since **shipped** (migrations `0071`/`0072`). The **§9.4 service-interceptor** track has since shipped in full (migrations `0073`–`0075`; before/after phases, data-transform, all six services, per-interceptor timeout, resolve cache, `pic interceptors ls`). A read-only **metrics/observability dashboard** has since shipped (A2): `GET /api/v1/admin/apps/{id}/metrics?window=` aggregates the existing `execution_logs` table (counts, error rate, latency avg/p50/p95, an hourly series) via `ExecutionLogRepository::summarize_for_app` + `metrics_api`, surfaced as the dashboard's per-app **Metrics** tab — no hot-path instrumentation. **Still deferred:** **multi-node cluster mode**. Don't pre-build for them — but don't make decisions that close the door on them either.
|
||||
|
||||
**Pulled forward to Phase 3 (pre-v1.1):** admin auth, multi-app scoping. The general cross-app **export/import** sharing model stays at v1.3+; note that v1.2 §11.6 shipped a narrower form — **group-owned shared collections** (KV/docs/files/topics/queues) let apps in one subtree share data through the owning group, with the ancestor-chain walk as the isolation boundary. See blueprint §11.5 + design-doc §11.6.
|
||||
|
||||
Reference in New Issue
Block a user