Rhythm 2.0 Specifications

Appearance

ATS-PFM-NOT-020Apply recipient protection and sender verification: Capability Test Specification

Markdown

ATS-PFM-NOT-020

Apply recipient protection and sender verification: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-NOT-020

Design

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

KindAcceptance test setProduct areaPlatformModuleStaff Notifications and Association CommunicationsRevision2

Read atservices-platform ad3f6a65react-console baf6dae3

Apply recipient protection and sender verification: Capability Test Specification ​

Coverage ​

Each scenario names the guarantee it proves. Category coverage describes specified cases; executable bindings retain their narrower assertion boundaries. Lifecycle coverage remains a gap wherever guards and effects lack independent verification.

RuleProof
BR-CAP-PFM-NOT-020-01ATS-PFM-NOT-020-01, ATS-PFM-NOT-020-15
BR-CAP-PFM-NOT-020-02ATS-PFM-NOT-020-02
BR-CAP-PFM-NOT-020-03ATS-PFM-NOT-020-03
BR-CAP-PFM-NOT-020-04ATS-PFM-NOT-020-04
BR-CAP-PFM-NOT-020-06ATS-PFM-NOT-020-05
BR-CAP-PFM-NOT-020-07ATS-PFM-NOT-020-06
BR-CAP-PFM-NOT-020-08ATS-PFM-NOT-020-07
BR-CAP-PFM-NOT-020-09ATS-PFM-NOT-020-08
BR-CAP-PFM-NOT-020-10ATS-PFM-NOT-020-09
BR-CAP-PFM-NOT-020-11ATS-PFM-NOT-020-10
BR-CAP-PFM-NOT-020-12ATS-PFM-NOT-020-11
BR-CAP-PFM-NOT-020-14ATS-PFM-NOT-020-13
BR-CAP-PFM-NOT-020-15ATS-PFM-NOT-020-14

Use published content, a pending custom sender and one eligible address. Submit and send using shared sending, refresh the custom sender to verified, report a permanent bounce, then submit another occurrence and inspect both messages.

The interaction case combines the producing, processing and reading outcomes named in its frontmatter. It remains proposed until an executable suite performs that complete sequence.

Coverage

  • Rule covered
  • Transition gap: FND-PFM-NOT-081
  • Validation covered
  • Permission gap: FND-PFM-NOT-081
  • Edge covered
  • Failure covered
  • Boundary covered
  • Concurrency gap: FND-PFM-NOT-081
  • Invariant covered
  • Interaction covered

Test Scenarios

15 scenarios proving CAP-PFM-NOT-020; 12 bound to an existing test.

