Rapid Inbox

Rapid Inbox is built for open-source maintainers, developers, and test teams that need a self-hosted email testing environment for receiving verification codes, CI/E2E email capture, internal-tool integration, and lightweight self-hosting.

Its core goals are reliable ingestion, clear inspection, controlled access, and straightforward recovery. Message bodies, attachments, and indexes are stored on local disk and in SQLite by default, without depending on a third-party email SaaS or cloud database. Receiving mail from the public Internet still requires your own domain, DNS/MX records, and a reachable SMTP ingress.

The project is currently at an early Alpha stage. Interfaces and data structures may continue to change.

In short: Rapid Inbox is an alpha-stage, inbound-only, self-hosted SMTP inbox for email testing, verification-code workflows, and internal integrations. It uses a single-host SQLite/local-filesystem architecture and is not an outbound mail server, hosted mailbox service, or multi-node mail platform.

See Roadmap Issue #5 for the current plan and capabilities that are explicitly out of scope for now.

The demo uses sanitized test data in an isolated environment and contains no real mailboxes, messages, or credentials. It was recorded with Python's embedded SMTP server. Current deployments persist committed public-mailbox delivery changes in a SQLite live-event outbox and tail them from the Python HTTP process, so the default C++ ingestd and standalone Python SMTP modes can update an open public inbox over WebSocket without a manual refresh. The administration console also uses an authenticated WebSocket: Python SMTP can publish process-local connection/command telemetry, while C++ and separate ingress surface committed deliveries as delivery_committed events through the SQLite outbox. Cursor-based reconnects can fall back to committed history.

Docker Compose · C++20 · Python 3.10+ · FastAPI · aiosmtpd · Jinja2 · SQLite · Uvicorn · WebSocket

Docker Compose is the recommended deployment method. From a reviewed checkout, with Docker Engine and Compose v2 installed, run:

./docker-deploy.sh

This one command builds the image, creates a mode-0600 private configuration with random bootstrap, cursor-signing, and metrics secrets, starts the Python control plane, waits for schema migration and /health/ready, then starts the C++ SMTP ingress. The image runs as a non-root user. Both processes are supervised in one container and one PID namespace because the cross-process maintenance protocol records and verifies operating-system PIDs. A SQLite live-event outbox carries committed public-mailbox delivery notifications across this process boundary. Public and administration WebSocket cursor generations remain local to one HTTP process, so keep one HTTP worker per instance (as the supplied runners do); a multi-worker or multi-replica HTTP tier requires sticky routing until cursor generations are shared.

Default host bindings:

HTTP: 127.0.0.1:8000
SMTP: 0.0.0.0:25

The first successful deployment prints the initial administrator password once. Open:

http://127.0.0.1:8000/admin/login

After the first bootstrap administrator login, the admin console forces a change of the initial password. The generated value remains in .rapid-inbox-docker/rapid-inbox.env; protect this file as a secret and replace the password in the administration UI immediately.

Mail, SQLite, manifests, and attachments are persisted in the Compose named volume rapid-inbox_rapid-inbox-data by default. The deployment script never removes this volume. Use the wrapper for lifecycle operations:

./docker-deploy.sh status
./docker-deploy.sh logs
./docker-deploy.sh credentials
./docker-deploy.sh update   # rebuild the current checkout with fresh base images
./docker-deploy.sh down     # retain configuration and the named data volume

Edit .rapid-inbox-docker/rapid-inbox.env to change published addresses, ports, or application settings, then run ./docker-deploy.sh again. For reproducible updates, check out a reviewed tag or commit first; update does not fetch source code.

See the Docker deployment guide for backup, restore, rollback, port, and troubleshooting procedures.

For Debian 12+ or Ubuntu 24.04+ hosts that require native services instead of Docker:

sudo bash deploy/system/install.sh install

The installer creates a dedicated rapid-inbox account, installs dependencies, stages a versioned release under /opt/rapid-inbox, generates /etc/rapid-inbox/rapid-inbox.env, keeps data under /var/lib/rapid-inbox, initializes and backs up SQLite at the write boundary, installs hardened HTTP/SMTP units, and verifies HTTP plus SMTP protocol readiness.

sudo bash deploy/system/install.sh status
sudo bash deploy/system/install.sh update
sudo bash deploy/system/install.sh uninstall  # preserves configuration and data

See the native systemd deployment guide for the exact support boundary, managed paths, update rollback, and uninstall behavior.

quickstart.sh is retained for local evaluation and development. It is a foreground launcher, not a long-running production process manager:

