Zusammenfassung

  • POP3 vergab Nachrichtennummern erst beim Öffnen des aktuellen Maildrops. LAST speicherte lediglich die höchste zuvor verwendete Nummer und konnte weder Lücken noch unterschiedliche Erinnerungen mehrerer Clients ausdrücken.
  • RFC 1725 entfernte LAST und ergänzte das optionale UIDL. RFC 1939 verlangte eine über Sitzungen beständige Kennung innerhalb eines Maildrops, überließ aber dem Client seinen Seen-Zustand und trennte diese Kennung von globaler Identität, Kopienzahl und Aufbewahrung.

Eine Kennung wird häufig nützlicher, wenn sie größer gedacht wird: weltweit statt lokal, dauerhaft statt sitzungsgebunden, eindeutig statt mehrdeutig. Bei POP3 UIDL wäre genau diese Aufwertung ein Fehler gewesen.

Der Server musste nicht beweisen, dass eine Nachricht im gesamten Internet einmalig war. Er musste einem intermittierend verbundenen Client nur ermöglichen, einen Eintrag aus dem heutigen Maildrop mit einem Eintrag aus der gestrigen Sitzung zu vergleichen. Dafür reichte eine Kontinuität, deren Geltungsbereich am Rand dieses Maildrops endete.

Die Begrenzung war keine Fußnote. Sie bestimmte, wie Clients Schlüssel bilden, Migrationen planen, identische Kopien behandeln und das Verschwinden einer Kennung interpretieren müssen.

Die Nummer entstand aus der gegenwärtigen Reihenfolge

RFC 1460 beschrieb POP3 für kleinere Arbeitsstationen und PCs, die kein dauerhaft laufendes Mail-Transportsystem unterhalten konnten. Ein Server hielt die Post in einem Maildrop. Der Client verband sich dynamisch, rief Nachrichten ab und löschte sie im normalen Modell anschließend.

Nachdem der Server den Maildrop geöffnet und zerlegt hatte, nummerierte er die erste Nachricht mit 1, die zweite mit 2 und so weiter. Diese Zahl war ein präziser Operand für LIST, RETR und DELE in der laufenden Transaktion.

Doch eine Position ist kein Name über zwei Ansichten hinweg. Verschwindet die frühere Nachricht 1, wird die bisherige 2 beim nächsten Öffnen zur 1. Neue Nachrichten und Löschungen verändern die Menge. Beide Nummern können jeweils korrekt sein, ohne dieselbe langfristige Bedeutung zu haben.

Die damalige Fassung kannte außerdem LAST. Der Server meldete die höchste Nachrichtennummer, auf die in früheren Transaktionen zugegriffen worden war. Höhere Nummern konnten als noch nicht gesehen gelten; RETR oder DELE einer höheren Position verschob die Grenze, RSET setzte sie auf null.

Ein Hochwassermarker kann nur eine zusammenhängende Vorgeschichte verdichten. Er kann nicht sagen, dass 1 und 3 lokal gespeichert wurden, 2 aber nicht. Zwei Clients mit verschiedenen Verläufen teilen sich dennoch einen Wert. Eine Löschung unterhalb der Grenze verändert die Positionen, auf denen sie beruhte.

RFC 1725 führte die beiden Änderungen in seiner Revisionsliste ausdrücklich nebeneinander: LAST wurde entfernt, UIDL optional hinzugefügt. Der Text behauptete keine ausschließliche Ursache. Mechanisch ersetzte jedoch ein Token pro Nachricht die Vorstellung, eine einzige serverseitige Fortschrittslinie könne jede Wiederkehr erklären.

UIDL verband den momentanen Operanden mit einer länger lebenden Kennung

Mit einer Nachrichtennummer gibt UIDL die aktuelle Nummer und die zugehörige unique-id zurück. Ohne Argument liefert es eine mehrzeilige Liste für alle Nachrichten, die nicht zur Löschung markiert sind.

Die beiden Spalten haben verschiedene Lebensdauern. Die Nummer sagt, welche Nachricht der Client jetzt abrufen oder markieren kann. Die UID erlaubt ihm, diesen Eintrag mit seinem lokalen Protokoll einer früheren Sitzung abzugleichen.

RFC 1939 definiert die UID als serverbestimmte Zeichenfolge aus einem bis siebzig druckbaren Zeichen. Sie identifiziert eine Nachricht innerhalb eines Maildrops und bleibt über Sitzungen bestehen. Das gilt auch dann, wenn die vorherige Sitzung nicht den Zustand UPDATE erreicht hat.

Ein abnormaler Abbruch macht diese Regel praktisch. Der Client kann eine Nachricht vollständig empfangen haben, bevor die Verbindung vor QUIT abreißt. Ohne UPDATE darf der Server markierte Nachrichten nicht entfernen. Der Eintrag erscheint wieder. Würde seine UID allein wegen des Abbruchs wechseln, sähe ein bereits gespeicherter Inhalt neu aus.

Der Server soll eine UID im selben Maildrop nicht wiederverwenden, solange der damit bezeichnete Eintrag existiert. Sonst könnte ein neuer Eintrag die Geschichte eines alten im Client-Ledger übernehmen.

Der vollständige Schlüssel lag nicht im Protokollfeld