01 Suppress permanently bounced recipientsinteractionapinegativetest
Proves
BR-CAP-PFM-NOT-020-01
Preconditions
Prepare a contact whose notice bounced permanently.
Steps
Submit a further notice for the bounced recipient.
Expected
Bounce detail is retained, the address becomes suppressed and subsequent mail is withheld before submission.
Data
Use only records created and owned by this suite.
Bound to
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
Source
services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js#marks the bounced message bounced_permanent with the diagnostic
02 Deduplicate canonical address suppressioninvariantapitest
Proves
BR-CAP-PFM-NOT-020-02
Preconditions
Prepare a address suppressed for a bounce.
Steps
Suppress it a second time in another spelling for a complaint.
Expected
Repetition adds no entry and preserves the existing bounce reason.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/communications/tests/integration/services/persistence/suppressions.integration.spec.js#canonicalizes the address, so the same mailbox written two ways is one suppression
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
services-platform:modules/communications/tests/integration/services/persistence/suppressions.integration.spec.js#keeps the reason of the suppression already in force when it is suppressed again
services-platform:modules/communications/tests/e2e/suppressions.e2e.spec.js#says nothing was recorded the second time, the list being one row per address
Source
services-platform:modules/communications/tests/integration/services/persistence/suppressions.integration.spec.js#canonicalizes the address, so the same mailbox written two ways is one suppression
03 Validate manual suppression inputvalidationapinegativetest
Proves
BR-CAP-PFM-NOT-020-03
Preconditions
Prepare a administrator with the create permission.
Steps
Add an address with a note; with a empty note; add “not an address”.
Expected
A valid address records manual suppression with its note; blank notes are omitted; invalid addresses report their field.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/communications/tests/e2e/suppressions.e2e.spec.js#records it as a manual suppression with the note staff gave
services-platform:modules/communications/tests/e2e/suppressions.e2e.spec.js#stores the address in its canonical form, lowercase
services-platform:modules/communications/tests/e2e/suppressions.e2e.spec.js#names emailAddress in the refusal of an address that is not one
services-platform:modules/communications/tests/unit/aws/api/communications-schemas.spec.ts#takes no note when the box was left blank, rather than refusing the suppression
Source
services-platform:modules/communications/tests/e2e/suppressions.e2e.spec.js#records it as a manual suppression with the note staff gave
04 Record deliberate suppression releasetransitionapinegativetest
Proves
BR-CAP-PFM-NOT-020-04
Preconditions
Prepare a suppressed address.
Steps
Release it without a reason; with one; release it a second time; suppress it a second time.
Expected
Missing reasons reject without release. Valid release retains actor, reason and history; another release is not found, and later suppression can succeed.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/communications/tests/e2e/suppressions.e2e.spec.js#leaves the suppression active after a release that does not say why
services-platform:modules/communications/tests/e2e/suppressions.e2e.spec.js#keeps the row for the history, read back when the released are asked for
services-platform:modules/communications/tests/e2e/suppressions.e2e.spec.js#answers 404 for releasing the same suppression twice, there being no active one left
Source
services-platform:modules/communications/tests/e2e/suppressions.e2e.spec.js#refuses a release that does not say why as 400
05 Withhold reserved-domain recipients everywhereboundaryapinegativetest
Proves
BR-CAP-PFM-NOT-020-06 INV-DOM-PFM-NOT-005-07
Preconditions
Prepare a request to a reserved-domain address, a public address and a test mailbox.
Steps
Submit the recipient fixture to the sending consumer.
Expected
The demonstration address is withheld with its reason and never submitted; remaining eligible recipients send.
Data
Use only records created and owned by this suite.
Bound to
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
Source
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
06 Apply the configured nonproduction policyedgeapinegativetest
Proves
BR-CAP-PFM-NOT-020-07
Preconditions
Prepare a development environment; a request to an ordinary address, a test mailbox and a blind copy outside the allow list.
Steps
Execute delivery under nonproduction policy.
Expected
Only the allowed test mailbox receives this fixture's mail; other recipients are withheld for environment policy.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js#queues the deliverable contact, withholds the suppressed one and the one this environment may not e-mail
services-platform:modules/communications/tests/integration/services/dispatch/template-copies.integration.spec.js#sends the deliverable BCC copy and drops the one this environment may not e-mail
Source
services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js#queues the deliverable contact, withholds the suppressed one and the one this environment may not e-mail
07 Use shared sending until workspace verificationinteractionapitest
Proves
BR-CAP-PFM-NOT-020-08
Preconditions
Prepare workspaces with verified, pending, failed and unconfigured sender identities.
Steps
Send from each; change the setting and send within and after one minute.
Expected
Only the verified identity uses its own address in this fixture; configured display names remain, and changed verification affects selection after cache expiry.
Data
Use only records created and owned by this suite.
Bound to
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
services-platform:modules/communications/tests/integration/services/sender-identity/tenant-sender-address.integration.spec.js#keeps answering the same thing for the minute it is held, although the setting has changed underneath
Source
services-platform:modules/communications/tests/integration/services/sender-identity/tenant-sender-address.integration.spec.js#sends from the association’s own address
08 Validate sender strategy and domain claimsvalidationapinegativetest
Proves
BR-CAP-PFM-NOT-020-09
Preconditions
Prepare a organization asking for its own sender.
Steps
Attempt a second identity, missing required domain, prohibited address-only domain, mismatched and subdomain addresses, and verified state without verification time.
Expected
All invalid identity records fail without persistence.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/communications/tests/integration/db/communication-sender-identities.table.integration.spec.js#refuses a second sender identity for the same tenant, by the unique rule’s name
services-platform:modules/communications/tests/integration/services/persistence/sender-identities.integration.spec.js#refuses a domain given to the address strategy, which proves the address alone
Source
services-platform:modules/communications/tests/integration/db/communication-sender-identities.table.integration.spec.js#refuses a second sender identity for the same tenant, by the unique rule’s name
09 Provision or adopt the requested provider identitiesruleapitest
Proves
BR-CAP-PFM-NOT-020-10
Preconditions
Prepare a organization that asked for the both strategy; one that asked for none.
Steps
Provision each; provision the first a second time.
Expected
The combined strategy creates domain and address identities with tags and DNS instructions in pending state. Retry adopts them; a workspace requesting none creates none.
Data
Use only records created and owned by this suite.
Bound to
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
Source
services-platform:modules/communications/tests/integration/services/sender-identity/provision-sender-identity.integration.spec.js#creates the domain identity and the address identity, in that order
10 Preserve first verification through later provider statestransitionapitest
Proves
BR-CAP-PFM-NOT-020-11
Preconditions
Prepare a pending sender identity.
Steps
Refresh while DNS is absent; after it is published; after it breaks.
Expected
State progresses from pending to verified with its first instant, then can lose verification without clearing that instant.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/communications/tests/integration/services/sender-identity/provision-sender-identity.integration.spec.js#is verified as soon as any identity will send, because that is when SES accepts mail from the address
services-platform:modules/communications/tests/integration/services/persistence/sender-identities.integration.spec.js#records when the association’s own sender started working, the first time it is verified
Source
services-platform:modules/communications/tests/integration/services/sender-identity/provision-sender-identity.integration.spec.js#is verified as soon as any identity will send, because that is when SES accepts mail from the address
11 Remove scoped sender and stored communication datafailureapinegativetest
Proves
BR-CAP-PFM-NOT-020-12
Preconditions
Prepare a organization with a sender identity and stored mail; another whose id begins the identical way.
Steps
Purge the first workspace, then exercise a provider refusal during identity removal.
Expected
Provider identities, setting and scoped objects disappear while another workspace's storage survives. Provider removal refusal fails the operation for operator attention.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/communications/tests/integration/services/storage/tenant-objects.integration.spec.js#leaves the objects of a tenant whose id merely begins like the purged one, which is what the trailing slash is for
services-platform:modules/communications/tests/integration/services/storage/tenant-objects.integration.spec.js#removes the tenant’s rendered bodies and the requests they came from, both prefixes in one call
Source
services-platform:modules/communications/tests/integration/services/sender-identity/provision-sender-identity.integration.spec.js#deletes every identity the setting named
12 Withhold future messages after bounce feedbackinteractionapinegativetest
Proves
AS-JNY-PFM-NOT-006-03
Preconditions
Prepare a permanently bounced contact.
Steps
Submit another workflow notice for the previously bounced address.
Expected
The next request retains a suppressed withholding outcome.
Data
The lifecycle suite's organization type, contacts and recording provider.
Bound to
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
Source
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
13 Persist verification refresh without rewriting first successtransitionapiproposed
Proves
BR-CAP-PFM-NOT-020-14
Preconditions
Prepare a sender setting with provider identities and a previous verified time.
Steps
Refresh from a changed provider response.
Expected
State and latest-check time change, while first verification time remains unchanged.
Data
A sender setting with provider identities and a previous verified time.
Source
services-platform:modules/communications/services/sender-identity/provision-sender-identity.ts:refreshSenderIdentityVerification
14 Remove adopted identities and verify provider absencetransitionapiproposed
Proves
BR-CAP-PFM-NOT-020-15
Preconditions
Prepare a sender setting linked to an adopted provider identity.
Steps
Purge the workspace sender identities.
Expected
Purge deletes the adopted identity and checks absence; a surviving identity makes the operation fail.
Data
A sender setting linked to an adopted provider identity.
Source
services-platform:modules/communications/services/sender-identity/provision-sender-identity.ts:purgeSenderIdentityIdentities
15 Sender and recipient safeguards remain visible through the mail lifecycleinteractionapiproposed
Proves
BR-CAP-PFM-NOT-020-01
Preconditions
Use published content, a pending custom sender and one eligible address.
Steps
Submit and send using shared sending, refresh the custom sender to verified, report a permanent bounce, then submit another occurrence and inspect both messages.
Expected
The first occurrence retains its selected sender and provider report. Later work uses the refreshed sender after cache expiry and withholds the protected address with a retained reason.
Data
A suite-owned workspace, named staff accounts and unique occurrence keys; external adapters record attempts without shared writes.
Source
rhythm-v2-docs:specs/platform/notifications/planning/capabilities/CAP-PFM-NOT-020-protect-deliverability-and-the-associations-sending-address.md#frontmatter,rhythm-v2-docs:specs/platform/notifications/planning/capabilities/CAP-PFM-NOT-017-ask-platform-to-send-an-association-e-mail.md#frontmatter,rhythm-v2-docs:specs/platform/notifications/planning/capabilities/CAP-PFM-NOT-018-deliver-association-e-mail-reliably-and-within-sending.md#frontmatter,rhythm-v2-docs:specs/platform/notifications/planning/capabilities/CAP-PFM-NOT-019-record-what-became-of-each-e-mail.md#frontmatter

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