Summary

  • RFC 9755 separates a server's UTF-8 capability from an authenticated client's explicit enablement; neither proves that the intended identity, mailstore, index and client path work together.
  • Acceptance should end with a controlled message that the intended user can list, search, fetch, interpret and act on—not with a green protocol transcript.

Imagine a release test in which an internationalized message is appended successfully. The server returns OK. The message exists somewhere. Yet the target user cannot find it by sender, cannot open the attached message, or never sees it on one supported client. Nothing in that sequence contradicts the first receipt. It shows that the receipt answered too small a question.

RFC 9755, published on the Standards Track in March 2025, makes this boundary unusually visible. It replaces RFC 6855 for IMAP4rev1; IMAP4rev2 already incorporates roughly the same abilities. Its protocol changes are real and useful. Their precision is also a warning against treating one negotiated token as a certificate for the whole service.

Advertisement is not activation

UTF8=ACCEPT says that a server can open mailboxes containing internationalized messages and return UTF-8 mailbox names. UTF8=ONLY includes that support while refusing the older modified UTF-7 convention. A server advertises at most one of the two.

The client still has work to do. It must authenticate, then issue ENABLE UTF8=ACCEPT. Even a UTF8=ONLY server expects that command—not an invented ENABLE UTF8=ONLY. Under RFC 5161, the resulting ENABLED response records which requested extensions became active. A later CAPABILITY response does not become a per-session enablement record.

An acceptance packet therefore needs both facts: what the relevant server build advertised, and what each real client session enabled. A configuration screenshot supplies neither if it is detached from the session that performed the test.

Syntax does not provision an identity

RFC 9755 does not extend IMAP LOGIN to carry UTF-8 usernames and passwords. A client needing them must use AUTHENTICATE. But the RFC immediately narrows the promise: making a credential syntactically legal does not guarantee that the server's identity system has provisioned or will accept the account.

This is a separate gate. A test identity must exist in the authoritative identity store, authenticate through the production mechanism, map to the intended mailbox and retain the same authorization under every supported access route. Otherwise an IMAP parser has accepted a string that the service still cannot turn into a user.

APPEND is a storage beginning, not a user outcome

After enablement, RFC 9755 requires a supporting server to accept UTF-8 headers in APPEND; before enablement it must reject an APPEND containing 8-bit header characters. That gives operators a valuable positive and negative test.

The positive response is not a visibility warranty. The revised RFC removes the old APPEND UTF8 data item and notes that IMAP4rev1, IMAP4rev2 and JMAP do not offer a trustworthy per-message indicator of whether that old item was used. The meaningful receipt is therefore message-specific: preserve a controlled raw input, record the APPEND result and assigned identifier where available, then retrieve the same message and compare the fields the service promises to preserve.

Mailbox names need their own vectors. RFC 9755 requires Net-Unicode with exclusions for controls and separators. RFC 5198 explains why canonically equivalent sequences should converge on NFC. RFC 6532 likewise recommends NFC for internationalized headers and warns against NFKC when it would erase spelling distinctions. Display equality, byte equality and search equality are different claims; the test report should say which one is expected.

That distinction reaches the implementation layer. Current Dovecot documentation describes UTF-8 mailbox-name storage as a specific configuration choice and warns that changing it breaks existing non-ASCII mailbox names. This is one product's documented seam, not evidence about the industry. It demonstrates why a protocol upgrade cannot silently stand in for a mailstore migration plan.

FETCH can be correct in two shapes

Internationalized headers also appear inside MIME structures. RFC 6532 defines message/global; software unaware of it may treat the part as an unknown attachment. For enabled IMAP4rev1, RFC 9755 allows two legitimate BODYSTRUCTURE treatments and requires clients to accept both. IMAP4rev2 follows RFC 9051. Verified erratum 8697 corrects the relevant comparison to message/rfc822.

A single happy-path parser is therefore inadequate evidence. Test fixtures should cover both permitted rev1 encodings, the rev2 result, nested internationalized headers and retrieval of the raw part. A thumbnail or an attachment count cannot prove that the client interpreted the same structure the server stored.

Search and access paths are separate products

Once UTF-8 is enabled, SEARCH must not carry a charset argument; commands with mandatory charset fields should use UTF-8. That change can expose old client assumptions even when LIST and FETCH look healthy. A release sample should record the exact query and returned UIDs for composed and decomposed test strings, headers, mailbox names and body text.

RFC 9755 also refuses a comforting simplification: operators often cannot know whether every IMAP or POP client, web interface or other consumer of a shared mailstore can handle the same message. Its legacy choices—error, notice, hiding or a standardized surrogate—are policies, not proof of equivalent access. This article does not revisit the separate archival question of who keeps a surrogate's original. The narrower point here is that each supported route needs an explicit expected outcome and a message-level observation.

The final receipt belongs at the human boundary. Can the intended user see the mailbox, find the test message, recognize sender and recipient, open its parts, and reply or forward where policy allows? If not, the earlier receipts remain useful diagnostics. They do not add up to delivered utility.

The evidence here establishes protocol semantics and one documented implementation seam. It does not measure adoption or certify any vendor. The operational reading follows Heng Lu's distinction between symbolic representation and executable reality: the capability token is a representation; the usable message is the reality that must be observed. The standards chain also includes SMTP internationalization, the documented downgrade transformation, the corresponding simplified POP behavior, and the IMAP4rev2 baseline. They bound interoperability claims; they do not turn one successful path into universal visibility.