Zusammenfassung

  • RFC 2449 ergänzte POP3 um CAPA, damit Clients Erweiterungen und Serververhalten strukturiert entdecken konnten, statt sich allein auf Probeaufrufe und natürlichsprachige Fehlermeldungen zu stützen.
  • Die Liste war an den Sitzungszustand gebunden. Sie bedeutete weder Berechtigung noch Erfolg und konnte sich durch Anmeldung, nutzerspezifische Richtlinien und Integritätsschutz ändern.

„Was kann dieser Server?“ klingt nach einer einzigen Frage. Bei POP3 hing die Antwort vom Zustand ab. Optionale Befehle, Authentisierungsverfahren und Serververhalten unterschieden sich; Clients lernten davon oft erst, indem sie Befehle ausprobierten, für Menschen formulierte Fehler deuteten oder Nutzer um Kompatibilitätseinstellungen baten. RFC 2449 erschien im November 1998 als Standards-Track-Aktualisierung von RFC 1939. Mit CAPA konnten Clients vor der Wahl einer Erweiterung ein maschinenlesbares Verzeichnis abfragen.

Dieses Verzeichnis wurde kein dauerhaftes Serverprofil. CAPA ist sowohl im Zustand AUTHORIZATION vor dem Login als auch in TRANSACTION danach verfügbar. Jede Fähigkeitsdefinition muss angeben, in welchen Zuständen sie angekündigt wird und in welchen ihre Befehle gültig sind. Eine vor der Anmeldung verfügbare Fähigkeit ist in beiden Zuständen anzukündigen; ihre Argumente können nach der Anmeldung trotzdem genauer werden. Kennung, Wert und dadurch mögliche Aktion sind verbundene, aber verschiedene Tatsachen.

LOGIN-DELAY und EXPIRE zeigen, weshalb der erste Wert vorsichtig sein kann. Variiert LOGIN-DELAY je Konto, muss der Server vor der Anmeldung das größtmögliche Intervall nennen und sollte danach für den angemeldeten Nutzer einen genaueren Wert liefern. EXPIRE bezeichnet eine garantierte Mindestaufbewahrungsdauer, nicht das Löschdatum einer bestimmten Nachricht. Wenn diese Dauer je Nutzer variiert, muss der Wert vor der Authentisierung die kleinstmögliche Dauer nennen; nach dem Login sollte er genauer werden. Solange der Server das Konto nicht kennt, schützt die breite Antwort vor einem zu günstigen Versprechen.

Die Anmeldung kann auch den Sicherheitskontext verändern. RFC 2449 empfiehlt eine erneute CAPA-Abfrage, wenn bei der Authentisierung eine Integritätsschicht ausgehandelt wird, damit Clients aktive Herabstufung erkennen können. RFC 5034 präzisiert die Grenze für SASL-Sicherheitsschichten: Der Client soll zuvor gelernte Serverinformationen einschließlich der alten Fähigkeitsliste verwerfen. Was außerhalb des geschützten Kontexts empfangen wurde, wird nicht automatisch zum Beleg innerhalb des neuen Kontexts.

Auch eine positive Liste garantiert nicht, dass jeder Nutzer jede Aktion ausführen darf. USER kündigt die Unterstützung von USER und PASS an, doch RFC 2449 warnt, dass diese Befehle nicht jedem Nutzer zur Verfügung stehen müssen. Ein angekündigter SASL-Mechanismus kann an Zugangsdaten oder lokaler Richtlinie scheitern; ein erfolgreicher Login kann den Zugriff auf das Postfach noch offenlassen. Antwortet CAPA mit -ERR, fehlt die Abfrage selbst und der Client muss wieder wie zuvor testen. Der neue Weg verringert Raterei, beseitigt aber die Unsicherheit älterer Server nicht.

RFC 2449 führte außerdem strukturierte Antwortcodes ein, damit Software Fehler nicht allein aus Fließtext ableiten musste. Unbekannte Details sind zu ignorieren, damit die gemeinsame Grundlage mit den Erweiterungen wachsen kann. Zugleich warnte der RFC, dass eine Fähigkeitsliste Authentisierungsverfahren offenlegt, während automatische Erkennung dem Client auch die Wahl eines stärkeren Verfahrens erleichtern kann. Lesbare Information hat operativen Nutzen und Offenlegungskosten.

Der Beitrag war also weder ein Versprechen austauschbarer POP3-Server noch das Ende aller Tests. Er grenzte ein, was ein Server in welchem Zustand und nach welchen Regeln einer Erweiterung behaupten darf. Die Liste unterstützt die nächste Entscheidung; was tatsächlich geschah, zeigen erst der nächste Befehl, seine Antwort und eine spätere Beobachtung des Postfachs. Der RFC-Status und ein IANA-Eintrag belegen keine universelle Umsetzung oder Verbreitung.

Quellen

RFC 2449; RFC-2449-Datensatz; Errata zu RFC 2449; RFC 1939; RFC 1957; RFC 5034; RFC 1734; RFC 4422; IANA-Register für POP3-Erweiterungen; RFC 2384; Heng Lu, Vorrang laufenden Codes; Heng Lu, minimale Anfangsspezifikation und freiwillige Einführung.