Rhythm 2.0 Specifications

Appearance

CAP-PFM-NOT-020Apply recipient protection and sender verification

Markdown

CAP-PFM-NOT-020

Apply recipient protection and sender verification

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationObserved

Planning

Feature
FEAT-PFM-NOT-07
Key concepts
CON-PFM-NOT-005
Actors
ACT-PFM-028, ACT-PFM-031
Journeys
JNY-PFM-NOT-006
Related
CAP-PFM-NOT-017, CAP-PFM-NOT-018, CAP-PFM-NOT-019
Proved by
ATS-PFM-NOT-020
Executed by
TST-PFM-NOT-025, TST-PFM-NOT-029, TST-PFM-NOT-030, TST-PFM-NOT-037, TST-PFM-NOT-039, TST-PFM-NOT-048, TST-PFM-NOT-050, TST-PFM-NOT-058, TST-PFM-NOT-059, TST-PFM-NOT-061, TST-PFM-NOT-066

KindCapabilityProduct areaPlatformModuleStaff Notifications and Association CommunicationsRevision1

Read atservices-platform ad3f6a65react-console baf6dae3

Apply recipient protection and sender verification ​

Purpose ​

Platform withholds unsafe recipients and selects a verified association sender when available.

How It Works ​

Platform checks canonical recipient addresses against suppression and environment policy. Permanent bounce and complaint feedback adds suppression automatically. Staff can add suppression or release it with a recorded reason. Message and copy destinations receive protection checks independently. Sender provisioning creates or adopts the provider identities requested by the workspace. Refresh writes verification state and check times, and delivery uses verified identity or the shared sender. Deletion verifies provider removal before deleting the setting. Shared adopted identities remain an unresolved ownership and deletion risk.

The product should establish sender-identity ownership before allowing adopted identities to be deleted during workspace cleanup.

Relationships ​

This outcome supplies communication records used by acceptance, sending and inspection.

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
Suppressions prevent applicable recipient sends, and sender checks select verified identities or the shared fallback.Nonproduction delivery admits test addresses and the configured allowlist, which can include real mailboxes.
Surfaces
apijob
Intent sources
services-platform:docs/communications/architecture.md#15. Decisions for Andrewservices-platform:docs/communications/architecture.md#2026-10-09 — Final acceptance

Controls

39 controls apply, from the corpus control catalogue.

TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-006 TC-CRY-001 TC-CRY-002 TC-CRY-003 TC-CRY-004 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-DAT-004 TC-DAT-006 TC-IAM-001 TC-IAM-002 TC-IAM-004 TC-IAM-005 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-PI-001 TC-PI-003 TC-PI-005 TC-PRV-001 TC-PRV-002 TC-PRV-004 TC-SEC-001 TC-SEC-002 TC-SEC-003 TC-SEC-004 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-VEN-001 TC-VEN-002 TC-VEN-003

Permissions

KeyChecked atScope
platform.communication-suppressions.readapitenant
platform.communication-suppressions.createapitenant
platform.communication-suppressions.updateapitenant

Business Rules

15 rules, 13 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

