Purelymanage

Part of the PurelyManage series. Listing Users The Users page shows all email accounts across all your domains. The list is served from a local PostgreSQL cache rather than a live PurelyMail API call on every page load. The reason is speed and rate limits. PurelyMail’s listUser endpoint returns all users in one call, but calling it on every page load when you have 50+ users and the page auto-refreshes every 60 seconds is wasteful. The cache (purelymail_users table) is populated on first boot and kept in sync by a background cron that runs a full refresh daily at 2am. When a user is created or deleted through the panel, the cache is updated immediately so the UI reflects the change without waiting for the cron. ...

Part of the PurelyManage series. Adding a Domain Adding a domain in PurelyManage is a single form: enter the domain name and submit. The backend calls the PurelyMail addDomain API and the domain appears in your list. await pmPost('/api/v0/addDomain', { domainName }) The domain will show as unhealthy immediately because no DNS records are set yet. That is expected. The next steps are ownership verification and DNS setup. Ownership Verification PurelyMail requires you to prove you control the domain before it will route email for it. Verification is done by adding a TXT record to your DNS with a value PurelyMail provides. ...

Part of the PurelyManage series. PurelyMail has an API. It is not publicly documented. There are no official client libraries. There is no changelog. What exists is a community-written reference at news.purelymail.com/api/index.html that covers the basic endpoints but leaves field names, response shapes, and edge cases as exercises for the reader. Building PurelyManage meant figuring out every endpoint through trial, error, and reading raw JSON responses carefully. Some of it was quick. Some of it was not. ...

Part of the PurelyManage series. The Problem Any admin panel that manages real data has a deletion problem. The moment you give someone a delete button, you are one misclick away from losing something that took time to set up. In a single-user tool this is manageable: you know who deleted it because it was you. In a multi-admin panel it is more complicated. PurelyManage can have multiple sysadmin accounts. Any of them can delete email users, domains, and routing rules. The operations go directly to PurelyMail via their API, meaning the moment the request is made, the resource is gone. There is no recycle bin, no undo, no recovery path. ...

Part of the PurelyManage series. PurelyManage handles two categories of sensitive data: IMAP passwords submitted by users during migration, and the session tokens that keep sysadmins logged in. Neither can be stored carelessly. This post covers how both are handled and why each design decision was made the way it was. Encrypting IMAP Credentials at Rest The problem with storing passwords When a user submits IMAP credentials for a migration job, the backend needs to hold onto those credentials until the job actually runs, which might be minutes or hours later depending on the queue. They have to live in the database. The question is in what form. ...