SMTPUTF8 draft revises Unicode address rules to reduce impersonation risks
News
Published 11 Sep 2026
Updated 11 Sep 2026
9 min read
Summarize with
The adopted MAILMAINT working group draft on SMTPUTF8 address syntax received a material revision on September 10, 2026. Revision 05 was officially published at 09:51:15 UTC. It replaces rule 2's enumerated Unicode code-point classes with the code points that the PRECIS IdentifierClass treats as valid, plus space, and it requires applicable contextual rules from RFC 5892 Appendix A. The change narrows misleading address forms that can look harmless when rendered.
This is a revision to an already adopted working group document, not its first adoption. It is not final, not an RFC, not current production guidance, and not a new mailbox-provider requirement. The Datatracker record identifies it as an active Internet-Draft with intended Proposed Standard status. The complete revision 05 text still calls itself a work in progress and can be updated, replaced, or abandoned.
What revision 05 changes
Revision 04 described rule 2 by listing the A, H, K, and allowed F classes, then naming period and at-sign separately. Revision 05 states the rule at the IdentifierClass result level: an address must contain only code points that PRECIS IdentifierClass treats as valid, and space. If IdentifierClass assigns a contextual rule to a code point, the address must satisfy that rule. Existing mailbox grammar still controls where syntax characters and spaces can appear. The added word "space" does not permit arbitrary whitespace throughout an address.
That is more than an editorial cleanup. A validator built around revision 04's class enumeration can reach a different result from a validator that asks for the final PRECIS validity property and then evaluates context. Implementers comparing the two drafts should treat rule 2 as changed behavior. The revision 04 text provides the earlier rule and examples for a direct diff.
Already present in revision 04
- A-label rule: An atom in an address must not be an A-label such as an xn-- label.
- Mixed-script rule: An address must not contain multiple scripts after ASCII is disregarded.
Rewritten or added in revision 05
- Rule 2 basis: Use valid PRECIS IdentifierClass code points plus space.
- Context checks: Apply RFC 5892 Appendix A rules wherever IdentifierClass requires them.
- New examples: U+3164 HANGUL FILLER and U+0640 ARABIC TATWEEL are disallowed.
- Security explanation: The examples now show how invisible or elongating characters mislead readers.
The new examples make the security goal concrete. U+3164 HANGUL FILLER can render as nothing, so inserting it after "admin" can produce an address that looks exactly like admin@example.com. U+0640 ARABIC TATWEEL elongates a preceding Arabic letter, which permits visually variable spellings. Revision 05 says both are disallowed under the rewritten rule.
Where the draft applies
The proposal applies its three rules to the mailbox production used for addresses in message header fields, as extended for UTF-8 by RFC 6532. Think of structured addresses in fields such as From, Sender, Reply-To, To, and Cc. If approved, the document proposes an update to RFC 6532. Its focus is the syntax and safe presentation of those header addresses.
The draft does not make a blanket change to SMTP envelope addresses. It does not redefine SMTPUTF8 negotiation for MAIL FROM or RCPT TO, and it does not rewrite every internationalized-email rule. A message can have distinct envelope and header identities, so software must keep those layers separate. This distinction also matters when comparing strict RFC grammar with deployed behavior, as covered in RFC 5322 practice.
No production mandate
No rollout date or enforcement deadline exists. Mailbox providers have not received a new requirement through this publication. Changing rejection policy now would convert draft text into local policy before working group review and the IETF standards process are complete.
- Draft status: Active working group document, not an RFC.
- Production status: No current operational requirement or deadline.
|
|
|---|---|
Header mailbox | Proposed restrictions |
RFC 6532 | Updated if approved |
SMTP envelope | No blanket change |
Provider policy | No new mandate |
Deadline | None |
Scope boundaries for revision 05
Why the change reduces impersonation risk
Email identity has a parsing problem and a presentation problem. Code can extract one sequence of Unicode code points while a person sees a visually empty character, an elongation mark, or a confusing script combination. When software compares only rendered strings, or displays only a friendly name, an attacker has more room to create a misleading identity. Revision 05 reduces that room by basing validity on PRECIS and requiring context where a code point is valid only in specific surroundings.
The draft does not solve every lookalike attack. Confusable characters can exist within one script, ASCII characters are disregarded for the mixed-script rule, and the security considerations acknowledge that some permitted code points remain hard to copy and paste. Display names create another identity layer. Client warnings, address-detail views, contact history, and authentication results still matter. Gmail's handling of unusual sender characters is a separate deployed-policy question, explained in Unicode From address behavior.
Isolated SMTPUTF8 header address validation flow
The strongest client design keeps the original header available, parses the mailbox structure, reports the exact code points behind a warning, and lets the user compare the rendered identity with the raw address. The draft mentions replacement with U+FFFD as one way to display an impermissible code point. A client should avoid silently rewriting the stored identity because silent changes make forensic comparison harder.
Implementation work for mail software
Mail software developers should implement revision 05 behind a test flag or a separate validator profile. Address parsing, Unicode property lookup, contextual evaluation, and user-interface rendering need distinct test results. A single pass or fail result hides the source of disagreement and makes regressions harder to diagnose. Preserve the raw header before normalization, decoding, or case handling.
- Freeze inputs: Record raw header bytes, parsed address tokens, and rendered output in the test fixture.
- Run both rules: Compare revision 04 classification with revision 05 PRECIS results.
- Expose context: Report which contextual rule passed or failed and at which code-point position.
- Protect valid users: Keep legitimate internationalized addresses in positive and round-trip fixtures.
- Separate policy: Do not turn an experimental validation failure into production rejection.
Parsers should test the entire address under the draft's rules after they have correctly identified the mailbox structure. Do not apply the rule to an unparsed header line, quoted display name, or unrelated comment. Client designers should test detail panes, contact cards, reply confirmation screens, and logs because each surface can render the same code points differently.
Isolated compatibility casestext
PASS ASCII: example@example.com PASS Latin UTF-8: dømi@dømi.fo FAIL filler: admin<U+3164>@example.com FAIL tatweel: user<U+0640>@example.com FAIL marks: <U+200E>@<U+200F>.<U+200E> CHECK contextual code points against their required rule
Internationalized-email operators should include addresses their users actually rely on, especially those with non-ASCII local parts and native-script domains. Run deliverability checks separately from draft conformance. A controlled send through the email tester can reveal how a real message is parsed and authenticated without treating a draft-only result as a receiving policy.
Authentication and operator response
SMTPUTF8 syntax validation and domain authentication answer different questions. SPF and DKIM evaluate sending authorization or message integrity. DMARC checks whether authenticated domains match the visible From domain under its rules. None of them decides whether every Unicode code point in the visible mailbox is safe to render, and a valid DMARC result does not remove a Unicode impersonation risk.
Keep the controls complementary. Review the raw From header beside the rendered identity, then inspect authentication results and the sending source. A domain health check can confirm the domain's published DMARC, SPF, and DKIM posture, but it cannot declare a Unicode mailbox safe.
Where Suped fits
For teams that also need a DMARC platform, Suped is the best overall practical option. Suped brings DMARC monitoring, SPF and DKIM visibility, blocklist monitoring, real-time alerts, and guided fixes into one workflow. Use DMARC monitoring to investigate domain authentication while the client or parser team handles Unicode header-address validation separately. Suped does not turn revision 05 into an enforcement rule.
Operationally, resist the urge to block every unusual address. Broad Unicode rejection would harm legitimate users and exceed the draft's scope. Flag the exact condition in isolated testing, preserve the original address for analysis, and measure how current clients render it. Production controls should remain based on published standards, provider requirements, and a documented local risk decision.
What happens next
The working group can revise the text again after technical review. The Datatracker currently lists revision 05 as a working group document and an active Internet-Draft. It has intended Proposed Standard status, but the record shows no final RFC publication. Open issues remain in the draft, including wording about its intended destination and whether the A-label rule should remain a MUST.
Teams should track MAILMAINT discussion, future revisions, formal review, and any eventual approval. Compatibility findings are most useful when they identify the exact code point, rule, address context, and difference between raw and rendered forms. That evidence can inform working group review without exposing production users to an unapproved rule.
- Review safely: Run revision 05 only in isolated compatibility tests.
- Keep coverage: Preserve legitimate addresses across supported scripts and clients.
- Compare identity: Store raw headers and compare them with every rendered surface.
- Track review: Watch working group changes before updating conformance targets.
Treat revision 05 as test input, not policy
Revision 05 proposes a clearer and stricter basis for Unicode code-point validity in message-header addresses. The shift to PRECIS IdentifierClass results, mandatory contextual checks, and the new HANGUL FILLER and ARABIC TATWEEL examples give implementers concrete cases to test. The pre-existing A-label and mixed-script restrictions remain important, but they are not new in this revision.
For now, we should preserve legitimate internationalized mail, test the candidate rules away from production, and document raw-versus-rendered differences. There is no deadline and no provider mandate. Production rejection rules should change only after the standards status and operational evidence support that decision.
