Summary

This branch makes the message database pluggable across engines, adds a blob store for message bodies, brings the SMTP client and server up to current protocol and transport-security expectations, and moves the application to Ruby 4.0.7, Rails 8.1.3.1, Rack 3.2.7 and Puma 7.0.4.

The default installation is unchanged. The message database still defaults to MySQL/MariaDB, bodies are still stored in the database, and no transport-security feature activates without configuration. What an existing installation sees is new optional configuration, a small number of new tables, and the toolchain move.

Implementation

Message database

Engine-specific SQL is isolated behind a dialect, selected by message_db.adapter. MySQL/MariaDB is the default; PostgreSQL and SQLite are supported. The dialect contract covers connection handling, identifier quoting, value escaping, schema-qualified table operations, index and column management, and translation of the column types the message schema declares into each engine's vocabulary.

A message body is written across raw_tables rows instead of as a single statement, so a body exceeding max_allowed_packet — and the equivalent limits on other engines — is no longer a failure. Chunk iteration guards against cyclic next references, and empty IN () conditions render as 1=0 rather than a syntax error. Retention prunes the corresponding rows, terminates instead of looping when the table list is exhausted, and skips a raw_tables name that is not a date rather than aborting the run. The connection pool never checks a failed checkout back in, and a replacement connection obtained on retry is treated as an ordinary connection.

Blob store

