Fixing Folder UTF-7 Encoding Errors in IMAP Migration

You finished an IMAP migration and half a dozen folders look wrong in the destination. Café arrived as Caf&AOk-. 受信トレイ shows up as a string of ampersand-escaped gibberish. The migration log shows Folder UTF-7 conversion error on a few items, but most "succeeded" — just with broken names. This is one of the oldest pain points in IMAP and it has a clean fix once you understand what modified UTF-7 is and where in the pipeline the encoding broke.

What modified UTF-7 actually is#

IMAP folder names use a variant of UTF-7 defined in RFC 3501 — usually called modified UTF-7 or IMAP UTF-7. It exists because the original IMAP4rev1 spec from 2003 required folder names to be seven-bit clean ASCII on the wire, so non-ASCII characters had to be escaped.

The mechanics: anything outside printable ASCII is wrapped between & and -. The wrapped section is base64-encoded UTF-16BE with the trailing padding stripped. A literal ampersand becomes &-. So:

• Inbox stays as Inbox
• Café becomes Caf&AOk-
• 受信トレイ becomes &U9dP4TDIMOwwpA-
• R&D becomes R&-D

Every IMAP server is supposed to encode folder names this way on the wire and decode them at the boundary. When the encoding survives into the user-visible folder name, something in the pipeline failed to decode.

Why the error appears#

Three failure modes produce broken folder names on the destination:

• Source encodes, tool fails to decode, destination accepts the literal string. The destination ends up with Caf&AOk- as a real folder name in UTF-8. Bad. Manual cleanup required.
• Source encodes, tool decodes correctly, destination refuses non-ASCII names. The destination returns an error like Folder name contains invalid characters. Some older Dovecot configs and some hosted providers do this for specific characters even when they accept others.
• Source uses UTF-8 directly via RFC 6855, tool re-encodes to modified UTF-7, destination decodes and accepts. This is the happy path most of the time, but if either side mis-handles the conversion, names land in modified UTF-7 form on a UTF-8 destination.

The first failure mode is by far the most common in legacy migration tools that treat folder names as opaque byte strings.

Step 1: list affected folders on the source#

Get the full list of source folders before you start. LIST "" "*" returns every folder name in modified UTF-7. Flag any that contain & followed by a non-- character — those are the escape sequences.

In Mailbox Taxi, the pre-flight scan does this automatically and reports a list of folders that will need encoding conversion. If you are diagnosing after the fact, look at the failure log for Folder UTF-7 conversion error lines and cross-reference against the source folder list.

Step 2: check what the destination supports#

Connect to the destination IMAP server and inspect the CAPABILITY response. Look for UTF8=ACCEPT (RFC 6855). If present, the destination accepts UTF-8 folder names directly and you should use that path. If absent, the destination still expects modified UTF-7.

Common destinations:

• Microsoft 365 / Exchange Online: announces UTF8=ACCEPT. Use UTF-8 directly.
• Google Workspace / Gmail: announces UTF8=ACCEPT. Use UTF-8 directly.
• Fastmail, Zoho: announce UTF8=ACCEPT.
• Older Dovecot, older Cyrus: no UTF8=ACCEPT. Use modified UTF-7.
• Some cPanel mail stacks: no UTF8=ACCEPT. Use modified UTF-7.

When in doubt, modified UTF-7 is the safe fallback — every IMAP server understands it.

Step 3: configure the migration#

Mailbox Taxi handles encoding in three modes:

• Auto (default): probe destination capability, use UTF-8 if available, modified UTF-7 otherwise.
• Force UTF-8: assume destination supports RFC 6855. Faster, but fails on legacy destinations.
• Force modified UTF-7: assume destination wants the wire encoding. Slower, always works.

For one-off migrations to a known destination, leave it on Auto. For batch tooling where you are migrating to multiple destinations of unknown vintage, prefer Auto with a fallback to Force modified UTF-7 if a destination rejects UTF-8.

Step 4: test one affected folder first#

Before running a full migration, pick one folder with a non-ASCII name and migrate just that. The right test folder has at least one character outside the ASCII range — a Latin accent, a non-Latin script, or a typographic punctuation mark.

Run the test, then look at the destination folder name in three places:

• In the destination webmail UI: should show the real character (Café, not Caf&AOk-).
• On the wire via a fresh IMAP LIST against the destination: should show the same modified UTF-7 escape the source had, if the destination is RFC 3501. Should show UTF-8 bytes if the destination is RFC 6855.
• In a desktop client like Thunderbird or Outlook: should also render correctly.

If the webmail UI shows the right name but a desktop client shows the escape, the destination is storing UTF-8 but advertising RFC 3501 on LIST. That is a destination quirk, not a migration bug — the data is correct.

Step 5: run the full migration#

With encoding mode set and the test confirmed, run the full migration. Watch the log for any remaining Folder UTF-7 conversion error lines. They usually point at folder names with control characters or invalid Unicode that even a correct UTF-7 decoder will refuse. Manual rename on the source before retrying is the cleanest fix.

If a folder ends up missing rather than mis-named after migration, the cause is usually a destination-side rejection of the name, not the encoding. The missing folders after migration fix walks through that case.

Related context#

Folder name encoding is one of the IMAP-specific quirks that bites first-time migration engineers. The IMAP protocol glossary has the surrounding vocabulary. For an end-to-end view of IMAP migrations including the encoding step, the IMAP migration guide and the broader complete email migration guide cover the rest of the moving parts. When other migration errors appear alongside this one, the email migration troubleshooting hub is the index.