Weil die UID nur innerhalb eines Maildrops gilt, muss ein Client sie zusammen mit Server- und Kontokontext speichern. Die gleiche Zeichenfolge in einem anderen Konto hat keine definierte Beziehung. Ein gemeinsamer Cache, der nur nach UID indiziert, vermischt getrennte Namensräume.

UIDL ist auch nicht das Nachrichtenkopf-Feld Message-ID. Es authentisiert weder Absender noch Empfänger, beweist weder Zustellung noch Integrität und erzeugt keine globale Inhaltsadresse.

Der Client ergänzt noch eine zweite Art von Information: was „gesehen“ für diese Anwendung bedeutet. Das kann erfolgreicher Empfang, dauerhaftes Speichern, Anzeige oder Archivierung sein. UIDL selbst hält keine gerätespezifischen Lesemarken.

Damit blieb der Server einfach. Er vergab eine begrenzte Kontinuität, während jeder Client sein eigenes Ledger führte. Die Kehrseite ist Wiederherstellungsrisiko: Verliert der Client seine Datenbank, lädt er alte Nachrichten erneut; ändert eine Migration die UIDs, sehen ganze Bestände neu aus; wird „verarbeitet“ vor dem sicheren Schreiben gesetzt, kann eine spätere Löschung den einzigen brauchbaren Inhalt vernichten.

uid_listed, retrieval_completed, stored_locally, delete_marked, update_committed und session_aborted müssen daher getrennte Zustände bleiben.

Eindeutig bedeutete nicht zwingend eine Kennung pro physischer Kopie

RFC 1939 bevorzugt im Allgemeinen gespeicherte, willkürlich vergebene Kennungen. Es erlaubt aber auch, eine UID als Hash der Nachricht zu berechnen. Clients müssen deshalb zwei identische Kopien in demselben Maildrop mit derselben UID behandeln können.

Ein lokaler Datensatz „eine UID, eine Zeile“ kann eine reale Kopie lautlos verschlucken. Zusätzlich zur zeitlichen Wiedererkennung braucht der Client die aktuelle Multiplizität und die zugehörigen Nummern. Die Kennung sagt nicht in jedem Fall, wie viele ununterscheidbare Speicherexemplare vorhanden sind.

Dieser Ausnahmefall zeigt, warum der Geltungsbereich als Beweisaussage behandelt werden muss. Das Wort unique darf nicht automatisch zu weltweit einmalig, eins-zu-eins oder kryptografisch stark erweitert werden. UIDL beantwortete eine schmalere Frage: Hält der Server diesen Eintrag im Maildrop für denselben wie zuvor?

Identitätsdauer und Speicherdauer waren verschiedene Verpflichtungen

Eine UID bleibt für einen vorhandenen Eintrag stabil; daraus folgt nicht, dass der Eintrag ewig vorhanden bleibt. RFC 1939 warnte, dass „leave on server“ Hunderte oder Tausende bereits gelesener Nachrichten ansammeln kann. Betreiber dürfen Quoten und Aufbewahrungsregeln anwenden und Nachrichten außerhalb eines POP3-Kommandos entfernen.

Wenn eine frühere UID fehlt, kann ein anderer Client gelöscht haben, eine Richtlinie kann abgelaufen sein oder die aktuelle Liste kann unvollständig sein. Abwesenheit allein beweist weder sichere lokale Speicherung noch eine ordnungsgemäß abgeschlossene Löschung.

RFC 2449 führte CAPA ein, weil optionale Funktionen zuvor oft nur durch Ausprobieren oder Konfiguration entdeckt wurden. Eine Zeile UIDL kündigt Unterstützung an. Sie bescheinigt weder die Qualität des Kennungsraums noch eine Aufbewahrungsfrist.

Dieselbe RFC definierte EXPIRE: Der Server kann eine Mindestzahl von Tagen, null oder NEVER angeben. Selbst diese Fähigkeit nennt keinen exakten Ablaufzeitpunkt für eine bestimmte Nachricht, weil der Betreiber die Frist etwa bei Ankunft, erster Auflistung oder Abruf beginnen lassen kann.

Fähigkeit, Wiedererkennung und Aufbewahrung sind getrennte Belege. CAPA sagt, dass das Kommando verfügbar ist. UIDL sagt, wie ein vorhandener Eintrag wiedererkannt wird. EXPIRE beschreibt eine Speicherpolitik. Keine Aussage ersetzt die andere.

Begrenzung machte die Kontinuität belastbar

UIDL synchronisierte keine Ordner und Flags, schlichtete keine Mehrgeräte-Konflikte und machte POP3 nicht zu IMAP. Es gab einem einfachen Abrufprotokoll nur die minimale Kontinuität, die für zurückgelassene Nachrichten nötig war.

Sein historischer Wert liegt gerade in der Grenze. Die Sitzungsnummer adressiert den aktuellen Eintrag. Die UID verbindet ihn mit einer früheren Ansicht desselben Maildrops. Das Client-Ledger dokumentiert die lokale Verwendung. Die Aufbewahrungsregel bestimmt, wie lange der Eintrag angeboten wird.

Wenn Implementierungen diese Ebenen nicht überdehnen, kann ein kleiner Namensraum zuverlässig sein. Die Nummer lebt für die Sitzung; die UID lebt lange genug für die Rückkehr; globale Identität war nie Teil des Versprechens.

Quellen