Repository navigation
Deliver company Email transport and migrate mailbox history #5481
Description
🤖 Generated by the Agentic Engineer
Summary
Complete company Email transport and move the existing mailbox safely, with ordinary mail-app access and measured delivery.
Motivation
The maintainer selected direct delivery from the company's server and asked for migration from the existing provider. Preparation of the server, administration access and encryption does not establish working inbound mail, outbound delivery or client access. Those outcomes need a distinct delivery slice under #5030.
Proposed Solution
Use the existing declarative platform and DNS owners to publish reviewed mail transport. Establish a stable sending identity, matching reverse DNS, authenticated TLS submission and receiving access before moving domain-wide mail routing. Preserve every existing mailbox and address until continuity and rollback are proved. Exact addresses, infrastructure details, credentials and message history remain in private operator configuration.
Acceptance Criteria
- Record current transport facts and ownership privately: stable sending address, forward/reverse DNS, provider SMTP permission and an actual server-side outbound SMTP connection. Preserve existing address ownership; any additional recurring cost requires its own authorization.
- Publish only the intended inbound SMTP, authenticated submission and mailbox-access endpoints through reviewed declarative configuration. Validate certificates, renewal, connectivity and client identity from an independent network.
- Reject anonymous relay and spoofed authenticated sending identities; preserve the agents' separate maintainer-only recipient restriction. Verify the relevant positive and negative controls against the deployed server.
- Apply domain routing and SPF, DKIM and DMARC through the reviewed declarative DNS owner, with a tested rollback. Do not move MX before destination delivery, recovery and existing-address inventory are verified.
- Copy and reconcile existing message history and the complete approved address inventory, proving message counts and representative content privately. Gracefully retire old aliases without deleting shared provider history.
- Configure the maintainer's normal mail apps and demonstrate authenticated sending, receiving and reading without per-client encryption identities.
- Observe an authorized external round trip with SPF, DKIM and DMARC passing and inbox placement verified; preserve sanitized evidence and private delivery details.
- Verify the published configuration after protected merge, complete the documented rollback/recovery exercise and update Company Email infrastructure and service notifications #5030 with the remaining acceptance state.
Dependencies
Part of #5030. Safe activation follows availability recovery (#5412) and the account, encryption and independent-recovery gates (#5387). The business sender (#5400) remains a separate slice and requires this deployed transport for its real delivery proof.
Alternatives Considered
A hosted SMTP relay was considered; the maintainer explicitly selected direct delivery. No relay subscription or new permanent infrastructure is authorized by this issue.
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Start date
Target date
Effort
Projects
- Status
Activity
coderabbitai commentedon Oct 28, 2026
🔗 Related PRs
#5367 - fix(mail): stage storage and verification before administration [merged]
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!
chore: agent-claim #5481 nonce=65f1416a0492b34c2bb24afbc75b4ba3
chore: agent-claim #5481 nonce=9cedb1ed87f2163ee60492c353e46eb2
chore: agent-claim #5481 nonce=e3683835ed2399320a52ab4ca068afa7
devantler commentedon Nov 2, 2026
The repaired connectivity workflow has merged in #5732, and its main validation passed. Confirmed main-only run 41431268753, first attempt at
fba2aed2a76c4bf12634b1498861dfdc562a8de1, returnedEMAIL_PROVIDER_SMTP=VERIFIED scope=hosting-node-no-message cleanup=verifiedandEMAIL_PROVIDER_CLEANUP=VERIFIED.This proves the reviewed no-message SMTP session and cleanup. It sends no email and does not establish stable sending identity, reverse DNS, mail-app setup or external delivery. Those acceptance gates remain open on this issue.
devantler commentedon Nov 3, 2026
The maintainer selected one dedicated movable IPv4 and explicitly authorized its quoted recurring cost in the interactive channel on 2026-11-03. This resolves the sending-address decision; it does not establish provisioning, reverse DNS, application egress, routing migration or delivery. Preparation and activation remain owned by the reviewed declarative platform and DNS paths, with service and recovery gates preserved. No resource has been purchased or mail routing changed by this decision record.
devantler commentedon Nov 3, 2026
Fresh protected no-message SMTP check passed at reviewed main
ee240d7f7b0920f88513627d08ed45d18e51dc5b: run 41678031373, job126067004532. Actual receipts reportEMAIL_PROVIDER_SMTP=VERIFIED scope=hosting-node-no-message cleanup=verifiedandEMAIL_PROVIDER_CLEANUP=VERIFIEDat 16:59 UTC. The source binding and diagnostic cleanup completed; no email was submitted.This is current hosting-node network evidence. It does not establish an account-wide support decision, Stalwart application egress, use of the approved permanent address, public transport or inbox delivery. The approved single movable IPv4 is still unallocated; its declarative ownership, host routing, reverse DNS and actual sending-source verification remain part of this delivery work. Existing provider mail routing and mailbox history remain preserved.