Access Email Behavior

It is intentionally small and operational.

1. Sending Identity

Primary sender:

• rascher.online Access <access@notify.rascher.online>

Fallback senders:

• rascher.online Access <access@rascher.online>
• rascher.online Access <access@tagnova.news>

Reply handling:

• Reply-To: felix@rascher.online

Operator review inbox:

• felix@rascher.online

2. User Mail Events

Registration Request Recorded

Trigger:

• a user submits the public Request wiki access form successfully

Recipient:

• the requesting user

Subject:

• rascher.online wiki access request received

Purpose:

• confirm that the request was stored
• make clear that this is not approval yet

Access Decision: Approved

Trigger:

• an operator approves the request

Recipient:

• the requesting user

Subject:

• rascher.online access update

Purpose:

• tell the user that access is now approved
• point the user to the wiki login path
• remind the user that account settings live on rascher.online/account/

Access Decision: Rejected

Trigger:

• an operator rejects the request

Recipient:

• the requesting user

Subject:

• rascher.online access update

Purpose:

• tell the user that access was reviewed and not approved

Deletion Request Recorded

Trigger:

• an approved user submits the protected deletion form

Recipient:

• the requesting user

Subject:

• rascher.online deletion request received

Purpose:

• confirm that the deletion request was stored
• make clear that review is still pending
• make clear that access may remain active until review completes

Deletion Decision: Completed

Trigger:

• an operator marks the deletion as completed

Recipient:

• the requesting user

Subject:

• rascher.online access update

Purpose:

• confirm that the invited-reader entry and wiki access were removed where applicable

Deletion Decision: Kept Active

Trigger:

• an operator keeps the account active after deletion review

Recipient:

• the requesting user

Subject:

• rascher.online access update

Purpose:

• confirm that deletion was reviewed but not completed
• make clear that access remains active

3. Operator Mail Events

New Registration Request

Trigger:

• a user submits the public Request wiki access form successfully

Recipient:

• felix@rascher.online

Subject:

• Review needed: rascher.online wiki access request

Purpose:

• signal that a manual review is needed
• include name, email, area, and direct review link

New Deletion Request

Trigger:

• an approved user submits the protected deletion form successfully

Recipient:

• felix@rascher.online

Subject:

• Review needed: rascher.online account deletion request

Purpose:

• signal that a manual review is needed
• include name, email, area, request type, and direct review link

4. What Does Not Send Mail

These actions do not send separate operator mail today:

• successful user login
• user opening the account page
• user opening the wiki assistant
• operator completing the review they just performed

Those flows are intentionally silent unless there is a stored request or a user-facing decision outcome.

5. Text Logic Requirements

Every transactional mail in this flow must:

• clearly distinguish request storage from approval
• use plain language
• name the exact area: wiki
• avoid sounding like marketing
• tell the user the next step

6. Code Owner Files

The current mail contract lives in:

• lib/root-access-email-contract.mjs
• workers/rascher-online-www/index.js
• workers/rascher-online-www/wrangler.jsonc