Visual RFC.
ALL RFCs / RFC 2047
Read the RFC ↗
RFC 2047 / EMAIL ENCODED WORDS

Decode only in allowed header locations

03

A recognizable wrapper is not permission to decode it everywhere. Header grammar decides which portions can contain encoded words.

RFC 2047 · § 5EXAMPLE
5 / 5
Decode only in allowed header locationsFive header-grammar cases: a separated encoded word in Subject; a display-name phrase distinct from mailbox qa@example.test; escaped parentheses inside a structured-field comment; a forbidden mailbox placement stopped before decoding; and quoted-string, Received and MIME-parameter restrictions. The verified comment erratum excludes literal backslash as well as parentheses from Q payload in comments.Header grammar decides where words belongNot encoded-word locations:quoted-string · ReceivedContent-Type/Disposition parameterPlacement rejecteddo not decode by wrapper shape aloneOther mechanisms govern internationalized parameters
05
Reject the placement, not the whole message.

Quoted strings, Received and MIME parameter values do not become valid encoded-word locations just because the bytes resemble =?...?=. Use the grammar and appropriate other specifications.

Source for this drawing: RFC 2047 · Read RFC section 5 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Locate the header token before decoding its display text.

  • Locate the header token before decoding its display text.
  • Encoded words can replace text in allowed text fields such as Subject, appear in structured-field comments, or replace a word in a phrase such as a display name. Required linear white space separates them from adjacent text or syntax as specified for each context.
  • They MUST NOT appear in an addr-spec, quoted-string, Received field or MIME Content-Type/Content-Disposition parameter. Q literals in a phrase have a narrower set; in comments, literal parentheses and backslash are forbidden (verified erratum504).
DETAILS

An addr-spec is the actual mailbox address, such as qa@example.test; a display name is a separate phrase before it. A comment is a parenthesized grammatical component in a structured header. Parentheses in a Subject are ordinary text, not comment delimiters. Restricted punctuation can be encoded as bytes; do not mistake the wrapper’s delimiters for phrase payload characters. Held erratum5469 clarifies wording, while the published §5 already requires complete =HH escapes. Other internationalized-address or MIME-parameter mechanisms are outside this RFC.

Read the RFC section ↗

All chapters in RFC 2047

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