Summary

  • RFC 2047 carries non-ASCII text through selected mail-header positions, but decoding produces presentation text rather than authenticated sender identity.
  • A defensible record keeps raw header data, structured parsing, charset decoding, mailbox syntax, signature coverage and final rendering as separate pieces of evidence.

Consider two harmless example headers. One represents “René” with UTF-8 octets inside a Q encoded-word; another uses an ISO-8859-1 octet. A capable reader can display the same four letters in both cases. Change the angle-bracketed mailbox while retaining that visible name and the screen may still lead with “René”. The equality belongs to the rendering. It does not make the raw lines equal, and it certainly does not make the mailboxes, signing domains or human actors equal.

This distinction is the durable lesson in RFC 2047, published in 1996 under Keith Moore’s name. The document solved a difficult interoperability problem. Internet message headers inherited an ASCII grammar and travelled through software known to fold lines, rearrange fields and mishandle obscure syntax. People nevertheless needed subjects, comments and personal names in many writing systems. The answer was not to pretend those systems were ASCII. It was to reserve a recognisable ASCII envelope for text that a reader could decode later.

An encoded-word has four parts: =?charset?encoding?encoded-text?=. The charset says how octets become characters. The encoding is initially Q or B. B uses MIME’s Base64 form. Q resembles quoted-printable and gives underscore the special meaning of a space octet. The syntax is short enough for bounded look-ahead: one encoded-word may not exceed 75 characters, and a header line containing one is limited to 76. Longer text can be divided among adjacent encoded-words.

That compact envelope is a representation contract. It is not a claim about the person named by the resulting text.

Where the envelope is allowed

RFC 2047 does not license encoded text everywhere. It allows encoded-words in text-oriented field bodies such as Subject, in comments, and as words within a phrase—for example, the display-name portion before an address. It explicitly forbids them in an addr-spec, in a quoted string, in a Received field and in MIME parameters such as those of Content-Type or Content-Disposition.

Those exclusions are evidence boundaries. If a display name reads “René”, the mailbox after it is still parsed under the mailbox grammar. A decoder must not manufacture a new @, angle bracket or address delimiter and then ask the mail parser to reinterpret the visible result. The specification says decoding and display happen after a structured field body has already been parsed into tokens. A special character revealed by decoding may look identical to punctuation around it; it does not retroactively acquire that punctuation’s syntactic power.

RFC 5322 makes the distinction easier to see. A name-addr may combine an optional display name with an angle address. The mailbox receives mail; the display name helps a person read the address. The same document distinguishes From, which states the message’s author role, from Sender, used for the agent responsible for actual transmission when that agent is not an author. These are message-format semantics. They are not cryptographic proof that the asserted author, agent or mailbox controlled the submission.

The format is therefore richer than the screen. A client that hides the addr-spec behind a friendly chip has made a presentation choice, not simplified the underlying evidence.

A fold can vanish without disappearing from history

Adjacent encoded-words carry another surprise. Linear white space between them is ignored when they are displayed. That rule lets a composer fold a long non-ASCII phrase without inserting a visible space at the fold. It also means that the reader-facing string is not a byte transcript of the header that crossed the network.

Each encoded-word remains self-contained. An escape or multi-octet character cannot begin in one word and finish in the next. Yet several legal raw sequences can still converge on one visible string: different registered charsets, different Q and B choices, different hex letter case, and different folding positions may all be consumed before the user sees the result.

The reverse can happen too. A reader may lack a charset, reject malformed encoded text, substitute a marker or make a best effort. RFC 2047 permits several display outcomes for unsupported material and does not require a malformed encoded-word to block the rest of the message. A raw line alone cannot prove what one historical user saw unless the parser, charset support and presentation context are also known.

This is not an indictment of decoding. It is the unavoidable consequence of turning a transport representation into readable language.

Direct UTF-8 changes the route, not the question

RFC 6532 later allowed UTF-8 directly in many header field bodies when the surrounding internationalised-mail environment supports it. It recommends Unicode normalization form NFC and discusses the security consequences of equivalent or confusing representations. A direct UTF-8 header no longer needs an RFC 2047 envelope for the same job, but the evidence layers remain: octets, syntax, code points, normalization, glyphs and identity are not interchangeable.

Mixed estates make this practical rather than historical. One message may arrive with encoded-words, another with direct UTF-8, and a gateway may have handled an older representation on the way. A monitoring system that stores only the final display string erases which path occurred. It can no longer distinguish a clean direct header from a decoded legacy form or show where replacement, normalization or folding changed what was visible.

A signature covers input, not a face on screen

RFC 6376 supplies a separate receipt. DKIM signs a canonicalized body and a declared set of header fields; its responsible identity is a Signing Domain Identifier. Verification can show that the signed input survived under a domain’s key and the chosen canonicalization. It does not assert that every field was signed, that a display name is a verified human, or that the person whose name appears had authority for a payment, account change or public statement.

The order matters. DKIM’s evidence concerns canonicalized message data. RFC 2047’s reader-facing evidence concerns recognition and decoding after field parsing. An operations panel that keeps only “DKIM pass” beside “René” has joined two outputs without showing the bridge: which From instance was signed, which bytes it contained, which encoded-word positions were recognised, which mailbox was parsed and which domain actually supplied the signing identity.

A valid signature and a correct display can both be true while answering different questions.

The receipt hidden behind a polished name

A defensible reconstruction begins with an observation point and a protected hash of the raw field. It records field order, folding and line endings; parser and decoder versions; token boundaries; every position recognised as an encoded-word; the charset and Q or B choice; decode errors and replacement policy; decoded code points and any normalization; the parsed display name and parsed addr-spec separately; and the final string, locale, font fallback and warning state shown to the reader.

Authentication belongs beside that chain rather than inside it. Record which header fields DKIM covered, the canonicalization, verification result and Signing Domain Identifier. If a system used transport trace, mailbox ownership, account policy or organizational authority, keep those as their own claims. If any raw material, parser version or rendering context is missing, say so instead of filling the gap with the visible name.

Such a receipt can itself expose personal information. It should be minimized, access-controlled and retained only as long as the decision justifies. The aim is not permanent surveillance of mail. It is to avoid making an irreversible conclusion from a presentation layer whose inputs were discarded.

Keith Moore’s IETF record lists a broad set of mail and Internet contributions. A 2008 University of Tennessee historical article says he worked there from 1991 to 2007 and had participated in IETF standardisation groups since 1990. Those dated facts establish the person and context; they are not a current job title. The narrower contribution here is exact: RFC 2047 made international header text transportable and displayable while preserving a line between what software can show and what the message can prove.

Sources