Summary

  • draft-ietf-mailmaint-smtputf8-syntax-05, posted on 10 September 2026, replaces an enumerated set of permitted character classes with the PRECIS IdentifierClass and requires its contextual rules to succeed.
  • The revision adds examples excluding U+3164 HANGUL FILLER, which can render as nothing, and U+0640 ARABIC TATWEEL, which can create many visually elongated spellings.
  • A valid-character decision is deliberately narrow. It does not prove mailbox ownership, human identity, account existence, SMTPUTF8 path support or delivery.
  • The draft still contains a literal wording mismatch around a quoted space and the punctuation used by an address. That should be clarified rather than silently repaired by implementers.

The blank space in the help-desk ticket

Imagine two account-recovery records placed side by side. The operator sees the same administrator mailbox on both screens. The database reports different byte strings. One local part contains U+3164 HANGUL FILLER immediately before the separator; in the font used by the console, the extra code point occupies no visible space.

The discrepancy matters before authentication begins. One service might store both strings. Another might strip the filler. A third might reject it. A fourth could display one value while an API compares the other. If an operator keeps only the screenshot or the rendered log line, the evidence needed to reconcile those decisions is already gone.

Revision 05 of SMTPUTF8 Email Addresses turns this from an informal caution into a proposed syntax boundary. Its new example says U+3164 renders as nothing and is not permitted. It also excludes U+0640 ARABIC TATWEEL: although Unicode classifies the character as a letter, it only lengthens the preceding Arabic letter and can multiply the visual spellings of one address.

The Datatracker record identifies the document as an active Mail Maintenance Working Group draft aiming at Proposed Standard. The history records revision 05 on 10 September. Those facts establish a current proposal. They do not establish IETF approval, deployed conformance or an observed abuse case.

One reference now carries more of the decision

Revision 04 described its second rule by listing four categories from RFC 8264: ordinary letters and digits, joining controls, printable ASCII and specific exceptions, together with the address punctuation. Revision 05 replaces that inventory with a reference to the PRECIS IdentifierClass. Where that class assigns a contextual rule, the address must satisfy it.

This is not merely shorter prose. An enumerated list invites separate implementations to reconstruct the permitted set and to forget that some code points are not simply valid or invalid. PRECIS has four dispositions: valid, contextual rule required, disallowed and unassigned. A joining character can therefore require evidence about its neighbours. A validator that checks only a Unicode category has not completed the decision.

RFC 8264 designed IdentifierClass for protocol strings that identify or address a network entity. It prioritises safety over expressiveness. Traditional letters and digits and printable ASCII are admitted; old Hangul Jamo, controls, ignorable properties, spaces, symbols, punctuation outside the grandfathered ASCII range, compatibility forms and several other classes are excluded. Some exceptions and join controls need context.

The old and new formulations draw from the same standards family, so “revision 05 bans everything revision 04 allowed” would be false. The material change is where the executable definition lives and how explicitly context is made part of conformance. An implementation should follow the referenced decision procedure, not preserve a hand-copied category table indefinitely.

A letter can still be an exception

U+0640 shows why category names are weak evidence. RFC 5892 puts ARABIC TATWEEL in an explicit exception table and marks it DISALLOWED even though the general property calculation would otherwise produce PVALID. The exception is normative input to the result. “Unicode says Letter” does not settle whether the code point belongs in this identifier class.

The HANGUL FILLER example reaches the same governance problem by another route. A character can survive in the input while vanishing from the display. The draft’s public test set also exercises bidirectional controls, fullwidth compatibility letters and conjoining old Hangul Jamo. The tests make the proposed boundary reproducible, but they remain working-group source material. Passing them does not certify every parser, form, directory, mail transfer agent or recovery flow.

Revision 05 retains a third rule: after ASCII is disregarded, an address must not contain more than one script. The examples distinguish an address using Han plus ASCII from one mixing Han with a non-ASCII Latin character. Unicode Standard Annex #24 defines the script property that gives this rule its vocabulary. The rule is an admission constraint in this draft, not a judgment about the legitimacy of multilingual people or organisations.

The quoted-space line is not ready for inference

The current text has an awkward edge. Rule 2 literally says that an address may contain only code points treated as valid by IdentifierClass, and a quoted space. Yet the next examples refer separately to dot, slash and the at-sign, and IdentifierClass itself treats printable ASCII differently from non-ASCII spaces. The public author source contains the same wording.

That may be a small drafting error, a grammar-level assumption or a sentence awaiting another revision. The record available at the evidence cutoff does not choose among those explanations. Implementers should not invent a correction and then call their choice the standard. A future revision, issue disposition or working-group statement can resolve it.

This restraint matters because punctuation is structural. The mailbox grammar determines where a local part ends, where a domain begins and which quoted or special forms are available. A character-class rule and a grammar production operate at different layers. Conformance evidence needs to name both.

Admission is not identity

RFC 6532 permits direct UTF-8 in Internet message headers, including addresses, within the internationalised email framework. The current draft tries to narrow which internationalised address strings interoperate safely. Neither document turns syntax into authority.

An accepted string does not show that the mailbox exists. A delivered challenge might show control at one time, but not a civil identity or organisational mandate. A domain may be syntactically sound and still deceptive. A receiving path may support the characters while an account-recovery database corrupts them. Conversely, a rejected code point does not show malicious intent; a user may have copied an address from a visual source without knowing its code-point sequence.

The earlier BTW history of SMTPUTF8 concerned a different boundary: every relevant transport hop must preserve an internationalised address because there is no generic way to downgrade its local part. This revision concerns the predicate applied before a string is admitted. Path capability and character admission can fail independently.

Keep the reason, not only the verdict

A useful admission receipt would begin with exact UTF-8 input bytes and the ordered code-point sequence. It would record the mailbox grammar component being tested, the IdentifierClass disposition for every non-ASCII code point, the contextual rule and its result, the script calculation, and any mapping, case, normalisation or directionality policy applied by the service.

The receipt should also name the Unicode/PRECIS data version, validator build, decision time, calling surface and final action. A safe display can show escaped code points or a warning marker alongside the human-readable string. The raw value belongs in protected evidence, not in a log view that makes an invisible character disappear again.

This is an editorial proposal, not an IETF requirement. Its purpose is modest: let a registration form, API, recovery service and mail gateway explain whether they made the same decision for the same input. Local services can still choose their account policy. The shared receipt keeps that choice from being mistaken for a fact about identity or delivery.

Sources