Status: beta bridge implementation. SMTP ingress bridges into local AMP inboxes. Authenticated SMTP submission can deliver to external MX hosts when the outbound configuration below is explicitly enabled.
Inbound SMTP paths
| Listener | Default port | Authentication | Intended use |
|---|---|---|---|
| Submission | 2525 | AUTH PLAIN after STARTTLS when TLS material loads | Authenticated applications and local MTAs |
| MX ingress | 2526 | None | Server-to-server delivery for configured relay domains |
MX ingress checks access_map and relay_domains. At startup the configured
AFTERSMTP_DOMAIN plus comma-separated AFTERSMTP_RELAY_DOMAINS are inserted into
the allowlist only if they have no existing rule; all other domains are rejected.
The same set is treated as local by the delivery pipeline. Submission accepts configured username/password
credentials. Neither listener should be exposed as production mail
infrastructure without hardening its TLS startup behavior, credential storage, and
operational monitoring.
The code currently logs a warning and continues without STARTTLS if the certificate or key cannot be loaded. Treat that as a pre-alpha limitation, not a secure fallback.
What the on-ramp does
At DATA, the bridge:
- converts each accepted recipient address to a DID;
- resolves that DID in the ledger;
- parses the legacy MIME body into an AMP payload;
- encrypts it for the recipient's X25519 key;
- signs the AMP envelope with the gateway key; and
- applies trust admission before creating a best-effort receipt and storing it.
The bridge records the envelope sender and DKIM verification result in PreviousHop.
It must not be treated as proof that the external sender owns a DID. In observe mode,
SMTP admission uses the connecting peer IP as an abuse-control key.
Retries are idempotent per recipient: the bridge derives a deterministic message ID and the inbox discards a duplicate recipient/message-ID pair.
Authenticated outbound SMTP
Outbound delivery is intentionally a separate path from native AMP: AMP payloads are
encrypted to their recipients and the gateway does not possess arbitrary recipient
private keys. Instead, a TLS-authenticated SMTP client may submit raw MIME for an
external recipient. The gateway permits it only when both MAIL FROM and the visible
From header belong to a configured hosted domain, DKIM-signs the message, requires
STARTTLS at the destination MX, and uses normal certificate validation. Unauthenticated
MX ingress cannot use this path.
Enable it only after publishing the DKIM selector record for every hosted domain:
AFTERSMTP_LEGACY_OUTBOUND_ENABLED=true
AFTERSMTP_EHLO_HOSTNAME=smtp.gomeow.media
AFTERSMTP_DKIM_SELECTOR=smtp
AFTERSMTP_DKIM_PRIVATE_KEY_PATH=/run/secrets/aftersmtp-dkim.pem
The configured DKIM key is used to sign each hosted domain, so the corresponding
smtp._domainkey public key record must exist for every domain. Outbound retries are
not durable yet; a transient external delivery failure returns SMTP 451. Do not
market it as a general-purpose public relay.
Postfix pilot configuration
For a controlled pilot, place AfterSMTP behind a TLS-terminating internal edge and configure Postfix as an authenticated submission client. Port, hostname, and credential values must match your gateway configuration.
# /etc/postfix/main.cf
relayhost = [aftersmtp.internal.example]:2525
smtp_tls_security_level = encrypt
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
Before accepting internet MX traffic, set AFTERSMTP_DOMAIN and
AFTERSMTP_RELAY_DOMAINS for every hosted domain, test STARTTLS failure behavior,
and verify that the receiving DID exists in the ledger.