You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Provide the business site's dedicated Email sender #5400
Provide a dedicated automated sender for the business site using the company Email service.
User Story
As the business owner, I want automated company email from the business site so that I and clients receive the messages needed for our workflows.
Motivation
The maintainer requested automated messages to the owner or clients, including future password resets and announcements. Reusing the agents' restricted identity would mix application access with private operational correspondence.
Proposed Solution
Declare the sender and its enforced sending identity, separate scoped application credentials, private custody and delivery controls. Keep exact production addresses in private operator configuration. Preserve credentials on replay and restore; do not weaken the agents' recipient restriction.
Acceptance Criteria
The dedicated sender and credential custody can be recreated declaratively without overwriting restored credentials or creating a normal administrator mailbox.
Authenticated submission permits only the configured sending identity; anonymous relay and a different envelope/header sender are refused.
The business site's own server-side credential can send to authorized owner/client recipients with verified TLS, SPF, DKIM and DMARC.
Rate limits, bounded retry/failure reporting and revocation are exercised with synthetic inputs; no credentials or message contents enter public logs.
Runtime configuration and rollback are documented; protected merge and actual delivery readback complete the slice.
Dependencies
Part of #5030. Credential activation follows verified backup recovery and the Email identity/recovery work in #5376 and #5387. The website integration is a separate sibling delivery; undeployed identity, password-reset or announcement features remain disabled until their own acceptance passes.
The remaining dedicated-sender work is tracked here. Duplicate #5529 has been withdrawn. The original sender restriction criteria include native tests for missing or ambiguous message sender identity, and the integration should define maintainer visibility for replies and delivery failures. No sender or credential has been activated by this refinement.
The dedicated sender needs a DATA-stage check with an explicit failure response. Stalwart's envelope check covers MAIL FROM. Its documented Sieve example tests for a matching address among the visible From addresses, and the trusted interpreter can accept mail after a script error. A standalone Sieve rule therefore cannot establish the sender boundary required here. Envelope authentication, trusted interpreter error handling.
Evaluate a DATA-stage hook scoped to the dedicated authenticated sender with temporary failure on transport, parsing or service error. Native SMTP controls should prove one top-level From header with exactly one parsed mailbox matching the verified envelope. Include duplicate headers, multiple addresses in one header, mismatched or missing sender, filter outage and ordinary-mail controls. Keep message bodies, invitation links and credentials out of logs. Stalwart hook settings.
The sender and real invitation delivery still depend on mailbox recovery and the reviewed company mail transport. This is a testable implementation direction. No sender, delivery or production setting was changed.
The DATA hook passed a native SMTP fixture on the deployed Stalwart version, 0.16.27. An authenticated fictional sender could submit a mismatched message header before the hook was configured. With the scoped hook installed, read back and loaded after restart, verified TLS submission accepted the exact machine sender and rejected mismatched, duplicate, multiple, grouped and missing From values. Stalwart independently rejected the wrong envelope sender.
The dedicated sender received a temporary SMTP failure when the HTTPS hook was unavailable or its CA was untrusted. Ordinary authenticated submission still passed with the hook unavailable. The fixture used synthetic mail, a private disposable network and generated credentials. It did not send an external message or alter the production bootstrap inventory.
Keep the production sender off until the exact retained hook and its activation guard are reviewed and the mailbox recovery and transport gates pass. The hook can be skipped if it is absent or its enable expression fails, so the successful endpoint tests do not replace exact native configuration readback and an independent sender hold. External invitation delivery and SPF, DKIM and DMARC proof remain open.
PR #6084 supplies the default-off dedicated submission component; it does not deploy a sender or establish external invitation delivery. Its two latest review findings now have native RED/GREEN controls for receiving-certificate validity and malformed authentication budgets. Fresh hosted validation and review remain in progress.
The actual pinned ZITADEL SMTP client first attempts implicit TLS when TLS is selected, on any configured port, and uses Go's verified system trust rather than the custom CA pool used by the component's test peer. Native client. Before commissioning, execute the real packaged ZITADEL client against the selected submission endpoint with its actual certificate, hostname and retained trust configuration. An untrusted CA or wrong name must refuse before authentication; disabling verification is not an alternative. Do not treat the existing Go-peer tests as that interoperability proof.
Keep the dedicated sender off until the separate recovery, transport, configuration-readback and real invitation/SPF/DKIM/DMARC acceptance pass. No mail, credentials, production runtime or DNS settings have been changed by this source work.
Activity
devantler commentedon Oct 28, 2026
The remaining dedicated-sender work is tracked here. Duplicate #5529 has been withdrawn. The original sender restriction criteria include native tests for missing or ambiguous message sender identity, and the integration should define maintainer visibility for replies and delivery failures. No sender or credential has been activated by this refinement.
devantler commentedon Nov 10, 2026
The dedicated sender needs a DATA-stage check with an explicit failure response. Stalwart's envelope check covers
MAIL FROM. Its documented Sieve example tests for a matching address among the visibleFromaddresses, and the trusted interpreter can accept mail after a script error. A standalone Sieve rule therefore cannot establish the sender boundary required here. Envelope authentication, trusted interpreter error handling.Evaluate a DATA-stage hook scoped to the dedicated authenticated sender with temporary failure on transport, parsing or service error. Native SMTP controls should prove one top-level
Fromheader with exactly one parsed mailbox matching the verified envelope. Include duplicate headers, multiple addresses in one header, mismatched or missing sender, filter outage and ordinary-mail controls. Keep message bodies, invitation links and credentials out of logs. Stalwart hook settings.The sender and real invitation delivery still depend on mailbox recovery and the reviewed company mail transport. This is a testable implementation direction. No sender, delivery or production setting was changed.
devantler commentedon Nov 10, 2026
The DATA hook passed a native SMTP fixture on the deployed Stalwart version, 0.16.27. An authenticated fictional sender could submit a mismatched message header before the hook was configured. With the scoped hook installed, read back and loaded after restart, verified TLS submission accepted the exact machine sender and rejected mismatched, duplicate, multiple, grouped and missing From values. Stalwart independently rejected the wrong envelope sender.
The dedicated sender received a temporary SMTP failure when the HTTPS hook was unavailable or its CA was untrusted. Ordinary authenticated submission still passed with the hook unavailable. The fixture used synthetic mail, a private disposable network and generated credentials. It did not send an external message or alter the production bootstrap inventory.
Keep the production sender off until the exact retained hook and its activation guard are reviewed and the mailbox recovery and transport gates pass. The hook can be skipped if it is absent or its enable expression fails, so the successful endpoint tests do not replace exact native configuration readback and an independent sender hold. External invitation delivery and SPF, DKIM and DMARC proof remain open.
chore: agent-claim #5400 nonce=9afff6b5645ab1bf64a8b692f20e116a
devantler commentedon Nov 11, 2026
PR #6084 supplies the default-off dedicated submission component; it does not deploy a sender or establish external invitation delivery. Its two latest review findings now have native RED/GREEN controls for receiving-certificate validity and malformed authentication budgets. Fresh hosted validation and review remain in progress.
The actual pinned ZITADEL SMTP client first attempts implicit TLS when TLS is selected, on any configured port, and uses Go's verified system trust rather than the custom CA pool used by the component's test peer. Native client. Before commissioning, execute the real packaged ZITADEL client against the selected submission endpoint with its actual certificate, hostname and retained trust configuration. An untrusted CA or wrong name must refuse before authentication; disabling verification is not an alternative. Do not treat the existing Go-peer tests as that interoperability proof.
Keep the dedicated sender off until the separate recovery, transport, configuration-readback and real invitation/SPF/DKIM/DMARC acceptance pass. No mail, credentials, production runtime or DNS settings have been changed by this source work.