Summary

  • RFC 2231 numbers long MIME parameter sections from zero, requires a consecutive sequence and permits character-set and language information only at the beginning. The section numbers determine reconstruction; wire order does not.
  • Reconstruction and percent decoding can recover a text value, but they confer no trust. RFC 2183 treats filename as a storage suggestion and tells receivers to strip paths, avoid dangerous destinations and prevent automatic execution.

A filename in three pieces

Imagine an attachment arriving with this illustrative metadata:

filename*0*=utf-8'en'Quarterly%20; filename*1*=review%20; filename*2=final.pdf

The visible value is not present in any one field. The first section identifies UTF-8 and the optional language, then carries the opening octets. The second continues with percent-encoded material. The third is unencoded. If the three sections are complete, their logical result is Quarterly review final.pdf.

The easy mistake is to treat those fields like three independent strings. RFC 2231 defines something more exact. The suffixes begin at zero, rise by one and contain no gaps. Leading zeroes are not allowed. MIME parameter order is otherwise insignificant, so a receiver cannot trust arrival order: *2 may appear before *0. It must recognise a common base name, establish one unambiguous consecutive series and concatenate the sections by number.

Only then is there one encoded value to interpret. The character set and language, when supplied, appear at the start of the first encoded section; they are not fresh declarations for each fragment. That makes the boundary between two sections a transport convenience, not necessarily a character boundary. A multibyte character can be split across it. Decoding each fragment as a complete text string can therefore create replacement characters or a different result from a parser that reconstructs first.

RFC 2231 does not present this as a modern security processing model, and its own security paragraph is spare. But its grammar implies a durable order of work: parse names; validate the series; order and join the payload; percent-decode encoded material into octets; interpret the declared character set; then hand the resulting value to a separate disposition policy. Each verb answers a different question. Combining them hides disagreements that attackers and malformed mail can exploit.

Syntax proves reconstruction, not permission

RFC 2231 extended MIME parameter syntax. It did not promote a parameter into an operating-system command. That boundary was already explicit in RFC 2183, the Content-Disposition specification that RFC 2231 updated.

RFC 2183 calls filename a suggested name for storing a detached body part. A receiving mail agent may use it, but must not use it blindly. Directory information should be ignored, leaving at most the final path component. The receiver must consider whether the proposed name overwrites an existing file, names a special or system location, lands an executable in a search path, or invokes a pipe. A file should not be named or placed so that it executes without a separate, explicit action by the user.

Those warnings remain necessary after perfect reassembly. A valid UTF-8 value can still contain ../, an absolute path, control characters, a misleading extension, a reserved device name or characters that render deceptively. Percent decoding does not sanitise any of them. Charset decoding does not prove who sent the message. A parameter called filename does not authenticate the declared media type, and neither field authorises a launcher to run the bytes.

The control boundary is therefore layered. The MIME parser determines whether the continuation is structurally coherent. The decoder determines which text the octets represent. A filename policy selects or constructs a safe local name. The storage layer chooses a confined destination without unintended overwrite. The user or a separately authorised policy decides whether content may be opened or executed. Passing one gate cannot substitute for the next.

The authorship line is also a protocol boundary

RFC 2231's header names Ned Freed and Keith Moore. Its immediate predecessor, RFC 2184, names the same two authors. That is the complete authorship record for this particular mechanism.

Patrik Fältström belongs to the wider history of Internet internationalisation, but not as an RFC 2231 co-author. RFC 3490, the original Internationalizing Domain Names in Applications specification, names Fältström with Paul Hoffman and Adam Costello. Folding that separate contribution into the authorship of MIME parameter continuations would blur exactly the kind of boundary standards documents are designed to preserve: adjacent work can share a problem space without sharing an author list or a protocol contract.

Freed's place in the larger MIME story is well documented. The IETF Datatracker records a long body of email and media-type work. Nathaniel Borenstein, remembering their collaboration, described how his interest in richer mail met Freed's focus on robustness and interoperability. RFC 2045 and RFC 2047 show that broader programme: structured Internet message bodies on one side, encoded non-ASCII message-header text on the other. RFC 2231 addressed the narrower parameter problem that remained.

That narrower scope is important. The document did not claim that every header could adopt a star suffix and acquire these semantics. A specification has to opt a parameter syntax into the convention. Nor did the work turn filenames into identity-bearing claims. It solved a representation and interoperability problem, while leaving content disposition and local safety to different rules.

HTTP kept the encoding idea and dropped the continuations

Later HTTP specifications make the separation easier to see. RFC 8187 carries forward the encoded-parameter form for HTTP header fields, with UTF-8 as the required character set, but excludes RFC 2231 continuations. HTTP did not need them. The family resemblance is real, yet the profile is deliberately smaller.

RFC 6266, defining Content-Disposition in HTTP, repeats the crucial status of a filename: advisory only. Recipients should discard path segments, keep control over the target directory, distrust extensions that can grant executable meaning, remove confusing control characters and handle special names. A server can propose a label; it cannot reach through the response and acquire authority over a client's filesystem.

This is the deeper legacy of the continuation design. Interoperability needs strict shared rules at the representation boundary: zero-based numbering, a complete sequence, one initial charset declaration and a deterministic decoding order. Security needs equal strictness about what those rules do not prove. A string can be reconstructed without becoming safe. Metadata can be meaningful without becoming sovereign.

Sources