Why IMAP Trash and Junk folder names break across languages and providers

Display names are not portable identifiers

Hard-coding `Trash`, `Junk`, or `Sent` works until an account uses another language, provider namespace, or nested folder convention. An IMAP server may expose localized names or vendor-specific labels. The correct first step is discovery: use LIST, inspect attributes, and use standardized special-use information when the server provides it. Your application should care about the folder's role, not whether the display string equals an English word typed by the original developer.

Discover mailbox capabilities when the connection starts

After authentication, record server capabilities and run mailbox discovery. Store the delimiter, hierarchy, and attributes returned for each mailbox. If special-use flags identify `\Trash`, `\Junk`, `\Sent`, or related roles, map those to your internal folder types. If not, fall back to a provider-specific mapping or explicit account configuration rather than silently guessing. This makes localization an expected branch in the connector instead of a production bug.

Keep provider folder mapping separate from business logic

Reply classification should ask for an internal role such as `inbox` or `junk`, while the connector translates that role to the provider's current mailbox name. Do not scatter string comparisons like `folder === "Trash"` across cleanup and reply code. Central mapping also lets you test unusual accounts and update one place when a provider changes conventions. The goal is an adapter boundary: IMAP naming quirks stay in the connector, while outbound state logic remains provider-agnostic.

Subscription and namespace can make a folder look missing

A mailbox that does not appear in one client is not necessarily deleted. Subscription state, namespace prefixes, permissions, and provider presentation can affect what is returned or shown. When a folder “disappears,” rerun LIST and related discovery before creating a replacement. Creating a new `Trash` because the localized trash folder was not recognized can leave two competing destinations and make later cleanup dangerous.

Do not move or delete messages until the role is confirmed

Folder-role mistakes are higher risk than read-state mistakes because they can relocate or remove data. If special-use metadata is absent and the mapping is uncertain, stop destructive operations and surface the account for configuration. A cleanup worker can still report candidate messages without moving them. This conservative fallback is appropriate for a small outbound system: temporary clutter is cheaper than moving 2,400 messages into the wrong mailbox because a string heuristic guessed incorrectly.

Cache mappings, but detect changes

Folder discovery does not need to run before every single message operation, but cached mapping should be tied to the account and refreshed on reconnect, provider errors, or a scheduled interval. If LIST results change after an administrator edits mailbox settings, update the mapping deliberately. Log both old and new folder identifiers so an incident report can explain why a connector changed behavior rather than simply saying “folder not found.”

Test with non-English and nested-folder fixtures

A connector test suite should include an account where trash is localized, a provider that nests special folders, and an account where the special-use attribute is absent. Verify that the role mapping resolves correctly or fails safely. This is one of the simplest ways to avoid the “works on my Gmail test inbox” trap. The code should prove it can discover semantics, not just reproduce one provider's English UI.

Prefer server-advertised roles over translated display names

Folder labels are presentation data. A user may see “Trash,” “Bin,” “Deleted Items,” or a translated equivalent while the server exposes a hierarchy with different names and delimiters. Build a mailbox discovery step that lists available folders and records any special-use attributes the server exposes, then map those roles to internal constants such as trash, junk, sent and archive. Business logic should ask for the trash role, not concatenate a hard-coded English path. If a provider does not advertise a usable role, require an account-specific mapping rather than guessing. This makes the same worker portable across English and non-English mailboxes and prevents a cleanup job from moving replies into the wrong folder.

Invalidate cached mappings when the mailbox topology changes

Caching folder discovery is reasonable, but the cache needs an invalidation rule. Refresh after reconnects that follow provider migration, permission changes, account relinking or a failed folder operation. Compare the current LIST results, namespace and hierarchy delimiter with the stored mapping before performing destructive actions. If the expected trash or junk role cannot be confirmed, fail closed and leave the message untouched. A missing folder is an operational alert, not permission to substitute the first similarly named mailbox. This is particularly important in multilingual accounts, where two labels can look equivalent to a human while representing different server paths or nested folders.

Store server path and human label separately

A mailbox mapping should distinguish the path used in IMAP commands from the label shown in the application UI. The server may expose a nested path with a provider-specific delimiter while the user sees a translated friendly name. Save both fields with the special-use role and account identifier. If the user renames a visible folder or changes locale, the worker can compare discovery data without assuming the display label is the protocol path. This separation also makes debugging clearer: logs can show the exact server mailbox selected while the UI can present a familiar human name.

Include folder discovery in account onboarding tests

When a new mailbox account is connected, onboarding should verify more than credentials. List folders, capture namespace and delimiter, identify special-use roles, confirm the inbox can be opened read-only, and record the server paths selected for Trash and Junk. Run this test before any cleanup or reply automation is enabled. A mailbox that authenticates successfully but exposes an unexpected folder topology is not ready for destructive operations. Making discovery part of onboarding catches provider and language differences before they appear as production incidents.

Never infer Junk from message content alone

A folder classifier should not decide that a mailbox is Junk merely because the messages inside look spammy. Folder role comes from server metadata or an explicit account mapping, not from content inspection. Content can help classify an individual message, but using it to rename or remap folders creates a circular failure mode where the worker may start moving legitimate mail into the wrong destination. Keep topology discovery and message classification as separate subsystems.

Field checklist

• Run LIST/capability discovery instead of hard-coding English mailbox names.
• Map special-use attributes to internal folder roles when available.
• Keep folder-name translation inside the IMAP connector layer.
• Investigate namespace/subscription changes before creating replacement folders.
• Fail closed on destructive moves/deletes when the folder role is uncertain.
• Test localized, nested, and no-special-use mailbox fixtures.