Summary

  • MIME message/partial made every fragment a separately transportable message while id, number and total gave a receiving user agent enough common structure to attempt local reassembly.
  • The reassembled result inherited the inner entity's meaning. It was not merely a message containing another message, and most later-wrapper headers disappeared under deterministic merge rules.
  • A matching identifier and complete number range did not authenticate the sender, hash the content, prove identical duplicates or show that the result was displayed. Arrival evidence and semantic reality remained different layers.

The ceiling was local even when mail was global

SMTP did not define one universal maximum message size. Hosts, gateways and stores did. By 1989, RFC 1123 required mail software to send and receive at least 64K bytes, called a much larger limit highly desirable, and noted that users were already mailing documents of a megabyte or more. The requirement described a floor for conforming hosts, not a promise that every path shared the same ceiling.

That mismatch mattered because store-and-forward mail is a chain of local decisions. A sender could accept a large object, one relay could queue it, and a later gateway could refuse it. The object had one human meaning but encountered several administrative and technical thresholds. Raising one limit did not raise the others.

The early MIME designers could therefore choose between two broad strategies. They could demand that the entire mail system accept a larger indivisible unit, or they could define how an application-level object might travel inside smaller units already understood by the system. They chose the second as an optional media type. The network would carry messages; the receiving application would decide whether several messages could become one object.

MIME split the delivery unit from the semantic unit

RFC 1341, the first published MIME specification in June 1992, is remembered for media types, multipart bodies and transfer encodings. Its message/partial subtype made an equally important separation. A body marked with that type was a fragment of a larger message. The fragment travelled as a complete outer mail message even though its body was not the complete inner entity.

This was not the same as multipart/mixed. Multipart places several components inside one delivered message. message/partial placed one intended entity across several delivered messages. A multipart boundary described structure within one envelope; partial-message parameters associated envelopes after they had arrived independently.

The distinction moved the point of completion. An SMTP server could accept fragment three without possessing fragments one or two. A mailbox could store two wrappers without possessing the inner object. Only a user agent with an adequate local set could attempt reassembly. No intermediate record had to pretend that the whole already existed.

Three parameters formed a deliberately small common law

The mechanism used three Content-Type parameters. id was to be generated as close to world-unique as possible and grouped the fragments. number placed a fragment in sequence. total declared the number of fragments. Numbering began at one, not zero; parameter order had no significance.

The asymmetry around total was practical. Earlier fragments could omit it, though later revisions encouraged including it. The final fragment had to carry it. A sender might begin streaming a split object before knowing the final count, but by the last piece the receiver needed a declared stopping point.

Those fields described a proposed set. They did not certify it. Two wrappers with the same id could still conflict. Two copies of one number could contain different bytes. A malicious sender could announce an impossible total, withhold a piece, or collide deliberately with another set. The RFC supplied interoperable syntax, not a cryptographic digest, signer identity or global clearing house.

That narrowness was a feature. A receiving agent did not need an authority to grant the object existence. It needed deterministic local questions: Do the identifiers match? Is every number from one through the declared total present? Are duplicates consistent under local policy? Can concatenation at the required boundaries produce a valid MIME entity? The record enabled the test; the running parser supplied the result.

Reassembly removed the scaffolding

The important design choice was semantic transparency. When the fragments were put together, the result was a complete MIME entity with its own Content-Type. A split audio entity became audio again. It did not become a displayed wrapper whose content happened to be another message containing audio.

RFC 1521, the 1993 revision, preserved this rule while tightening several operational details. The outer message/partial form was temporary scaffolding. Its purpose was transport across a constrained path, not permanent promotion into the identity of the content.

That created two kinds of Message-ID-shaped evidence. Each outer wrapper could possess its own ordinary Message-ID and delivery trace because it was a real mail message. Inside the first fragment lay the headers of the entity being reconstructed, including its own Message-ID if present. The outer identifiers named deliveries. The inner identifier named the resulting message. Treating either as a substitute for the other would erase the difference between how the pieces travelled and what the receiver reconstructed.

The same separation applied to timestamps and Received fields. Fragment four might arrive first; fragment one might take the longest route. Those facts mattered to transport diagnosis, but they did not reorder the body. The number parameter governed concatenation. Arrival time was evidence about the path, not authority over semantic order.

The first wrapper and the inner message divided the headers

