Zusammenfassung

  • Seit RFC 733 musste der erzeugende Host die Eindeutigkeit garantieren. Eine Überarbeitung erhielt eine neue ID; zusätzliche Transportspuren änderten die ursprüngliche Identität nicht zwingend.
  • In-Reply-To und References machten IDs zu Kanten eines Gesprächs. Netnews speicherte gesehene IDs an jedem Server und verwarf Wiederholungen, wodurch verteilte Schleifen lokal endeten.
  • Der Name war weder Signatur noch Inhalts-Hash. Netnews behandelte unterschiedliche Körper mit gleicher ID als einen Artikel; eine vorhersagbare Kennung konnte vorweggenommen werden und den erwarteten Artikel blockieren.

Andere Bytes, dieselbe Nachricht

Beim Transport setzt ein Relay ein Received-Feld voran. Die gespeicherte Folge stimmt nicht mehr bytegenau mit der Einlieferung überein, doch das Relay hat keine neue Fassung der Aussage verfasst. Die ursprüngliche Message-ID bleibt.

Ändert der Autor dagegen die beabsichtigte Aussage und veröffentlicht eine Revision, braucht sie eine neue Kennung, selbst wenn nur ein Satz abweicht. RFC 733 zog diese Grenze 1977: Eine ID bezeichnet genau eine Fassung oder Instanziierung; spätere Revisionen erhalten neue IDs. Für Eindeutigkeit haftet der erzeugende Host.

RFC 822 übernahm die Regel 1982. Der Wert sollte maschinenlesbar, nicht menschlich bedeutungsvoll sein. Er ist weder Betreffzusammenfassung noch Personenbeweis, sondern ein stabiler Griff für eine erklärte Version.

Einen Weltnamen lokal zusammensetzen

RFC 5322 verlangt globale Eindeutigkeit und verpflichtet den Generator, sie sicherzustellen. Eine zentrale Stelle, die pro Nachricht eine Nummer ausgibt, gibt es dennoch nicht.

Empfohlen wird geteilte Zuständigkeit: Rechts von @ steht eine Domainkennung, links ein Wert, den der Generator in diesem Bereich eindeutig hält, etwa aus Zeit und Sequenz oder Prozesswert. Global unterscheidbarer Namensraum plus lokales Buch ergibt einen globalen Namen ohne globale Transaktion.

Die Adressform ist begrenzt. Die rechte Seite ist kein Postfach, muss heute nicht auflösbar sein und belegt weder Domainkontrolle noch Autorenschaft. Auch die linke Seite trägt keine verlässliche Geschäftssemantik.

Der RFC macht Identität vom gemeinten Sinn abhängig. Spuren- und Resent-Felder können die Syntax verändern, ohne eine neue Nachricht zu schaffen. Ob die ID wechselt, entscheidet die beabsichtigte Botschaft des Absenders, nicht irgendein Byteunterschied. Message-ID ist daher weder Prüfsumme noch SMTP-Umschlagtransaktion.

Aus der Antwort wurde eine Kante

In-Reply-To trägt die ID der Elternnachricht. References übernimmt deren Vorfahren und hängt die Eltern-ID an. Software kann daraus ein Gespräch bilden, obwohl Teile über verschiedene Wege und Zeiten eintreffen.

Schon RFC 850 verlangte 1983, dass ein Usenet-Follow-up die References des Vorgängers verlängert. Leserprogramme sollten Artikel zu Gesprächen gruppieren und ein ganzes Gespräch ausblenden können, ohne die Newsgroup zu verlassen. RFC 1036 behielt dies bei.

Die Kante bleibt eine Behauptung. RFC 5322 weist darauf hin, dass viele Programme beim Rückwärtsgang ein einzelnes Elternobjekt annehmen; mehrere Eltern sind nicht vollständig definiert. References authentifiziert weder Autoren noch inhaltliches Verständnis.

Jeder Server machte den Namen zu Gedächtnis

Im Usenet-Flooding kann derselbe Artikel von mehreren Nachbarn eintreffen. Jede Ankunft weiterzuleiten würde Zyklen erhalten. RFC 1036 beschreibt die History: Jeder Host merkt sich Artikel nach Message-ID und verwirft eine erneut eintreffende ID sofort. Path spart zusätzlich Übertragung, doch die lokale Seen-ID-Liste genügt zum Schleifenbruch.

Kein Master erklärt die Verteilung global für fertig. Jeder Standort vergleicht den Namen mit seinem Gedächtnis und entscheidet, dass er den logischen Artikel schon aufgenommen hat. Eine menschliche Gesprächsreferenz wurde so zum Schlüssel verteilter Duplikatunterdrückung.

Gleicher Name schlug unterschiedlichen Inhalt

RFC 5536 formuliert den Preis: Artikel mit gleicher Message-ID gelten als derselbe Artikel, auch wenn Header oder Körper abweichen. Engere Syntax, Längenbegrenzung und unveränderte Groß-/Kleinschreibung erlauben einen einfachen Oktettvergleich. Die Eindeutigkeit gilt über E-Mail und Netnews hinweg.

Damit erhält eine Kollision Wirkung. Wer die ID eines künftigen Artikels vorhersagt und zuerst ein anderes Objekt einspeist, kann bewirken, dass das Ziel als bereits gesehen abgelehnt wird. RFC 5536 empfiehlt daher Unvorhersagbarkeit. Nicht ein Inhalts-Hash versagte; einen solchen gab es nicht. Der falsche Anspruch erreichte das verteilte Namensbuch zuerst.

Was der Name nie bewies

Message-ID löst Referenz, nicht Vertrauen. Sie signiert keinen Körper, authentifiziert From nicht, benennt keine SMTP-Transaktion, beweist kein Lesen und garantiert keine gleichen Bytes. Gleiche IDs können Kollisionen verbergen; verschiedene IDs denselben Text tragen.

Die begrenzte Rolle machte den Entwurf haltbar: Der Ursprung benennt, Transport ergänzt Spuren ohne Umbenennung, Mailsoftware baut Beziehungen, News-Server verwalten lokale History. Kryptografischer Beweis bleibt eine andere Schicht.

Quellen und Grenzen

Die geschlossene Kette umfasst RFC 733, RFC 822, RFC 850, RFC 1036, RFC 2822, RFC 5322 und RFC 5536. Sie messen keine heutigen Kollisionsraten, Provideralgorithmen, Verbreitung oder History-Fristen.