Release identity
SHA-256 of the pack file bytes: 19394cd84b978167b5e44487d8001c4075213f67c626e45acc4a295f6417d4f7
Distributable: digest matches the release manifest. The binary carries a digest-bound manifest of the distributable library; a pack whose bytes differ from its manifest entry — endpoint, tier, allowlist, or credential edited, with provider, version, and review block preserved — fails the digest check, loses distributability, and renders MODIFIED rather than as the shipped reviewed artifact. Review state and artifact status are different facts: the first is a documentation-review declaration, the second is the identity of the exact bytes.
Capabilities (1)
smtp.mail.send v1.0.0R3
- Action
- send
- Endpoint
send smtp://SMTP_HOST:587- Connector
- Custody
- customer_vault
- Credential ref
secret-ref-smtp-relay-credential- Data class
- pii
Send one message through the relay as its configured identity. A delivered message cannot be unsent, and send is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer), which is why it carries the R3 floor. SMTP_HOST is a placeholder to replace in both the endpoint and the egress allowlist before enabling.
Credential reference
The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.
- Reference
secret-ref-smtp-relay-credential- Custody
- customer_vault
- Injection
- header (Authorization)
The SMTP AUTH credential for the relay, held in the client's own secret manager. The email rail presents the resolved material to the relay as its AUTH mechanism requires (for example PLAIN or LOGIN over STARTTLS); it is never interpolated into a message and never logged. The account should be a least-privilege submission identity that can send only as the addresses the deployment means agents to use.
Resources
smtp-relay(mailbox, pii):smtp://SMTP_HOST:587
Pack notes and exclusions
An SMTP relay does one governed thing — accept a message for delivery — so this pack registers one capability. A delivered message cannot be unsent, so it carries the send action at the R3 floor, and send is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). The sender identity belongs to the relay, not the caller: the email connector's payload has no From field and the rail stamps the identity it is configured with, so a caller cannot spoof one. Recipients come from the caller at request time and are checked for shape by the connector, which also bounds the recipient count per message; the destination the message leaves through is the registered endpoint, and nothing else. Outbound mail routinely carries personal data in addresses and bodies, so the capability registers at the pii class — an internal label on client emails is a finding, not a default. SMTP_HOST is a placeholder to replace in both the endpoint and the egress allowlist. This pack covers submission only: it says nothing about inbound mail, mailbox access, bounce processing or DKIM signing, which belong to the relay's own configuration. The pack names no vendor; any relay the deployment's email rail adapter can speak SMTP to serves it.
Review record
Review completed: 2026-09-20 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)
- https://www.rfc-editor.org/rfc/rfc5321 (retrieved 2026-09-20)
- https://www.rfc-editor.org/rfc/rfc6409 (retrieved 2026-09-20)
A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.