Zusammenfassung

  • Bei message/partial blieb jedes Fragment eine selbständig transportierte E-Mail. id bezeichnete die beabsichtigte Gruppe, number ihre Reihenfolge und total die erwartete Zahl der Teile.
  • Das zusammengesetzte Ergebnis erhielt die Semantik der inneren MIME-Entität. Header der ersten äußeren Nachricht und ausgewählte innere Header wurden nach festen Regeln verbunden; spätere äußere Header verschwanden aus dem abgeleiteten Objekt.
  • Eine lückenlose Nummernfolge bewies weder Absender noch Byte-Gleichheit, Integrität oder Anzeige. Die Felder beschrieben prüfbare Behauptungen, während erst der lokale Empfänger ein nutzbares Objekt erzeugte.

Ein Objekt, aber keine einheitliche Obergrenze

Für den Absender war ein Anhang eine Einheit. Im Store-and-forward-Netz traf er jedoch auf mehrere unabhängige Entscheidungen: Annahme, Warteschlange, Speicherplatz und maximale Nachrichtengröße. Ein Server konnte akzeptieren, obwohl ein späterer Gateway ablehnte. SMTP schrieb keine weltweit gemeinsame Obergrenze vor.

Der RFC 1123 beschrieb diese Lage 1989. Mailsoftware musste Nachrichten von mindestens 64 KByte senden und empfangen können; eine deutlich größere Obergrenze sei sehr wünschenswert. Zugleich erkannte der Text Implementierungsgrenzen und bereits versandte Dokumente von einem Megabyte oder mehr an. Die Vorgabe setzte einen Boden, keine Ende-zu-Ende-Zusage.

Eine Lösung, die alle Zwischenstationen gleichzeitig zu größeren Einheiten zwang, hätte das heterogene Internet wie ein zentral verwaltetes System behandelt. MIME beließ daher die bekannte Transporteinheit und trennte sie von der Bedeutungseinheit. Mehrere vollständige Nachrichten konnten eine größere innere Entität tragen. Ob diese Entität tatsächlich vorlag, entschied erst der Empfänger mit den Fragmenten vor sich.

Außen vollständig, innen nur ein Ausschnitt

Der im Juni 1992 veröffentlichte RFC 1341 definierte message/partial. Der Body einer solchen äußeren Nachricht enthielt ein Fragment einer größeren Nachricht. Die Hülle selbst war dennoch eine wirkliche Mail mit eigener Message-ID, Received-Kette, Ankunftszeit und Zustellentscheidung.

Das unterschied den Typ von multipart/mixed. Multipart bündelt mehrere Teile in einer Zustellung. Partial verteilt eine beabsichtigte Entität auf mehrere Zustellungen. Teil 4 durfte vor Teil 1 eintreffen und eine andere Route nehmen; seine logische Position blieb trotzdem 4.

Damit blieb die Reichweite jedes Datensatzes begrenzt. Die SMTP-Annahme eines Fragments dokumentierte dessen Annahme. Drei Hüllen im Postfach dokumentierten drei gespeicherte Nachrichten. Keine Zwischenstation musste so tun, als besitze oder bestätige sie bereits das Ganze.

Drei Parameter koordinierten, ohne zu beglaubigen

id verband die Teile und sollte möglichst welt-eindeutig erzeugt werden. number gab die Position an und begann bei 1. total nannte die erwartete Gesamtzahl. Die Reihenfolge der Parameter im Content-Type war ohne Bedeutung.

Im letzten Fragment war total zwingend. Frühere Fragmente durften es auslassen, spätere Fassungen empfahlen jedoch die frühzeitige Angabe. So konnte eine Aufteilung beginnen, bevor ihre endgültige Zahl feststand; wer den letzten Teil bezeichnete, musste dem Empfänger aber ein prüfbares Ende mitteilen.

Der RFC 1521 übernahm den Mechanismus 1993 und präzisierte seine Betriebsbedingungen. Aus id wurde dennoch kein Inhalts-Hash. Zwei Exemplare derselben Nummer konnten unterschiedliche Bytes enthalten. Eine Kennung konnte versehentlich wiederverwendet, eine Gesamtzahl widersprüchlich angegeben werden. Die Werte beschrieben eine vorgeschlagene Menge, nicht deren Echtheit.

Der Empfänger musste die Folge von 1 bis total prüfen, Dubletten nach einer lokalen Regel behandeln, widersprüchliche Grenzen ablehnen, Ressourcen begrenzen und das Ergebnis als MIME parsen. Die gemeinsame Spezifikation machte die Entscheidung reproduzierbar. Sie nahm sie dem laufenden Programm nicht ab.

Nach dem Zusammensetzen galt wieder das Innere

Das Resultat war eine vollständige MIME-Entität mit eigenem Content-Type. Ein aufgeteiltes Audioobjekt sollte wieder als Audio erscheinen, nicht dauerhaft als Nachricht, die eine Nachricht mit Audio enthält. Die partielle Verpackung war semantisch transparent und diente nur dem Transport.

Dadurch entstanden zwei Identitätsebenen. Jede äußere Nachricht konnte eine eigene Message-ID haben, weil sie separat reiste. Die innere Nachricht konnte eine andere Message-ID besitzen, die zur rekonstruierten Entität gehörte. Außenkennungen bezeichneten Zustellereignisse; die Innenkennung bezeichnete das Ergebnis. Ihre Gleichsetzung hätte Weg und Objekt verwechselt.

Auch Ankunftszeit bestimmte nicht die Reihenfolge. Wenn Nummer 3 zuerst eintraf, war das wertvolle Transportinformation. Zusammengesetzt wurde trotzdem nach number. Eine Beobachtung des Netzes erhielt keine Autorität über die semantische Ordnung.

