IMAP folder delimiters are not always “/”: read LIST before constructing Trash, Sent or nested mailbox paths

Define the exact state transition

IMAP LIST responses include mailbox attributes, hierarchy delimiter information, and mailbox names. The delimiter is server-defined and can differ across implementations or namespaces.

IMAP does not guarantee that mailbox hierarchy uses `/`. The LIST response tells the client the hierarchy delimiter for a mailbox namespace, and that delimiter can be another character such as `.` or can be NIL where hierarchy is not represented in the usual way. Hard-coding `INBOX/Processed` therefore works on some providers and quietly fails on others. A portable client should discover mailbox names and delimiter through LIST, then use the server-returned representation when building child mailbox paths. This is particularly important in multilingual accounts where the display name and hierarchy conventions can differ from the examples used during development.

Where automation can flatten two different states

A webmail interface showing nested folders with a slash does not prove slash is the protocol delimiter. The UI can render hierarchy independently from the wire representation.

Do not normalize every folder path into filesystem conventions before sending it back to IMAP. A mailbox name is a server namespace value, not a local path, and escaping/encoding rules also matter. Another trap is assuming that a slash in a displayed label necessarily means hierarchy; depending on provider behavior it can be part of a name or mapped through provider-specific semantics. Keep the raw LIST name and delimiter alongside the friendly label used by your UI. That gives the connector an authoritative value even if a user sees a translated or prettified folder title.

A deterministic test case

Issue LIST for the target account, preserve the returned delimiter and exact mailbox names, then compare them with names your code currently constructs. Repeat on at least two providers before generalizing behavior.

Test against at least two providers or a test IMAP server configured with different delimiters. Capture LIST responses, create or select a child mailbox using the returned delimiter, and verify the same code works without a provider-specific slash substitution. Include a mailbox whose name contains spaces and a non-English special-use folder so path handling is exercised beyond `INBOX`. If the server returns NIL, the client should avoid fabricating hierarchy. This fixture also helps catch code that splits stored mailbox names on `/` before issuing SELECT or MOVE-like operations.

The smallest change that restores correctness

Store discovered mailboxes per account and resolve special-purpose folders through attributes or configured mapping. Join hierarchy components only with the delimiter the server advertised.

Store a canonical server mailbox identifier exactly as discovered, plus separate fields for delimiter, special-use role if available, and human display label. When a folder disappears, refresh LIST rather than constructing a guessed alternate path from the English word “Trash” or “Junk.” This small abstraction keeps IMAP operations independent from locale and provider naming. It also makes migrations easier: only the discovery/mapping layer changes, while reply scanning, archiving, and suppression logic continue to address the mailbox selected by the server’s own namespace rules.

Example from a multi-mailbox workflow

One server can return “/” while another returns “.” or NIL for a flat namespace. Building Trash/Subfolder with a fixed slash will therefore produce a name the second server never advertised.

Special-use mailbox discovery can complement delimiter handling. Providers may expose roles such as Junk, Trash, Sent, or Archive through flags/extensions even when the visible names are localized. Prefer those machine-readable roles where supported, then fall back to stored user configuration rather than English-name guesses. Persist the exact LIST response that established the mapping so a later support case can explain why `Papierkorb`, `Deleted Items`, or another localized name was chosen. Refresh the mapping when LIST changes instead of every poll. This avoids hard-coded strings and prevents a migration from silently scanning or deleting the wrong folder. For a reply detector, Inbox and All Mail behavior should be a deliberate provider strategy built on discovery, not a side effect of splitting a path on `/`.

Audit fields for later debugging

Record server capabilities, namespace or LIST response, delimiter, exact UTF-8 mailbox name, and the application role assigned to it such as junk, trash, sent, or archive.

Failure modes that need a different branch

Do not rename provider folders to make automation easier. Discover and map what exists; otherwise a deployment can unexpectedly rearrange a user’s mailbox.

Treat mailbox mapping as discovered configuration. Cache it for efficiency, but invalidate and rediscover after provider migration, namespace errors, or repeated SELECT failures. Do not silently fall back to an English folder name. A loud mapping error is safer than scanning the wrong mailbox, because missing replies can continue sending follow-ups while the automation appears healthy. Preserve the returned delimiter and raw mailbox name in the incident log so the same mapping can be verified after reconnect.

Field checklist

• Capture the raw evidence for IMAP LIST hierarchy delimiter slash dot folder automation before editing DNS, queue state, or mailbox metadata.
• Confirm the cited mechanism using imap-rfc rather than a generic deliverability score.
• Keep a known-good control case so the failing layer can be compared without changing several variables at once.
• Apply the narrow repair described for IMAP folder delimiters are not always “/”: read LIST before constructing Trash, Sent or nested mailbox paths and preserve a rollback or retry path.
• Repeat the original failing test after the change; do not substitute a different checker as proof of recovery.
• Store timestamp, affected identity, raw result, action taken, and the post-change result in the operator log.