Zusammenfassung

  • Das ursprüngliche Literal war eine gezählte Zeichenfolge innerhalb eines IMAP-Befehls. Nach {n} wartete der Client auf +, bevor er die Oktette und die restliche Syntax schickte.
  • LITERAL+ erlaubte {n+} ohne diese Runde. Ein ablehnender Server musste nun bereits erlaubte Daten ablaufen lassen oder die Verbindung schließen.
  • LITERAL- behielt die Schreibweise, begrenzte das Senden ohne Einzelzustimmung aber auf 4096 Oktette. APPENDLIMIT veröffentlichte getrennt eine globale oder mailboxbezogene Upload-Regel; IMAP4rev2 übernahm die beschränkte Form.

Gezählt statt durch Zeilen getrennt

Ein Literal darf CR und LF enthalten. Sein Ende wird deshalb nicht gesucht, sondern gezählt. Nach exakt n Oktetten setzt der Parser denselben Befehl fort. Dort können Leerzeichen, weitere Argumente oder ein weiteres Literal stehen.

Nach RFC 2060 war A001 LOGIN {11} trotz CRLF unvollständig. Der Client musste eine Fortsetzungsanforderung abwarten. Erkannte der Server bereits im Präfix einen Fehler, konnte er BAD senden und weitere Befehlsdaten verhindern. RFC 3501 behielt das Verfahren bei.

Das + war keine endgültige Zusage. Spätere Syntax, Rechte oder Quoten konnten weiter scheitern. Selbst {0} musste warten: Die Grenze bezeichnete Entscheidungsgewalt, nicht Übertragungsdauer.

Auch mit TCP-Flusskontrolle ist sie nicht gleichzusetzen. Ein Empfangsfenster kennt keine Mailbox. Die IMAP-Fortsetzung ließ die Anwendung über einen syntaktischen Abschnitt entscheiden.

Das Plus als vorweggenommene Zustimmung

RFC 2088 definierte 1997 LITERAL+. Nach entsprechender Capability durfte der Client {n+} verwenden und sofort senden. Ohne Anzeige blieb {n} Pflicht.

Das Framing änderte sich nicht: Der Server erkannte den Marker am Zeilenende, las die genaue Menge und nahm danach die Befehlsgrammatik wieder auf. Eingespart wurde nur die Zwischenantwort. Bei hoher Latenz und mehreren Literalen konnte das mehrere Netzrunden aus einem Befehl entfernen.

Die Capability machte die Optimierung freiwillig. Der Server delegierte die Erlaubnis im Voraus, statt sie an jeder Grenze zu geben. Damit verschob er jedoch den Moment, in dem Ablehnung noch ohne Datenkosten möglich war.

Wenn das Nein zu spät kommt

RFC 7888 beschreibt zwei schlechte Wege. Ist ein nicht synchronisiertes Literal zu groß, kann der Server die angekündigten Bytes lesen, verwerfen und den Befehl ablehnen. Das wahrt die Stromgrenze, verbraucht aber Ressourcen. Oder er sendet BYE und schließt, worauf Reconnect und Wiederholung folgen können.

Ein früher BAD- oder NO-Status widerruft keine Bytes, die der Client aufgrund der Capability senden durfte. Besonders APPEND kann ganze Nachrichten und Anhänge tragen. Die Latenzersparnis des Senders wird zur Aufräumarbeit des Empfängers.

Eine Begrenzung ohne neue Drahtsyntax

RFC 7888 löste RFC 2088 ab und definierte LITERAL+ sowie LITERAL-. Unter LITERAL- dürfen nicht synchronisierte Literale höchstens 4096 Oktette groß sein. Größere müssen wieder {n} und die Fortsetzung nutzen.

Auf dem Draht steht weiterhin {n+}. Das Minus erscheint nur im Capability-Namen. Deshalb darf ein Server nicht beide Fähigkeiten zugleich anzeigen: Erst die Aushandlung bestimmt, ob das Plus unbeschränkt oder nur klein gilt.

4096 ist keine Mailboxquote. Es begrenzt nur das Recht zum sofortigen Senden. Ein kleiner APPEND kann scheitern, ein großer nach Zustimmung gelingen. Viele kleine Literale können weiterhin Arbeit summieren; die DoS-Verbesserung bleibt teilweise.

Eine zweite Grenze für die Mailbox

RFC 7889 führte APPENDLIMIT ein. Ein Server kann einen gemeinsamen Höchstwert anzeigen oder Clients per STATUS beziehungsweise LIST-STATUS mailboxspezifische Werte abfragen lassen.

Ein kooperativer Client vermeidet damit einen sicher zu großen Upload. Unterhalb des Werts bleiben ACL, Quote und weitere Fehler möglich. Ist der Wert unbekannt, rät der RFC bei APPEND von nicht synchronisierten Literalen ab.

Die Trennung ist Absicht. 4096 ist eine gemeinsame Syntaxgrenze der Delegation; APPENDLIMIT ist lokale, veränderliche Betriebspolitik. Eine minimale gemeinsame Regel bleibt deterministisch, während die Mailbox ihre Zukunftsentscheidung behält.

IMAP4rev2 behielt das Warten

RFC 9051 nahm 2021 LITERAL- in IMAP4rev2 auf. Oberhalb von 4096 wird normalerweise synchronisiert. Die moderne Basisspezifikation erklärte die Pause also nicht für überholt, sondern bewahrte sie vor größerem Ressourcenaufwand.

Das IANA-Register führt LITERAL+, LITERAL- und APPENDLIMIT. Es belegt Standardsbedeutung, nicht heutige Verbreitung.

Historisch wanderte das Recht, die nächsten Bytes festzulegen: vom einzelnen Serverentscheid zur vorab delegierten Initiative und weiter zur begrenzten Initiative mit separater Policy-Evidenz. Die eingesparte Runde musste jemandem als Ablehnungsrisiko zugerechnet werden.

Quellen und Grenzen

Die Quellen messen keine aktuelle Nutzung, Leistung oder Angriffe. Fortsetzung ist keine Endannahme, 4096 keine Quote und APPENDLIMIT keine Erfolgsgarantie.