Bodies at or above blob_store.threshold (default 1 MiB) can be held in a blob store instead of the message database: a filesystem tree, S3-compatible object storage, or FoundationDB. The store is addressed by URL (inline:// default, filesystem://, s3://, foundationdb://), and all three backends generate keys from one place. Filesystem keys are validated against the shared key pattern, so a tampered database value cannot escape the store directory. S3 object keys use / separators on all platforms.

Statistics and telemetry

Optional sinks accept the daily statistics: DuckDB, ClickHouse, and a time-series sink speaking the Prometheus text protocol (also accepted by VictoriaMetrics), InfluxDB line protocol, or line-delimited JSON for a vector.dev pipeline. Time-series samples carry both the server permalink and the server id, so servers in different organisations sharing a permalink do not merge. Optional live statistics can be held in a key-value store speaking the Redis protocol (Valkey, Redis, or another drop-in replacement) or Aerospike rather than in the message database; a non-default store outage is logged and delivery continues, while the default store still propagates failures because the store is the message database. Only a Prometheus-compatible store can additionally back the dashboard read-back and live streaming; the Influx and JSON schemes are write-only. Every one of these is optional and inert when unconfigured.

SMTP server

The advertised ESMTP extensions are derived from a single declaration rather than assembled per session, so what is announced and what is implemented cannot drift. The server has an explicit TLS version policy, and every unauthenticated entry point is rate limited. CRAM-MD5 challenges use a CSPRNG value and the response comparison is timing-safe. A PROXY line naming an unparsable address is rejected, and the unauthenticated credential lookup tolerates legacy rows without an address. The pre-newline read buffer is bounded so a client that never sends a newline cannot grow memory without bound.

SMTP client

Relay delivery supports authentication (PLAIN, LOGIN, CRAM-MD5) and refuses to send credentials when the relay advertises no mechanism. A message which a server has already refused via SIZE is not transmitted. The verified-TLS context pins the system certificate store, and the MTA-STS policy fetch does the same while refusing SSRF destinations through the shared address guard; hosts that do not resolve fall through to the existing fetch-failure handling.
Outbound delivery honours MTA-STS policies, and can be held to them strictly.

Domain transport security

For hosted domains:

• DKIM — key size (1024, 2048, 3072 or 4096; default 2048), rotation and change reminders are configurable.
• DMARC — the record is checked and displayed. It is not managed.
• MTA-STS — a policy is published and served, and the certificate for the policy host is obtained over ACME (Let's Encrypt directory by default).
  Key files are created with mode 0600 rather than chmodded after the fact.
• TLS-RPT — a reporting record is published for the domain, and submitted reports are ingested. The receiving address is configurable, the report is attributed to the domain it concerns, reports for domains that no longer exist are discarded, and each report contributes at most 100 policies with 100 failure details each.

Ingestion is keyed on the local part of the recipient (dns.tls_rpt_local_part, default tlsrpt). Setting it blank disables ingestion rather than accepting any address without a local part.

Security

The password reset form no longer reveals whether an account exists: a request for an unknown address is indistinguishable from one for a known address. Reset requests are throttled by address and period (protection.web_password_reset_limit / web_password_reset_period).
Rate-limit keys are bounded so that arbitrary input cannot grow the counter store without limit, and counters can be shared between workers via protection.counter_store. Session policy (sessions group) is declared explicitly rather than left to the library's defaults. OIDC account linking by email requires the provider's verified claim. The legacy API no longer echoes rejected keys. Domain verification codes use a CSPRNG value with timing-safe comparison, and invitation acceptance requires the invited address. The test message composer accepts only the fields its form submits. Trusted proxies are declared through action_dispatch.trusted_proxies, and the session secret flows through Rails' secret_key_base chain.

Toolchain

Ruby 4.0.7, Rails 8.1.3.1 (with load_defaults 8.1), Rack 3.2.7, Puma 7.0.4. Default and bundled gems used by the code (cgi, timeout, securerandom, base64, benchmark, logger, mutex_m, ostruct) are declared and required where used.

YJIT is compiled into the Ruby 4.0.7 runtime and needs no native toolchain at runtime, but ships disabled: the image sets RUBY_YJIT_ENABLE=0 via the YJIT build arg (default 0). Pass --build-arg YJIT=1 to enable it for the image, or -e RUBY_YJIT_ENABLE=1 at run time; only the value 1 enables it. spec/lib/ruby_runtime_spec.rb guards the invariant: YJIT support present, off unless explicitly enabled, stats exposed when on.

jemalloc 5.3.0-3 ships as a build variant, off by default: --build-arg JEMALLOC=1 installs the library, and -e JEMALLOC_PROFILE=balanced (or =aggressive) preloads it at container start. Only two profiles exist, deliberately — Ruby allocates many small short-lived objects across migrating Puma threads, so thread-local caching stays on and arenas stay at jemalloc's default; what varies is how fast unused pages return to the OS (10s/10s vs 1s/0s dirty/muzzy decay). The preload goes through /etc/ld.so.preload rather than LD_PRELOAD because the image's setcap-capped ruby binary ignores the latter (verified: mapped in /proc/self/maps only via the preload file). max_background_threads:1 is set explicitly because background_thread:true alone spawns zero threads and pages are never purged. abort_conf:true refuses to boot on a bad profile or a missing library rather than running misconfigured.
spec/lib/postal/jemalloc_spec.rb covers the profile mapping and the library lookup. Measured on a 200MB burst workload: churn ~20% faster than glibc, steady-state RSS higher (~95MB vs ~15MB retained pool, reused rather than regrown across bursts), aggressive back to baseline within seconds of sustained allocation pressure. Combines cleanly with YJIT.

Configuration and compatibility

New or changed configuration, all inert unless configured except where noted:

Compatibility points:

• PostgreSQL requires a role with access to every schema the message database uses. The message database creates a schema per server, so a role limited to one schema fails during migration.
• Toolchain requirements move to Ruby 4.0, Rails 8.1 and Rack 3. The container image is ruby:4.0.7-slim-trixie with Bundler 4. The json gem stays pinned below 3 because Active Support 8.1 still passes quirks_mode.

Database and storage changes

Main database, all for transport security (one migration):

• tls_reports — a submitted report, one row per report.
• tls_report_results — the per-failure detail of a report.
• acme_challenges — the challenge records used for certificate issuance.
• domains gains DKIM rotation, DMARC status, MTA-STS policy and certificate, and TLS-RPT status columns.

The message database gains the raw_table and raw_headers_id columns on messages, the raw_tables relation holding the body rows, and a blob column on raw tables referencing the blob store.

Two corrections to the existing migrations, both needed for a fresh installation:

• Seven migrations predating versioned migrations inherited from ActiveRecord::Migration without a version, which Rails 8.1 refuses to run.
  One of them is the initial schema, so a new installation could not be migrated at all.
• Nine datetime columns were declared without the precision the migrations produce, so the schema the application loaded differed from the schema a migration produced. They are now declared precision: 6.

The schema version and collation are unchanged. The transport-security schema is carried by the single migration that describes it.

Testing

• bundle exec rspec — 1563 examples, 1 failure, 22 pending.
• bundle exec rubocop — 395 files, 20 offences, all pre-existing and autocorrectable.
• The message-database suite passes against MySQL/MariaDB, PostgreSQL and SQLite.
• The optional image target, which carries the optional backends, builds.
• The web interface was booted, not only tested: Rails 8.1.3 on Rack 3 serves the login page, and boot resolves the trusted-proxy list and the session secret through Rails' own configuration chain.

The failure and the pending specs are both environmental; both are described under Known limitations. Coverage added with this work includes the schema equivalence between a migrated database and the loaded schema, the columns the SQLite dialect must normalise as booleans, credential decoding in the S3 and ClickHouse backends, escaping in the dialect queries, the OIDC verified-email requirement, and the non-echo of rejected API keys.

Known limitations

• FoundationDB is unverified at runtime. The backend is implemented and covered by a spec, but that spec has never executed against a cluster. The client library must also be reachable from the process, which the current image does not arrange.
• SQLite engine attribution was not independently observed. The suite reported 95 examples passing against it, but the engine was selected by environment variable rather than confirmed at runtime.
• ACME issuance has not run against a live certificate authority. It is verified against a stubbed directory; a live run requires a public hostname resolving to the installation.
• The one failing spec resolves an external name over live DNS and fails wherever that name is not resolvable as expected.
• The 22 pending specs are optional-group examples skipping because their services are not running, plus the YJIT stats example skipping when YJIT is off (its default) and the jemalloc library example skipping when the library is not installed.