Teil eins trug auch die Header-Grundlage

Bloßes Aneinanderhängen der Bodys reichte nicht, denn jede Hülle brachte potenziell widersprüchliche Header mit. MIME erlaubte die Aufteilung deshalb nur an Zeilengrenzen und legte eine asymmetrische Zusammenführung fest.

Aus der ersten äußeren Nachricht wurden gewöhnliche Header übernommen, jedoch keine Content-Header und auch nicht Subject, Message-ID, Encrypted oder MIME-Version. Aus der inneren Entität kamen Content-* sowie genau diese ausgewählten Felder. Andere innere Header wurden verworfen. Sämtliche Header der zweiten und späteren äußeren Nachrichten fehlten im rekonstruierten Ergebnis.

Der RFC 2046 stabilisierte diese Aufteilung 1996. Die Hülle mit number=1 stellte den verbleibenden äußeren Kontext. Das Innere stellte Medientyp und ausgewählte semantische Felder. Spätere Hüllen blieben Belege separater Wege, bekamen aber keine Stimme im endgültigen Header.

Der erste Teil war deshalb mehr als das erste Byte-Intervall. Wer seine Hülle früh löschte und nur Body-Stücke behielt, konnte alle Datenbereiche besitzen und trotzdem die normgerechte Header-Basis verlieren. Wer stattdessen die zuerst eingetroffene Hülle nahm, ersetzte die Nummernregel durch einen lokalen Zufall.

Ein prüfbares System bewahrt beides: unveränderte Hüllen für Zustell- und Authentifizierungsfragen sowie die abgeleitete Entität für die Anwendung. Nur das saubere Ergebnis zu speichern, lässt eine lokale Konstruktion später wie eine ungeteilte Zustellung aussehen.

Verschiedene Gateways erzwangen 7bit als gemeinsamen Nenner

8bit- oder Binärdaten stellten ein besonderes Problem dar. Ein Body vom Typ message ließ sich außen nicht einfach mit base64 oder quoted-printable versehen. Wurde eine binäre innere Nachricht geteilt, verlangte jedes Partial binärfähigen Transport. Ein 7bit-Gateway, das nur ein Fragment sah, konnte nicht auf alle anderen warten, sie zusammensetzen und neu kodieren; die übrigen konnten andere Gateways passieren.

Darum musste message/partial 7bit-Transferkodierung verwenden, und das Innere durfte nicht von 8bit oder binary abhängen. Der RFC 2045 lieferte den allgemeinen MIME-Kodierungsrahmen; RFC 2046 zog für Partial-Nachrichten die engere Grenze.

Die Regel erkannte an, dass kein Vermittler die Gesamtansicht besaß. Der Sender musste eine Darstellung wählen, die jeder unabhängige Weg tragen konnte. Die gemeinsame Schicht blieb restriktiv, anstatt einen vermeintlich allwissenden Rekonstruktions-Gateway zu schaffen.

Unterschiedliche Schwellen führten außerdem zu verschachtelter Fragmentierung. Nach einer Rekonstruktion durfte das Ergebnis erneut message/partial sein. Die Spezifikation erlaubte das ausdrücklich. Ein Empfänger wiederholte den Vorgang pro Ebene, musste Tiefe und Aufwand aber lokal begrenzen.

SIZE verhandelte Annahme, nicht Bedeutung

Der RFC 1870 führte 1995 die SMTP-Erweiterung SIZE ein. Ein Server konnte seine feste Obergrenze ankündigen, ein Client vor dem Body eine geschätzte Größe nennen. Eine vorhersehbare Ablehnung wurde dadurch früher möglich.

SIZE und message/partial beantworteten verschiedene Fragen. SIZE betraf eine Nachricht zwischen SMTP-Client und -Server. Partial betraf mehrere zugestellte Nachrichten im Benutzeragenten. Eine positive SIZE-Antwort garantierte weder den späteren Transfer noch die endgültige Zustellung und schon gar keine Rekonstruktion.

Das eine Verfahren machte eine lokale Grenze sichtbar. Das andere bewahrte eine Entität über mehrere Grenzen hinweg. Es handelt sich nicht um einen bloßen Ersatz in der Chronologie, sondern um zwei getrennte Kontrollflächen.

Drei Protokolle bewahren die widersprüchliche Wirklichkeit

Das Hüllenprotokoll enthält Rohbytes, äußere Message-ID, Received, Ankunft und Behandlung jeder Nachricht. Das Mengenprotokoll enthält normalisierte id, Nummern, Gesamtangaben, Lücken, widersprüchliche Dubletten und Ablauf. Das Rekonstruktionsprotokoll enthält die gewählte Variante je Nummer, Reihenfolge, Header-Fusion, Parsergebnis, Medientyp und weitere Partial-Ebenen.

Herkunft, Integrität und Sicherheit bleiben gesonderte Urteile. Eine numerisch vollständige Menge kann gefährlichen Inhalt tragen. Authentifizierungsergebnisse können sich zwischen Hüllen unterscheiden. Ein erfolgreiches MIME-Parsing beweist weder eine Signatur noch Anzeige oder menschliche Kenntnisnahme.

Die Architektur funktionierte, weil ihre Kennung wenig behauptete. Sie koordinierte autonome Systeme, ohne ein zentrales Wahrheitsregister zu errichten. Der Datensatz beschrieb eine Beziehung; der lokale Code prüfte sie; erst das tatsächlich erzeugte Objekt durfte in den nächsten Zustand übergehen.