Setting up Stalwart gave me a useful boundary between applications and communication data. The CRM can work with email and calendars without becoming the mail server or the authority for every calendar object.

The local integration work includes isolated Stalwart instances, account bootstrap scripts, mail configuration, calendar discovery, and sharing checks. Those are separate pieces of evidence; a working calendar request does not establish mail deliverability.

One service, several contracts

The main application-facing paths are:

submission → accept an authenticated outgoing message
mail access → retrieve the account's mailbox data
calendar discovery → find the account's collections and rights
calendar operations → read or conditionally change objects
sharing → change another principal's access

Treating these as one login check hides failures. An account can authenticate for mailbox access while its outgoing identity or calendar permissions are wrong.

The CRM configuration uses protected server-side credentials. Neither a browser nor a published example needs real mailbox identities, domains, or administrative tokens.

Bootstrap should produce a known starting point

For local testing, the bootstrap code configures the service, finds the expected domain and account, and creates or updates the intended test account. Listener configuration is another explicit step.

A persisted configuration change is not necessarily active in a running process. The bootstrap accounts for listener activation rather than assuming that a successful administrative response changed the network immediately.

A development listener is also not a production TLS policy. Local isolation can make a plain transport acceptable for a disposable test, but that setting must not be copied blindly to an exposed deployment.

Discover calendars instead of guessing paths

Calendar integration needs to resolve the authenticated identity and available collections. A collection visible through sharing is not necessarily owned by the account, and visibility does not imply permission to create or delete objects.

The integration therefore needs explicit rights and identity information before selecting a write destination. A successful read of one calendar is insufficient evidence for write access to another.

The sharing checks also exercise stale state. If another operation changed the sharing configuration, an update based on an older state should fail rather than overwrite the newer decision.

Verify the result independently

For calendar writes, the useful evidence is an independent read after the operation, not just a successful response from the write request. The same approach helps when a response is lost and the caller does not know whether the server committed the change.

Isolated tests make these cases practical: create disposable objects, check their identity and permissions, and remove only the objects the test owns.

Mail acceptance has additional layers

SMTP authentication does not prove that an external recipient received the message. DNS identity, signing policy, reputation, and recipient-side filtering require their own checks in a real mail deployment.

Likewise, calendar object creation does not prove invitation delivery or client interoperability. Keeping those claims separate makes the setup easier to operate: every successful check says exactly which service contract worked, and leaves the remaining contracts visible.