Izveidot pastkasti personai

Kad izmantot

A person joining the company needs a company mailbox. Not for a person leaving — that is tech.remove-mailbox. Not for setting up the mail program on their laptop or phone — that is tech.setup-mail-client, which runs after this one. If the company does not yet hold the domain the mailbox should be on, run tech.register-domain first.

Pirms sāc

• The person exists in the people module with a start date.
• The address scheme is known (read it from an existing mailbox, do not invent a new pattern per request).
• The domain is held by the company and already serves mail (MX points at Brain Club). If unsure, check

Ko izpilde pieprasa1

Ceļš8 soļi

1. S1

   Confirm the requestaģents

   Read the trigger: who, which domain, which aliases and groups. If anything is ambiguous (two spellings of the name, a role address instead of a personal one), ask the owner before creating.

   Izdarīts, kad address, aliases and groups are written down in one line.

2. S2

   Check for conflictsaģents

   bc mail search <proposed address> — the address must not already exist as a mailbox or alias.

   Izdarīts, kad the search shows no existing mailbox and no alias pointing at one.

   ⛔ An alias of a departed employee is not free space — flag it; the old mailbox is handled by tech.remove-mailbox, not silently reused.

3. S3

   Approve the addressīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S3 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   Present the proposed address, aliases and groups.

   Izdarīts, kad the owner has confirmed the exact address in writing (chat message or task comment is enough).

4. S4

   Create the mailboxaģents

   Create it in the mail module with the agreed address, a generated password, and no forwarding rules. Add aliases and group memberships as approved.

   Izdarīts, kad the mailbox appears in the mail module with the agreed address and zero forwarding rules.

   ⛔ Never send credentials to a manager, a colleague or a chat channel — hand them to the person only, through the onboarding channel the company uses.

5. S5

   Verify the domain serves mailaģents

   bc dns <domain> (read) — MX, SPF, DKIM and DMARC records must match the expected values.

   Izdarīts, kad all four record types are present and match on every Brain Club nameserver.

6. S6

   Test both directionsaģents

   Send a test message from an existing company mailbox to the new address, and one from the new mailbox to an external address. Ask the person to check both arrived — and that the outbound one did not land in the recipient's spam.

   Izdarīts, kad one inbound and one outbound test message are confirmed delivered, with timestamps.

7. S7

   First loginaģents

   The person logs in (webmail or via tech.setup-mail-client, which runs next) and changes the generated password to their own.

   Izdarīts, kad the person has confirmed a successful login.

8. S8

   Record and hand backaģents

   Link the mailbox to the person record; add a renewal/review note with bc tasks add only if the company tracks mailbox reviews; send the owner a two-line summary: address, aliases, test results.

   Izdarīts, kad the mailbox is linked to the person and the summary is sent.

Pārbaudes — kā zinām, ka izdevās

• The address in the mail module reads back exactly as approved in S3 (character by character — gn. vs
• Outbound test message passes SPF and DKIM (check the headers of the received test, not the send log).
• Forwarding rules: zero.
• The mailbox appears in the person's record and in no one else's.

Ja noiet greizi

Ko atstāj katrs solis

1. S1address, aliases and groups are written down in one line.
2. S2the search shows no existing mailbox and no alias pointing at one.
3. S3the owner has confirmed the exact address in writing (chat message or task comment is enough).
4. S4the mailbox appears in the mail module with the agreed address and zero forwarding rules.
5. S5all four record types are present and match on every Brain Club nameserver.
6. S6one inbound and one outbound test message are confirmed delivered, with timestamps.
7. S7the person has confirmed a successful login.
8. S8the mailbox is linked to the person and the summary is sent.

Ko saglabāt

Approved address from S3 (who, when) · bc mail search output from S2 · mailbox creation date · test message timestamps both directions · the person's login confirmation.

Kā šī procedūra uzlabojas

After every 10 runs ask: how long from person-joined to confirmed first mail, and which step waited longest? Did any test message land in spam, and was the cause on our side? Did any mailbox end up with forwarding rules or a reused departed person's address? A new version changes the step that caused the wait or the failure, and says so in its change note.