Skip to content

Provide the business site's dedicated Email sender #5400

Open
0 of 1 issue completed
Open

Description

@devantler

🤖 Generated by the Agentic Engineer

Summary

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.

Priority High, effort Medium, Standard.

Activity

  1. self-assigned this
    on Oct 26, 2026
  2. moved this to 📥 Backlog in 🌊 Project Boardon Oct 26, 2026
  3. updated Effort Medium and Priority High on Oct 26, 2026
  4. devantler commented on Oct 28, 2026

    @devantler
    ContributorAuthor

    🤖 Generated by the Agentic Engineer

    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.

  5. devantler commented on Nov 10, 2026

    @devantler
    ContributorAuthor

    🤖 Generated by the Agentic Engineer

    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.

  6. devantler commented on Nov 10, 2026

    @devantler
    ContributorAuthor

    🤖 Generated by the Agentic Engineer

    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.

  7. added a commit that references this issue on Nov 11, 2026
  8. devantler commented on Nov 11, 2026

    @devantler
    ContributorAuthor

    🤖 Generated by the Agentic Engineer

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Fields

Priority

High

Start date

None yet

Target date

None yet

Effort

Medium

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions