Federation
Comail currently has one relay operator. Moving a member’s relay state to another operator is not available. This page describes the current limit and ideas for future federation.
Why this page exists
Section titled “Why this page exists”Turnkey migration between relay operators is not available. The design below is a proposal; it does not describe a working multi-relay service.
Current service
Section titled “Current service”Comail runs one relay service under one operator. It authenticates members, checks sending domains, and sends mail through a shared IP pool. A member’s DID remains anchored at their PDS. Relay history and state do not transfer automatically to another operator.
What federation would require
Section titled “What federation would require”A second relay alone would not provide member migration or shared reputation signals. Comail has not implemented the routing, migration, and governance rules needed to operate multiple relays together.
Possible multi-relay design
Section titled “Possible multi-relay design”Federation could mean multiple relay operators, member migration between relays, shared reputation signals, and a labeler they trust. These are design ideas, not available features.
Member-PDS routing
Section titled “Member-PDS routing”The PDS could publish which relay handles a member’s mail. A member could then move by changing that record and completing a hand-off between operators. Comail has not defined the record or built the hand-off.
Shared atproto labeler as source of truth
Section titled “Shared atproto labeler as source of truth”The public labeler currently issues labels for some member states (see atproto labels). A multi-relay design could use a shared service to coordinate trust signals from all relays.
This could keep some reputation signals linked to a DID when a member moves. The current auto_suspended signal is private to the relay and is not available through the public label endpoint.
Operators would need to choose whether to share a labeler or run a coordinated service. That choice requires a governance and key-management design.
IP pool federation
Section titled “IP pool federation”Each relay would operate its own outbound IP pool. A member who moves to another relay would send from different IP addresses, so IP history would not move with their DID.
Operators could share policies for rate limits, pauses, suppression, warming, and acceptable use. The policies and migration behavior are not agreed or implemented.
What a second operator would change
Section titled “What a second operator would change”If Comail adds another operator, it would need to define:
- How a member would select a relay, including whether the PDS would publish a routing record.
- How relays would share send and complaint signals for atproto labels.
- How relays would share suppression entries.
- How relays would assess reputation and set warming limits.
- How operators would maintain the Acceptable Use Policy.
Members would continue to sign in with an atproto handle, verify a domain through DNS, and view status in /account. The routing record would determine which relay accepts their SMTP connection.
Open design questions
Section titled “Open design questions”The following points remain design questions rather than commitments.
Governance for label policy changes
Section titled “Governance for label policy changes”The labeler defines the cooperative’s trust signals. Changes to label policy, such as raising the complaint-rate threshold or adding a label, currently happen through the single operator. A federation must decide whether operators, members, or both ratify those changes. The labeler may need a narrower process than the operating entity because its semantics affect participants across relays.
The current working answer: label policy changes go through the same ratification path as AUP changes. The mechanism is still being designed.
IP pool agreements between operators
Section titled “IP pool agreements between operators”Operators need an agreement for incidents in which a sender’s behavior affects more than one relay’s reputation. Today each operator bears the cost of a block on its own IP pool. A federation needs shared response rules while keeping each operator responsible for its infrastructure.
One proposal is a mutual-defense agreement at the labeler level: an operator could request emergency suspension of a DID, the labeler would issue the label, and each relay would enforce it within minutes. This proposal would put the labeler in the critical path for trust-and-safety actions.
Member migration mechanics
Section titled “Member migration mechanics”The routing record and shared reputation system are not built. A migration would also need to handle queued mail, pending bounces, suppression entries, and DKIM keys.
Roadmap vs shipped
Section titled “Roadmap vs shipped”The table below shows the current status of these features:
| Piece | Status |
|---|---|
| Single-operator relay on isolated infra | Shipped |
| Atproto labeler with public verification | Shipped |
| Relay source code | AGPL-3.0 license; repository is private and source is not publicly available |
| Routing record on PDS | Proposed, not built |
| Multi-relay labeler queries | Proposed, not built |
| Cooperative ratification process for label policy | Open question |
| Operator mutual-defense agreement | Open question |
| Second operator running a federated relay | Not available; no date set |
What partners can do today
Section titled “What partners can do today”PDS communities can direct members to enroll with Comail as other atproto users do. This does not give the community control of the relay or move relay state to another operator.
Atproto infrastructure operators can use the project’s public discussion channels to contribute requirements or review the open questions above.