Zusammenfassung

  • RESERVE machte einen Mailboxnamen für weitere Ansprüche nicht mehr verfügbar; RFC 3656 sagte ausdrücklich, dass die Mailbox dadurch noch nicht für Clients bereitstand.
  • Erst MAILBOX bezeichnete einen aktiven, zugänglichen Eintrag – nach lokaler Erstellung und ACTIVATE. Die Reihenfolge wurde empfohlen, aber von kooperierenden Teilnehmern getragen und nicht als Server-Voraussetzung erzwungen.

Erst der Name, dann die Mailbox

Ein Verbund von Mailservern muss zwei verschiedene Fragen beantworten: Welcher Server beansprucht den Namen, und kann ein Client die Mailbox jetzt benutzen? RFC 3656, im Dezember 2003 als Experimental-Protokoll veröffentlicht, stellte dafür getrennte Antworten bereit. MUPDATE sollte IMAP- und POP3-Servern einen gemeinsamen Mailbox-Namensraum geben, während mehrere Maschinen die Zustellung teilten.

Der typische Ablauf begann mit RESERVE. Ein Client bat den Master, einen Mailboxnamen an einem angegebenen Ort zu reservieren. Nach dem OK legte der Client die Mailbox lokal an und sandte anschließend ACTIVATE mit Name, Ort und ACL. Erfolgreiche Aktivierung machte den Datenbankeintrag aktiv. Der Ort konnte zum speichernden Server führen; die ACL beschrieb die Zugriffsrechte.

Die Antworten markieren die Grenze. RESERVE bedeutet, dass ein anderer Anspruchsteller den Namen nicht mehr nehmen kann. RFC 3656 stellt jedoch ausdrücklich klar, dass die Mailbox damit noch nicht für Clients verfügbar ist. MAILBOX bezeichnet einen für den Zugriff bereiten Eintrag. Wer beides gleichsetzt, macht aus einer Namenssperre ein falsches Verfügbarkeitssignal: Das lokale Objekt kann noch fehlen oder der Erstellungsschritt noch laufen.

Atomarität war gemeinsame Disziplin

MUPDATE beschreibt einen einzelnen Master mit der maßgeblichen Datenbank und Slaves, die sie replizieren. Clients können bei beiden suchen; Änderungen an der Datenbank sollen an den Master gehen. Die Erstellung berührte also zwei Oberflächen: das verteilte Namensregister und den lokalen Mailbox-Speicher. Das Protokoll koordinierte sie, verschmolz sie aber nicht zu einer einzigen atomaren Transaktion.

Die normative Formulierung macht das sichtbar. Neue Mailboxen SHOULD vor der Aktivierung reserviert werden, weil das Design kooperierende authentifizierte Teilnehmer voraussetzt, um atomare Operationen zu erhalten. Trotzdem verlangt ACTIVATE keine vorherige Reservierung. Die Spezifikation erlaubt das, um die Synchronisierung mit dem tatsächlichen Mailbox-Ort zu vereinfachen. Wer die gemeinsame Sperrkonvention umgeht, kann einen inkonsistenten Datenbestand erzeugen. Die Datenbank kann keine lokale Transaktion ableiten, die ihr niemand gemeldet hat.

DEACTIVATE setzte einen aktiven Namen in den reservierten Zustand zurück; es löschte den Namen nicht aus dem Namensraum. RFC 3656 warnte zudem, dass bekannte ACL-Informationen dabei verloren gehen können. Bei einer Migration oder abgebrochenen Erstellung kann der Name also weiter belegt sein, ohne dass eine aktive Mailbox angekündigt wird. Der gespeicherte Ort beweist weder einen erfolgreichen Login noch das Lesen von Nachrichten.

Das OK einer Replica hatte eine Grenze

Nach einem UPDATE erhielt der Slave zunächst eine vollständige Liste und danach spätere Änderungen als Stream. Der Master musste eine Änderung innerhalb von 30 Sekunden an den Slave senden. Der Slave konnte NOOP ausgeben; nach UPDATE durfte dessen OK erst kommen, wenn alle zum NOOP-Zeitpunkt ausstehenden Änderungen gesendet waren. Das setzte einen begrenzten Synchronisationspunkt – keine Garantie, dass die Datenbank danach global aktuell blieb.

Das ist ein nützlicher, aber enger Beleg: Der bis dahin offene Strom erreichte eine bestimmte Replica zu einem Zeitpunkt. Er beweist weder den Eingang einer späteren Änderung noch den Zustand des lokalen Speichers oder den Zugriff eines Endnutzers. RFC 3656 ist Experimental und beschreibt einen vorgeschlagenen Koordinationsvertrag, keine heutigen Deployments oder gemessene Verfügbarkeit.

Quellen