bash quickstart.sh

It creates .venv and .env, initializes SQLite, and runs Python HTTP with C++ ingestd. By default, it downloads the mutable latest ingestd release after SHA-256 verification; pin a reviewed release with --ingestd-version, or build the current checkout with --build-local. Run bash quickstart.sh --help for all options, including the Python SMTP compatibility mode.

# 1. Build the C++ SMTP ingress
cmake -S cpp/ingestd -B cpp/ingestd/build
cmake --build cpp/ingestd/build

# 2. Start Python HTTP without embedded SMTP
.venv/bin/uvicorn app.main:app --host 127.0.0.1 --port 8000

# 3. Start the C++ SMTP ingress
SMTP_HOST=0.0.0.0 SMTP_PORT=25 cpp/ingestd/build/rapid-inbox-ingestd --base-dir .

.venv/bin/rapid-inbox-http

.venv/bin/rapid-inbox-smtp

.venv/bin/uvicorn app.main:app --reload

The repository includes the GitHub Actions workflow .github/workflows/release-ingestd.yml:

• Regular pushes and pull requests run Python tests, validate both deployment paths, execute a real one-command Docker smoke deployment, and build/test C++ ingestd.
• Pushing a v* tag builds a Linux x86_64 release archive and publishes these files to a GitHub Release:
  • rapid-inbox-ingestd-linux-x86_64.tar.gz
  • rapid-inbox-ingestd-linux-x86_64.tar.gz.sha256

Example release commands:

git tag "$NEW_RELEASE_TAG"
git push origin "$NEW_RELEASE_TAG"

The publisher should set NEW_RELEASE_TAG explicitly according to the actual versioning policy. Published versions are listed under GitHub Releases.

The Docker path builds a local image from the reviewed checkout; this workflow does not currently publish a container image. After a Release is published, local-development bash quickstart.sh downloads prebuilt ingestd from the mutable latest release by default and prints a drift warning. Reproducible deployments should explicitly pass a reviewed tag; use --build-local when a local build is required.

The application resolves variables in this order:

Process environment  >  .env in the current working directory  >  defaults in app/config.py

Docker passes .rapid-inbox-docker/rapid-inbox.env as process environment; systemd uses /etc/rapid-inbox/rapid-inbox.env. The repository .env.example is the local-source template.

1. Start the service and sign in at /admin/login.
2. Select an ingestion mode: add one or more managed domains, or enable catch-all mode in system settings.
3. Explicitly enable Web or API access for domains/catch-all policy that truly need public inspection; keep the defaults private.
4. Deliver a test message to any matching mailbox, for example code@example.com.
5. Inspect private mail in the admin console, or use an authorized public page/API.
6. Issue automation clients an API Key with the minimum scope and minimum domain grant.

• managed_only: accept only domains enabled in the database and matched by exact/subdomain rules.
• managed_plus_catchall: managed domains still use longest-suffix-first matching; other valid domains fall through to the system's * policy. Domains do not need to be pre-registered individually for deliveries that have already reached this SMTP service.
• Catch-all mode does not change public DNS routing and cannot receive third-party mail whose MX does not point to this service. Receiving mail from the public Internet still requires an A/MX record for a domain you control and reachable TCP port 25; for testing, an upstream relay may deliver directly to this host.
• Public Web/API switches are disabled by default for new managed domains and the * policy. A new mailbox's public_enabled flag defaults to enabled, but is a second-level gate under the domain switch; after a domain is explicitly made public, each mailbox can still be disabled. SMTP acceptance does not imply anonymous read access; authorized administrators or service Keys can always read private mail.
• When one message is delivered to multiple recipients, recipients are de-duplicated by canonical mailbox. Shared message/raw/attachment files enter final cleanup only after every delivery expires.
• Creating a more specific managed suffix or changing plus/case canonicalization creates a persistent domain_rehome_jobs record for existing catch-all/parent-domain mailboxes in the same write transaction. The worker processes at most 1,000 mailboxes per batch and commits independently, allowing SMTP writers to take priority between batches. Jobs resume from a cursor after cancellation, process exit, or a transient failure. Migration only moves mail one way into a more-specific managed rule, merges duplicate deliveries, and recalculates summaries; a managed mailbox never falls back to * because a rule was disabled.

GET  /
GET  /mail/{mailbox_address}
GET  /mail/{mailbox_address}/{delivery_id}
GET  /mail/{mailbox_address}/{delivery_id}/raw
GET  /mail/{mailbox_address}/{delivery_id}/attachments/{attachment_id}

