Second-Level Trash (Deletions Mailbox)

The second-level trash is the Deletions service folder (default name Deletions): before permanent removal, a message is copied there so an administrator with the appropriate right can review and restore it. Messages restored from Deletions go to the Restored folder (default name Restored).

The regular Trash Mailbox (first level) remains available to the user: they can still move messages there and restore them on their own. Deletions is hidden from regular users and is intended for administrative control and recovery.

Flow

Behavior depends on the DeleteViaDeletions setting (“Keep Messages in Deletions” in the administrator interface) and on the delete method (DeleteMode).

1. Message deletion.
2. If DeleteViaDeletions is off - ordinary deletion.
3. If enabled - behavior depends on the delete method (DeleteMode):
   • Move To Trash: message -> Trash -> on removal from Trash, a copy in Deletions -> physical removal.
   • Mark / Immediately: on physical removal from the source folder - a copy in Deletions -> physical removal.
4. Archiving is best-effort: if opening Deletions or copying into it fails, the marked messages are still physically removed.
5. From Deletions, two outcomes are possible:
   • Restore - an administrator with CanManageDeletions runs the RESTOREDELETION CLI command; the message is moved into Restored (name from the RestoredBox preference) of the same account (even when an administrator restores another user’s mailbox).
   • Permanent removal - on user session logout, the server physically removes messages in Deletions that are older than the retention period set by EmptyDeletions (“Store Messages” in the administrator interface; default 30 days).

With delete method Move To Trash, a copy in Deletions is created only when the message is finally removed from Trash (or when Trash is emptied). With Mark and Immediately, a copy in Deletions is created when the message is physically removed from the source folder.

Settings

Settings are configured in Account Settings (the Settings tab) and can be inherited from the domain template.

The actual names of the Deletions and Restored folders are set by the DeletionsBox and RestoredBox preferences:

Setting	Preference key	Default	Description
Keep Messages in Deletions	DeleteViaDeletions	No	Enables copying into Deletions
Keep Deleted in	DeletionsBox	Deletions	Name of the Deletions folder
Restore Deleted to	RestoredBox	Restored	Name of the Restored folder
Store Messages	EmptyDeletions	30 day(s)	Retention period in Deletions; on session logout, messages older than this period are physically removed

The Deletions Management block (DeleteViaDeletions, EmptyDeletions) in the administrator interface is visible to all administrators; without the Can manage Deletions right (CanManageDeletions; see Access Rights) the values are read-only. The DeletionsBox / RestoredBox folder-name rows are shown only to administrators with CanManageDeletions.

Access Rights

Access to Deletions requires the domain right Can manage Deletions (CanManageDeletions): the folder appears in client folder lists, and the administrator can browse, restore, configure settings, and use full-text search. It is included in the standard domain administrator right set.

Unlimited Mailbox Access (UnlimMboxAccess) additionally allows opening Deletions by its actual folder name (bypassing per-mailbox ACL), but does not add the folder to IMAP, AirSync, or XIMSS lists and does not permit message restore.

Visibility

The Deletions folder (name from the DeletionsBox preference) is hidden from folder lists for users without CanManageDeletions, including requests via:

• XIMSS mailboxList;
• IMAP LIST (IMAP);
• AirSync FolderSync and GetHierarchy (AirSync);
• CalDAV and CardDAV tree walks.

The Restored folder (name from the RestoredBox preference) remains in the list: the account owner can see and open it; access to another user’s Restored requires CanManageDeletions.

Internal and administrative calls without an authenticated account name receive the full physical folder list (account settings, service operations).

Limits for a regular user

A user without CanManageDeletions:

• does not see Deletions in the listed folder APIs;
• cannot open Deletions;
• cannot open another user’s Restored;
• does not receive full-text search hits from Deletions.

The account owner can open their own Restored without CanManageDeletions.

Administrator capabilities

With CanManageDeletions, an administrator sees Deletions in folder lists, browses it, restores messages, and configures second-level trash settings for domain accounts.

Special Folders

As with Trash, the server recognizes service names:

Purpose	Name preference key	Default name	Special name
Deletions	DeletionsBox	Deletions	$Deletions$
Restored	RestoredBox	Restored	$Restored$

The actual folder name is the preference value (DeletionsBox, RestoredBox; defaults Deletions and Restored; the name can be changed in account settings). In folder lists: Restored is visible to the owner; Deletions only to an administrator with CanManageDeletions (see Visibility).

The special name ($Deletions$, $Restored$) is a fixed alias for protocols and clients: on access, the server resolves it to the current preference value. Special names do not appear in folder lists.

The same pattern applies to the Trash Mailbox: TrashBox preference -> actual name, $Trash$ -> special name.

Restore

Restore is available to an administrator with CanManageDeletions via CLI:

• LISTDELETIONS - list messages in Deletions (From, Subject, Date, Return-Path, UID);
• RESTOREDELETION - move one message by UID from Deletions into Restored (name from RestoredBox) of that account.

Relation to Trash

	First level (Trash)	Second level (Deletions)
Purpose	Temporary storage for the user	Administrative archive before permanent deletion
Visibility	User sees the folder	Deletions hidden without CanManageDeletions; Restored visible to owner, others need CanManageDeletions
Restore	User (move from Trash)	Administrator (RESTOREDELETION)
Cleanup on logout	EmptyTrash	EmptyDeletions (if DeleteViaDeletions is enabled)
Folder name preference	TrashBox	DeletionsBox

Recommended configuration when deleted messages must be retained: delete method Move To Trash, DeleteViaDeletions enabled, EmptyDeletions set according to domain policy.

See Also

• Trash Mailbox - first-level settings
• Special Mailboxes - overview of service folders
• messageRemove operation - deletion via XIMSS