Turn UTF-8 URI text into correctly encoded mail
04UTF-8 percent-encoding represents non-ASCII template text. The final email then needs its own message encoding; internationalized domains have a separate IDNA conversion.
The public user@%E7%B4%8D%E8%B1%86.example.org template decodes to the 納豆 domain label and composes user@xn--99zt52a.example.org using IDNA. No mail is actually submitted.
Source for this drawing: RFC 6068 · Read RFC section 2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- UTF-8
- A character encoding that represents Unicode characters as bytes.
- MIME
- Multipurpose Internet Mail Extensions: message body formats and encodings for email.
- IDNA
- Internationalizing Domain Names in Applications: processing internationalized domain names for use in Internet protocols.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
URI encoding, message encoding and domain encoding are different layers.
- Non-ASCII hfvalues may use UTF-8 bytes followed by percent escapes. Header text must be suitably encoded for the composed message; body text uses the relevant MIME body encoding. Correctly transcoded alternatives MAY be used in the message.
- MIME encoded-words are also permitted in suitable header values when their URI-reserved characters are escaped, but have no special decoding meaning in a body hfvalue. URI-supplied MIME encoding fields MUST be ignored; the MUA creates appropriate message fields.
- For a UTF-8 percent-encoded internationalized domain, composition MUST apply IDNA where appropriate. Producers SHOULD supply the IDNA form for legacy interoperability. This RFC does not define complete internationalized local-part or fallback-address support; do not infer it from these domain/header examples.
The two URI rows in the drawing join without whitespace; the line split is only for layout. The public§6.3 café example has UTF-8 bytes63 61 66 C3 A9. The displayed MIME message is one possible encoding, not a requirement to use Q/quoted-printable or UTF-8 on the wire. The public 納豆 domain becomes xn--99zt52a.example.org; this is not percent-decoding a local part into an SMTPUTF8 support promise.
Read the RFC section ↗