curl \
  -H "X-API-Key: <your-public-api-key>" \
  "http://127.0.0.1:8000/api/v1/public/mailboxes/code@example.com/messages"

The endpoint supports limit, the legacy-compatible offset, and returns next_cursor. New integrations should use next_cursor for pagination:

curl \
  -H "X-API-Key: <your-public-api-key>" \
  "http://127.0.0.1:8000/api/v1/public/mailboxes/code@example.com/messages?limit=20&cursor=<next_cursor>"

New integrations can also use the v2 public-mailbox resource directly. A public Key uses Bearer authentication and remains constrained by domain grant mode, mailbox glob, and domain/mailbox public API switches:

curl \
  -H "Authorization: Bearer <ri_public_...>" \
  "http://127.0.0.1:8000/api/v2/public/mailboxes/code@example.com/messages?limit=20"

/api/v2 accepts admin, service, and public Keys, but only standard Bearer headers. Credentials in query parameters or X-API-Key are rejected. A public Key may call only /me and public mailbox resources allowed by public.read; service and admin Keys are further narrowed by kind, scope, domain, and mailbox authorization. JSON responses use strict envelopes, file downloads use their corresponding media types, and errors use application/problem+json. List cursors are bound to the resource and filters and signed with API_CURSOR_SECRET; rotating that secret immediately invalidates old cursors. OpenAPI is available at /docs and /openapi.json.

curl \
  -H "Authorization: Bearer <ri_service_...>" \
  "http://127.0.0.1:8000/api/v2/messages?limit=50"

