We manage SmarterMail accounts through a custom provisioning API rather than allowing customers to directly create and delete users within SmarterMail (although if they are a domain admin they can delete from SmarterMail webmail if they choose)
One feature we are considering is a “soft delete” process for mailbox removals when a customer requests deletion of a mailbox via support ticket.
Instead of immediately deleting a mailbox when a customer requests account deletion, our API would:
- Detach the user instead of deleting them.
- Record the detach date.
- Retain the detached mailbox for 14 days.
- Automatically purge detached mailboxes after the 14-day retention period.
The main benefit is that if a customer accidentally requests a delete of a mailbox and contacts support a few days later, we could simply reattach the user and restore the mailbox with all mail, folders, settings and data intact.
We are also considering the following scenario:
- A mailbox such as user@domain.com is detached.
- Before the 14-day retention period expires, someone attempts to create a new mailbox using the same email address.
- Our provisioning system would detect the detached mailbox and present two options:
- Restore the detached mailbox (Attach User)
- Permanently delete the detached mailbox and create a completely new account
Before implementing this workflow, I would like to understand whether this is a supported use case for Detach/Attach.
Specifically:
- Is Detach User intended to be used as a temporary retention state before permanent deletion?
- Are there any known issues with reattaching users after days or weeks?
- Is there any risk associated with reusing an email address that already exists as a detached user?
- Is there an API method available to determine whether a detached user exists for a particular email address?
- Has anyone else implemented a similar “recycle bin” or “soft delete” process around Detach User?
From an operational standpoint this seems like it could provide a useful safety net for accidental deletions, but I would be interested to know if there are any caveats before building this into our provisioning platform.
Thanks.