Files

T

Karti TripathiandClaude Opus 5 f0ec4ad691 Add ROADMAP; settle ADR 0005 with a measured OCI port test

cloud-1 (phx) and cloud-2 (us-sanjose-1) are both already OCI aarch64
instances, so the open question in ADR 0005 was answerable directly rather
than by reading forum posts. Measured from cloud-2:

  BLOCKED  25    gmail-smtp-in.l.google.com, aspmx.l.google.com
  OPEN     587/465/2525  gmail, sendgrid, SES, OCI Email Delivery

The community reports claiming 587 and 2525 are also blocked are wrong.
Only 25 is blocked, exactly as Oracle documents, so relay works and the
launch host is viable. Inbound :25 reachability is still unverified — that
is a VCN security-list change, not a platform limit.

ROADMAP.md carries the goal, three success signals that are deliberately
not v0.1, a definition-of-ready checklist, and five standing rules.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JkyvfNJGTshJNE9FtwPLk7

2026-09-02 13:38:01 -07:00

2.6 KiB

Raw Permalink Blame History

ADR 0005 — Oracle Cloud as the launch host, and what it forbids

Status: Accepted, 2026-09-02.

The constraint

OCI blocks outbound TCP/25 for every tenancy created after 2021-06-23. Exemption is a service-limit request, routinely refused for free tier. Inbound :25 is not blocked.

	On OCI
Receive on :25	✅ works — `openmail-smtpd` is fine
Relay out on 587	✅ works (verify: see below)
Direct-to-MX	❌ impossible. `mail-dane` and `mail-mta-sts` can never run there

Decision

Launch on OCI in split delivery: receive directly, relay outbound. Support Oracle Cloud Email Delivery and SES as relay providers from day one — two providers at launch forces the provider abstraction to be genuinely data-driven instead of an SES-shaped if.

Direct-to-MX (v0.4) is developed and tested on a host without the block.

Consequences

Embedded inbound moves from "milestone 4, later" to required at launch.
The relay path is not a temporary on-ramp; on our own launch host it is the only outbound path that exists.
Oracle's SPF include is region-scoped (rp / eu.rp / ap.rp .oracleemaildelivery.com), so providers.rs deliberately stores None and makes the operator paste theirs. A guessed include turns the DNS check green against a mechanism the provider does not honour and mail still fails SPF — silently. Same for Resend.

Measured, 2026-09-02 — the block is port 25 only

Community reports claimed 587 and 2525 were also blocked, which would have made OCI unable to relay and changed the host choice entirely. Tested directly from our own OCI instance (cloud-2, us-sanjose-1, aarch64):

BLOCKED  25    gmail-smtp-in.l.google.com
BLOCKED  25    aspmx.l.google.com
OPEN     587   smtp.gmail.com
OPEN     465   smtp.gmail.com
OPEN     587   smtp.sendgrid.net
OPEN     2525  smtp.sendgrid.net
OPEN     587   email-smtp.us-east-1.amazonaws.com
OPEN     587   smtp.email.us-sanjose-1.oci.oraclecloud.com

The reports are wrong. Only 25 is blocked, exactly as Oracle documents. Submission ports are open, including both relay providers we ship. The host is viable and this ADR stands.

Note that cloud-1 (phx) and cloud-2 (us-sanjose-1) are both already OCI aarch64 instances — the same shape as the launch target, and the same architecture spark-1 builds for.

Still unverified

Inbound :25 reachability has not been tested end-to-end. Oracle blocks outbound only, but the VCN security list and the instance firewall must still be opened before mail can arrive. That is a configuration change, not a platform limit.

2.6 KiB Raw Permalink Blame History