The current v2 surface covers principal, public mailbox list/verification-code/detail/raw/attachment resources, domain and DNS checks, mailbox operations, message detail/raw/attachment/reparse/delete, SMTP sessions and events, audit, dashboard, manual cleanup/clear, system settings, and the full API-Key and admin lifecycle. The admin live WebSocket (plus its deprecated SSE compatibility route) and cross-message bulk deletion remain under /api/v1/*. New code should prefer resources covered by v2 and follow the operations actually present in OpenAPI.

Every v2 cursor has a 2,048-byte input limit, an HMAC signature, and resource/filter binding. Retained v1 public-mailbox cursors are also bound to the calling credential and mailbox. v1 domain lists and SMTP events use hard pagination, and bulk deletion accepts at most 1,000 delivery IDs per request. v2 API-Key listing scans at most 5,000 candidates per request; when a low-privilege principal filters out many old Keys, it returns a continuation cursor instead of scanning without bound to fill a page.

Admin sessions have three roles:

• viewer: read runtime status, domains, mailboxes, messages, SMTP, audit, settings, Key metadata, and administrator metadata.
• operator: all viewer permissions plus write access for domain, mailbox, and message handling.
• superadmin: high-risk system settings, API Keys, administrators, password resets, and session revocation; the system prevents deleting or demoting the last enabled superadmin.

API Keys first constrain selectable scopes by kind: public may use only public.read, service is for business resources, and only admin may hold Key/administrator/system-write scopes. Domain grants must be explicit:

• none: grants no domains;
• selected: grants only listed domain IDs; an empty list still denies access;
• all: grants all current and future domains.

Mailbox globs, allowed IP CIDRs, Header/Query transport modes, per-minute limits, expiry, and revocation further narrow permissions. An empty domain list on a new Key no longer implicitly means all domains. Key creation, update, rotation, revocation, and deletion re-read caller and target permissions in the same SQLite writer transaction, preventing authorization races caused by policy changes while a request waits in the queue.

Administrator delegation is re-authorized in the write transaction as well: creating a login-capable account requires both admins.write and admins.credentials.write; password reset and session revocation require admins.credentials.write and admins.sessions.write respectively, and the target role's effective scope may not exceed the caller's own scope.

Domain, mailbox, and message endpoints filter resources by selected grants. Global resources such as dashboard/live status, SMTP sessions, audit, system settings, maintenance, and administrators cannot be safely partitioned by domain, so their v1/v2 endpoints require domain_grant_mode=all; v2 API-Key lifecycle operations also require all-domain authorization. A restricted v1 Key manager can operate only on Keys within the caller's scope and domain grants.

A selected-domain principal may update ordinary policy for an authorized domain, but changing the domain identifier root_domain changes the authorization boundary and is therefore limited to a principal with domain_grant_mode=all. The service layer confirms this condition again in the same write transaction.

• /health/live is the process liveness probe; /health/ready checks runtime state, background tasks, SQLite, the storage directory, and minimum free disk; /version reports the application version, recommended API v2, and the list of supported v1/v2 APIs.
• /metrics exposes Prometheus text metrics including route-aggregated request counts/latency, in-flight requests, background tasks, readiness, process CPU/memory, and uptime. With METRICS_TOKEN, use Bearer or X-Metrics-Token; when METRICS_ENABLED is disabled, the endpoint returns 404. A non-loopback bind with metrics enabled and no token refuses startup; loopback development is the only mode that permits tokenless access.
• HTTP responses carry a safe X-Request-ID. Access logs record route templates but not query strings, preventing compatibility Query Keys from leaking into logs. LOG_FORMAT=json suits collectors and text suits local troubleshooting. Formatting and output run on a separate thread with capacity 4,096, so a slow log sink does not block the event loop; queue-full, output-failure, and close-timeout drops are counted by rapid_inbox_log_records_dropped_total with fixed reasons.
• The /admin dashboard gathers database/disk state asynchronously through a short-TTL shared snapshot and displays RPS, P95, receipt/delivery/rejection/parse-failure counts, SMTP, parse queues, DB/WAL, disk, background jobs, and recent cleanup. Domain/mailbox/message/Key/audit totals are maintained by transaction triggers in one counter row; traffic uses minute buckets, so a 24-hour query reads at most about 1,441 buckets rather than scanning linearly with that day's message count.

Rapid Inbox is designed for a single-host local-disk architecture. It is not an unlimited horizontal scaling promise or an unmeasured throughput guarantee:

• SQLite uses WAL for concurrent reads, but still has one write transaction at a time. Ingestd can parse and write files in parallel; SQLite group commits are serialized briefly by a mutex, and Python changes are serialized by the DatabaseWriter write lock.
• /api/v2 uses Runtime-private persistent read-only actors with mode=ro/query_only connections. Admission, waiting, and deadlines are bounded, and maintenance drains and closes them first. A single actor is a conservative default; benchmark the actual workload before adding connections, because blindly adding threads can amplify Python row-materialization GIL/futex contention. Write connections explicitly use synchronous=FULL.
• The /api/v2 SQLite hot path is offloaded to dedicated actors and raw/attachment responses remain streamed. The dashboard uses a roughly 1.5-second shared cache and a stampede-prevention lock. New high-concurrency integrations should prefer v2; retained v1 routes remain compatibility surface. These optimizations do not remove disk IOPS or the SQLite single-writer ceiling.
• API-Key authentication uses a bounded approximately two-second in-process cache. Cache hits do not switch to the default thread pool; misses perform an asynchronous database read. Key changes in this process actively invalidate the cache after commit; selected-domain authorization is not cached to preserve FK-level fail-closed behavior. last_used_at is written at most about every 30 seconds, so it is an operations signal rather than a per-request audit trail.
• API-Key rate limiting uses a fixed-memory token bucket per Key. Bucket capacity equals the per-minute quota and refills evenly over 60 seconds, allowing short bursts up to the bucket capacity. State remains per HTTP process; with N workers, total available quota is roughly N times the per-process quota. Enforce a strict global quota at a reverse proxy/gateway.
• Run exactly one ingestd and one HTTP process for a data directory. Do not scale the Compose app service, deploy multiple Swarm/Kubernetes replicas, or point independently managed containers at the same volume. Do not place SQLite WAL on a network filesystem without reliable POSIX locking, and do not let multiple hosts share one app.db.
• C++ and Python SMTP currently do not implement or advertise STARTTLS. For encrypted public transport, terminate TLS at a verified SMTP proxy or expose the receipt port only to a trusted network; place the HTTP admin plane behind an HTTPS reverse proxy as well.

Before tuning workers, batches, queues, fsync, or HTTP concurrency, use the repository stress scripts on the actual disk to measure throughput, P95/P99, WAL growth, 451 ratios, recovery time, and power-loss requirements, and reserve explicit limits for queues and disk.

Rapid Inbox stores structured data in SQLite and splits message content across local directories:

storage/
├── app.db           # SQLite indexes and metadata
├── raw/             # Raw EML
├── text/            # Parsed plain text
├── html/            # Parsed HTML
├── attachments/     # Attachments
├── manifests/       # Manifests used for startup recovery
├── quarantine/      # Tasks and manifests that could not be persisted/verified
└── tmp/             # Temporary files

Mail no longer uses a global hard-coded "10-minute" retention period. Managed domains set each delivery's expires_at through retention_days; when unset, deliveries do not expire automatically. Catch-all delivery uses CATCH_ALL_RETENTION_DAYS, whose default 0 likewise means no automatic expiry. Domain-policy changes affect only newly created deliveries and do not rewrite historical expiry times.

Cleanup removes expired deliveries in CLEANUP_BATCH_SIZE batches. Message metadata is removed only after every delivery for that message has expired. The same database transaction registers raw, body, manifest, and attachment paths in file_gc_tasks; actual files are deleted outside the transaction, with the failure reason recorded and retries using exponential backoff. This avoids silently leaving half-applied state between a database commit and filesystem failure. SMTP sessions, empty mailboxes, metric buckets, and audit records have independent retention settings.

Each cleanup run also removes quarantine files older than QUARANTINE_RETENTION_DAYS and incrementally scans, up to ARTIFACT_SWEEP_BATCH_SIZE, for raw/text/HTML/attachment artifacts with no database, manifest, quarantine, file-GC, or in-flight ingestion reference. A scan pass resumes across runs from its previous position. A file must be at least ORPHAN_ARTIFACT_GRACE_SECONDS old to qualify, reducing races with files being persisted or recovered. Completed maintenance records are removed in batches according to MAINTENANCE_RUN_RETENTION_DAYS.

The Python parsing queue limits both message count and raw bytes, and the budget covers queued and active workers. Once raw data, manifests, and database state have been persisted, a temporarily full queue still preserves SMTP success. A background pending scan re-enqueues older messages first so already acknowledged mail is not discarded for memory backpressure.

An admin/API DELETE immediately marks the target delivery deleted and sets expires_at to the current time. The next cleanup run hard-deletes it; if the message has no other deliveries, metadata and files continue through the file-GC outbox. DELETE therefore takes immediate effect for read visibility, while disk reclamation is an asynchronous, retryable operation. Call POST /api/v2/maintenance/cleanup to accelerate processing.

Deleting all mail in a mailbox does not update all historical deliveries in one long transaction. In the final authorization transaction, the service freezes the mailbox's current deletion generation and maximum delivery rowid, advances the mailbox to the next generation, and creates a persistent mailbox_bulk_delete_jobs record. The worker processes at most 1,000 rows per batch and can resume after cancellation, failure, or restart. Deliveries that arrive or migrate after job creation inherit the new generation, so an old job cannot delete them even if retention deletes the highest rowid and SQLite reuses it. Job creation is the authorization linearization point: domain or mailbox grants revoked before it are rejected atomically; an authorized, persisted job completes within its original scope.

Only one C++ ingestd may use a given STORAGE_ROOT. On startup it holds a kernel file lock on .ingestd.instance.lock; normal exit and crashes release the lock automatically. The lock file is intentionally retained, and only the OS lock indicates ownership. The SQLite writer reuses one connection and prepared statements across batches. SQLite errors, database-file replacement, or a maintenance drained ACK invalidate the session so it can be rebuilt safely for the next batch.

Startup recovery checks manifest and raw-file size/SHA-256 and restores uncommitted domain policy, messages, deliveries, and parsed results. Full history, permanent-failure retries, and same-timestamp watermark paths are processed in batches through temporary on-disk SQLite, so core replay state does not grow linearly with total history. Each manifest and each decode/replay batch is limited to 16 MiB. A manifest with missing domain policy, corruption, or an over-budget payload fails closed into quarantine; it neither infers public access nor blocks recovery of other mail. "Clear all messages" in the admin console creates a cross-process .maintenance.lock, makes C++ ingestd temporarily return 421/451, stops parsing, clears mail tables, atomically moves raw/text/html/attachments/manifests/tmp, and compacts SQLite. Domains, administrators, API Keys, audit/maintenance records, and quarantine are retained for separate forensic disposal. An expired heartbeat is accepted only after its PID is confirmed to have exited; a live or unverifiable process must produce a matching drained ACK or time out.

Do not use mv, os.replace, or backup restoration to replace app.db while the service is running. A reader in one process can detect an inode change, but a Python writer, C++ ingestd, other HTTP processes, and -wal/-shm sidecars cannot atomically switch through a single connection pool. To restore a database, stop every HTTP/SMTP process, handle the main file and sidecars according to the SQLite backup procedure, run integrity checks, and then start the entire service again.

The current 0.x series evolves toward the new security model and does not promise legacy call semantics:

• New domains default to public_web_enabled=false and public_api_enabled=false; public access must be explicitly enabled.
• An empty API-Key domain list no longer means all domains. Existing Keys migrate to selected when grants exist, or fail-closed none; explicitly choose all when access to future domains is needed.
• API v2 uses Authorization: Bearer, strict fields, and cursors; it rejects Query Keys and does not guarantee compatibility with v1 response shapes. Internet-facing deployments must now provide a stable API_CURSOR_SECRET.
• Mail expiry is delivery-level expires_at; retention_days=NULL/0 means no automatic expiry and no longer inherits the old global 10-minute rule.
• C++ ingestd enables durable ACK by default. If an earlier deployment depended on the very low latency of "in-memory enqueue means 250," it can be disabled explicitly, with the risk of losing mail on an abnormal exit.

Before every upgrade, retain a restorable copy of configuration, mail artifacts, and SQLite. For Docker, stop the deployment, back up .rapid-inbox-docker/rapid-inbox.env and the named volume, check out the reviewed target commit, then run ./docker-deploy.sh; the wrapper starts SMTP only after HTTP migration and readiness succeed. For systemd, sudo bash deploy/system/install.sh update stages and builds first, then stops both writers, creates a consistent SQLite backup, migrates, switches the release, and performs HTTP/SMTP acceptance. Manual deployments must stop all old HTTP/SMTP processes and allow exactly one migrator before ingestd starts. Never let old and new binaries write the same database concurrently. Afterward, recheck domain public switches, Key domain_grant_mode, retention, Metrics Token, and fsync choices.

# Install
python3 -m venv .venv
.venv/bin/pip install -c constraints-dev.txt -e ".[dev]"

# Test C++ ingestd (build first so the cross-language integration test is not skipped)
cmake -S cpp/ingestd -B cpp/ingestd/build
cmake --build cpp/ingestd/build
ctest --test-dir cpp/ingestd/build --output-on-failure

# Python tests; when ingestd is built, these also run the cross-language integration tests
.venv/bin/pytest

# Selected test files
.venv/bin/pytest tests/test_admin_api.py tests/test_public_routes.py

Use the included scripts to deliver verification-code messages in bulk and sample CPU and memory for C++ ingestd / Python HTTP:

.venv/bin/python tools/smtp_stress_test.py \
  --to code@example.com \
  --count 5000 \
  --concurrency 100 \
  --json-output .rapid-inbox-run/smtp-stress.json

By default, the tool waits for and verifies SQLite persistence/parsing counts. Add --no-db-check to measure only SMTP ACKs. The HTTP tool permits only GET/HEAD. Pass its Bearer token through an environment variable to keep it out of shell history:

RAPID_INBOX_API_TOKEN='<ri_service_...>' \
  .venv/bin/python tools/http_stress_test.py \
  --url http://127.0.0.1:8000/api/v2/domains \
  --count 5000 \
  --concurrency 100 \
  --json-output .rapid-inbox-run/http-stress.json

Both report throughput, P50/P95/P99, and failures. See the actual script help for all parameters:

.venv/bin/python tools/smtp_stress_test.py --help
.venv/bin/python tools/http_stress_test.py --help

Runtime and development dependencies are pinned to exact versions in pyproject.toml, and constraints-dev.txt records one verified development dependency resolution. After pulling new code into an existing virtual environment, rerun the installation command so entry points and dependency versions match.

• Never use the default administrator password in a public environment. Prefer disabling compatibility tokens; if they are required, configure separate high-entropy values.
• Catch-all mode accepts deliveries that have reached this SMTP service and whose RCPT domain syntax is valid, but it does not replace DNS/MX configuration. Read access is private by default; do not enable public Web/API globally for convenience.
• When /metrics is enabled on a non-loopback bind, METRICS_TOKEN is mandatory or startup is refused; the metrics endpoint can also be disabled.
• API-Key token buckets are local to one HTTP process. Multi-process deployments must also enforce global rate limits at a trusted reverse proxy.
• Docker maps host port 25 to non-privileged container port 2525; the systemd unit grants only CAP_NET_BIND_SERVICE to its dedicated account. Manual deployments still need an equivalent privilege boundary.
• Public inboxes are intended for testing and temporary workflows, not sensitive long-term mail.
• Do not commit .env, storage/, databases, or persisted mail files to Git.

For security issues, read SECURITY.md first.

Issues, fixes, and improvements are welcome. The project is maintained by @wendaochangsheng. Read CONTRIBUTING.md before starting; it covers the development workflow, tests, and pull-request guidance.

Rapid Inbox is released under the MIT License.