IdRuleKindEnforced atProvenance
01must prove
Proposed
Permanent bounces and complaints suppress the workspace address, withholding subsequent mail without provider submission.
origin: services-platform:docs/communications/architecture.md#2026-10-09 — Final acceptance
no proof recorded yet
lifecycleservicetest
services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js#stores the next notice to that address suppressed, with the reason, and sends nothing
02must prove
Proposed
Canonical addresses identify suppression entries; repeated suppression preserves the current reason and creates no duplicate entry.
no proof recorded yet
invariantservice, databasetest
services-platform:modules/communications/tests/integration/services/persistence/suppressions.integration.spec.js#records nothing for an address already suppressed, so a repeated bounce adds no second row
03must prove
Proposed
Suppression-create permission allows an address and optional note; whitespace-only notes are omitted, and malformed or blank addresses produce field-specific refusals.
no proof recorded yet
validationapi, servicetest
services-platform:modules/communications/tests/e2e/suppressions.e2e.spec.js#records it as a manual suppression with the note staff gave
04must prove
Proposed
Release requires an explanation and records actor and reason while retaining history; missing or already-released entries are not found; a released address may be suppressed again.
no proof recorded yet
lifecycleapi, servicetest
services-platform:modules/communications/tests/e2e/suppressions.e2e.spec.js#refuses a release that does not say why as 400
05
Proposed
Suppression lists are newest first and normally show active entries; Including released entries is optional; pages default to fifty and cap at two hundred.
policyservicetest
services-platform:modules/communications/tests/integration/services/persistence/suppressions.queries.integration.spec.js#answers at most the 200 a page may hold, however many the caller asks for
06must prove
Proposed
Reserved demonstration domains, including example.com relatives and .test, .example, .invalid and .localhost suffixes, are withheld in every environment; other request recipients continue independently.
no proof recorded yet
policyservicetest
services-platform:modules/communications/tests/integration/services/dispatch/reserved-domain-suppression.integration.spec.js#withholds its message with the reserved-domain reason, so the history says why it was not sent
07must prove
Proposed
Nonproduction sends allow only test mailboxes and configured permitted addresses or domains; other primary and copy recipients are withheld.
no proof recorded yet
policyservicedocumented
services-platform:docs/email.md#The delivery policy
08must prove
Proposed
Verified workspace sender addresses take precedence over Rhythm's shared sender; Selection is cached per process for one minute; template and request settings determine display names.
no proof recorded yet
policyservicetest
services-platform:modules/communications/tests/integration/services/sender-identity/tenant-sender-address.integration.spec.js#sends from the shared Rhythm sender, so the tenant’s mail never waits for the customer
09must prove
Proposed
Each workspace has one sender setting using domain, address or combined verification; Domain strategies require a domain; address-only omits it; Addresses match the verified domain exactly rather than a subdomain, and verified state includes its verification time.
no proof recorded yet
validationservice, databasetest
services-platform:modules/communications/tests/integration/db/communication-sender-identities.table.integration.spec.js#refuses an address at a subdomain of it, which SES does not cover either
10must prove
Proposed
Provisioning creates or adopts the identities needed for the selected strategy, retains applicable DNS instructions and existing verification state, and does nothing when no identity is requested.
no proof recorded yet
lifecycleservicetest
services-platform:modules/communications/tests/integration/services/sender-identity/provision-sender-identity.integration.spec.js#leaves the setting pending, because nothing it did proves the customer published anything
11must prove
Proposed
Provider refresh reports verified when any identity can send, pending while DNS is missing, and failed when none can send and a provider identity failed; the first verification time remains permanent.
no proof recorded yet
calculationservicetest
services-platform:modules/communications/tests/integration/services/persistence/sender-identities.integration.spec.js#never clears that instant when a later reading is no longer verified
12must prove
Proposed
Workspace deletion removes provider identities before the setting and reports deletion failure rather than claiming success while an identity remains; request and body cleanup is confined to the workspace prefix.
no proof recorded yet
lifecycleservicetest
services-platform:modules/communications/tests/integration/services/sender-identity/provision-sender-identity.integration.spec.js#fails for an operator rather than reporting a sender gone that can still send
13
Proposed
Platform invitation and password messages always use Rhythm's Platform sender rather than association identity.
policyservicedocumented
services-platform:docs/email.md#Sending identities
14must prove
Proposed
Verification refresh reads provider state and writes the resulting setting and latest check time, preserving the first verified instant.
no proof recorded yet
lifecycleserviceobserved
services-platform:modules/communications/services/sender-identity/provision-sender-identity.ts:refreshSenderIdentityVerification
15must prove
Proposed
Purge removes both newly created and adopted provider identities and verifies absence before recording removal.
no proof recorded yet
lifecycleserviceobserved
services-platform:modules/communications/services/sender-identity/provision-sender-identity.ts:purgeSenderIdentityIdentities

Scenarios

IdGivenWhenThenProvenance
01A member's address received a permanent bounce the previous week.CRM submits the next compliance message to that address.The message records suppression withholding without provider submission.inferred
services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js#stores the next notice to that address suppressed, with the reason, and sends nothing

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software