Reassembly required more than appending bodies. Every wrapper had ordinary mail headers, and blindly preserving all of them would create several competing senders, subjects, dates and delivery traces around one result. MIME therefore specified a merge law.

Fragmentation had to occur only at line boundaries. On reconstruction, ordinary headers from the first enclosing message were copied, but its Content-prefixed fields and the selected semantic fields Subject, Message-ID, Encrypted and MIME-Version were excluded. From the enclosed message, Content-prefixed fields plus those selected semantic fields were appended. Other inner headers were dropped. Headers from the second and subsequent enclosing messages were discarded from the reconstructed entity.

RFC 2046 states the resulting allocation clearly. The first wrapper provides the surviving outer context. The inner message provides its media description and selected identity-bearing fields. Later wrappers prove separate arrivals but do not vote on the final header block.

This makes fragment one more than the first byte range. It carries reconstruction context that later fragments cannot replace. A system that keeps bodies but expires the first wrapper may possess every data segment and still lack the specified header basis. A system that chooses the first-arriving wrapper instead of number=1 silently invents a different protocol.

The discarded headers are not worthless. They remain valuable in the raw wrappers for mail-flow analysis, queue timing and abuse investigation. They simply do not belong in the semantic entity produced by reassembly. Good evidence preservation keeps both views: immutable wrappers for provenance and a derived entity for use.

Different gateways forced the content into the lowest common envelope

MIME allowed message bodies to use encodings suited to transport, but message/partial faced a special trap. A message-type body could not simply be wrapped in base64 or quoted-printable at the outer level. If a binary inner message were split, every partial wrapper would require binary-capable transport. A gateway meeting only one fragment could not safely wait for the others, reassemble the entity and encode it, because the other fragments might travel through different gateways.

The rule therefore followed the weakest shared path. A message/partial entity had to use 7bit transfer encoding, and the inner entity could not depend on 8bit or binary encoding. RFC 2045 supplied the companion transfer-encoding framework; RFC 2046 applied the stricter constraint to partial messages.

This was a form of decentralised humility. No gateway was assumed to see the whole set. No relay was made the reconstruction sovereign. The sender had to prepare an inner representation that each independently routed fragment could carry. Interoperability came from a small common restriction rather than from granting one intermediary complete visibility.

The same humility explains nested fragmentation. Different transfer agents could use different size thresholds. After one set was reassembled, the result could itself be another message/partial entity. The specification explicitly permitted that outcome. A receiver had to recognize layers and repeat the local procedure rather than assume one grouping pass exhausted the history.

SIZE negotiated admission but did not perform reconstruction

By 1995, RFC 1870 gave SMTP a different response to the size problem. A server could advertise a fixed maximum through the SIZE extension, and a client could declare an estimated message size with MAIL before transferring the body. An obviously oversized transaction could fail before consuming the full path.

SIZE and message/partial should not be narrated as a simple replacement sequence. They acted at different layers. SIZE was a transport admission signal between an SMTP client and server for one message. message/partial was an application representation that associated several messages after delivery. A server's acceptance of a declared size did not guarantee final transfer or delivery, and it said nothing about whether a receiving user agent would reconstruct partial messages.

The later mechanism could reduce the reason to split on a known hop. It could not make heterogeneous downstream limits disappear, authenticate fragments or merge headers. One exposed a local ceiling earlier; the other defined how meaning could survive several accepted envelopes.

A complete set was still only the beginning of trust

An operator examining a partial-message incident needs at least three ledgers. The wrapper ledger records raw bytes, outer Message-ID, Received chain, arrival time, mailbox and disposition for every separately delivered message. The set ledger records normalized id, number, declared totals, duplicate conflicts, missing numbers and expiry decisions. The reconstruction ledger records the chosen fragment for each number, concatenation order, header merge, parser result, decoded media type and any further nested set.

Security judgments belong beside those ledgers, not inside the identifier. Authentication results can differ among wrappers. A complete numeric range can still carry hostile content. A parser can produce a valid MIME entity whose signature fails, whose media type is unsafe, or whose origin cannot be established. Display and user attention happen later still.

The design lesson reaches beyond old mail clients. Distributed systems often receive several records that claim to compose one object. A shared label can coordinate them, but it cannot manufacture the object, the authority behind it or the consequence of processing it. The common layer should state only the invariants needed for compatible reconstruction. Local running code must decide whether the available evidence satisfies them.