Résumé

  • Le littéral IMAP d’origine était encadré par un nombre d’octets et inséré dans une commande. Après {n}, le client attendait une continuation + avant d’envoyer les données et la suite de la syntaxe.
  • LITERAL+ autorisa {n+} et supprima cette attente, mais obligea le serveur qui refusait un gros littéral à absorber les octets annoncés ou à rompre la connexion.
  • LITERAL- conserva le même marqueur tout en limitant cette initiative à 4096 octets. APPENDLIMIT publia séparément une politique globale ou propre à une boîte ; IMAP4rev2 intégra ensuite la forme restreinte.

Une ligne inachevée

Dans IMAP, CRLF ne suffit pas toujours à conclure une commande. Après A001 LOGIN {11}, la ligne physique est finie, mais la grammaire attend encore onze octets. Ceux-ci peuvent contenir eux-mêmes CR ou LF : seule la quantité annoncée fixe leur frontière. Puis l’analyse ordinaire reprend exactement au prochain octet, où peuvent apparaître un espace, un autre argument ou enfin la fin de commande.

RFC 2060 imposait au client d’attendre une requête de continuation pour un littéral envoyé au serveur. Le serveur pouvait, avant cette invitation, repérer une erreur dans le préfixe et répondre BAD. Le client n’avait alors introduit aucune donnée indésirable dans le flux. RFC 3501 a maintenu cette règle.

Le + ne validait pas l’opération entière. Il signifiait seulement : « je suis prêt pour cette continuation ». Une boîte pouvait encore être interdite, un quota dépassé ou un argument ultérieur incorrect. Même {0} demandait cette permission. L’attente représentait donc une autorité de protocole, non le délai nécessaire pour transporter une charge utile.

Il serait trompeur d’y voir la fenêtre TCP. Le transport règle la capacité d’un flux d’octets ; il ignore les verbes IMAP et les boîtes. La continuation plaçait un veto applicatif à l’intérieur d’une seule construction syntaxique.

L’optimisation d’un caractère

Publié en janvier 1997, RFC 2088 ajouta la capability LITERAL+. Si le serveur l’annonçait, le client pouvait écrire {11+} et envoyer immédiatement les onze octets. Sans annonce, la forme synchronisée restait obligatoire.

La commande demeurait déterministe. Le serveur devait reconnaître, en fin de ligne, l’accolade, le nombre et le plus, puis compter exactement les octets suivants avant de reprendre la syntaxe de la même commande. LITERAL+ ne transformait ni le littéral en message séparé ni CRLF en délimiteur de sa charge. Il retirait seulement la conversation intermédiaire.

Le bénéfice augmentait avec la latence et le nombre de littéraux. L’exemple du RFC enchaîne deux chaînes dans LOGIN sans deux attentes. La négociation protégeait en même temps les anciens serveurs : le client n’obtenait le droit d’anticiper qu’après l’annonce explicite du récepteur.

Mais une permission générale est aussi un engagement de ressources. Le texte de 1997 ne connaissait aucun problème de sécurité. L’expérience ultérieure a montré que le point supprimé était précisément celui où un serveur pouvait encore refuser avant de recevoir le coût.

Refuser des octets déjà autorisés

RFC 7888, en 2016, décrit le dilemme. Avec LITERAL+, un client peut annoncer un littéral non synchronisé très grand et commencer immédiatement. Si le serveur le juge inacceptable, il peut lire et jeter les octets avant de rejeter la commande. Il préserve ainsi l’alignement du flux, mais dépense bande passante et travail. Ou bien il envoie BYE et ferme la connexion, imposant reconnexion et reprise.

Un BAD ou un NO envoyé tôt ne retire pas les données que le client avait le droit d’émettre. Pour continuer sur le même flux, le récepteur doit savoir où elles se terminent. Le nombre qui rend le cadrage précis rend aussi le coût impossible à ignorer.

APPEND concentre l’exposition : ce verbe peut transporter un message entier. Des limites de taille protègent mémoire, stockage et traitement, alors qu’une pièce jointe peut être déjà en route. Le gain de latence du client devient le budget de refus du serveur.

Le plafond de LITERAL-

RFC 7888 remplaça RFC 2088 et définit deux contrats. LITERAL+ garde les littéraux non synchronisés sans plafond propre à l’extension. LITERAL- les limite à 4096 octets ; au-delà, {n} et une continuation redeviennent obligatoires.

Le fil ne porte pas {n-}. Il porte toujours {n+}. C’est la capability annoncée qui donne au plus son étendue. Un serveur ne doit donc pas annoncer LITERAL+ et LITERAL- simultanément.

Cette solution conservait trois propriétés : une grammaire courte, la compatibilité de la forme synchronisée et l’économie d’un tour pour les petites chaînes. Elle réintroduisait le consentement avant les données importantes. Les 4096 octets ne sont pourtant ni un quota ni une promesse. Un petit APPEND peut échouer ; un gros peut réussir après continuation.

Le plafond ne ferme pas toute attaque. De nombreux petits littéraux, des analyses coûteuses ou des reconnexions répétées restent capables de consommer des ressources. Le RFC dit que LITERAL- améliore seulement en partie le risque de déni de service.

APPENDLIMIT n’était pas le même nombre

Le RFC 7889, publié le même mois, permet au serveur d’annoncer la taille maximale d’un message APPEND. APPENDLIMIT=<nombre> exprime une limite commune. Une capability sans valeur renvoie le client vers STATUS ou LIST-STATUS pour connaître une limite par boîte, éventuellement NIL.

Cette information évite un envoi condamné d’avance. Elle ne réserve rien. ACL, quota ou autre règle peuvent encore refuser un message plus petit. Le RFC conseille d’éviter les littéraux non synchronisés pour APPEND quand la limite demeure inconnue.

Les deux seuils répondent donc à deux autorités. 4096 borne une liberté syntaxique universelle sous LITERAL-. APPENDLIMIT expose une politique opérationnelle susceptible de varier d’une boîte à l’autre. Les confondre ferait d’une règle de cadrage un faux quota, ou d’un quota local une fausse règle commune.

Une extension devenue grammaire de base

RFC 9051 a intégré en 2021 la discipline LITERAL- dans IMAP4rev2. Une chaîne peut être citée, synchronisée ou non synchronisée. Sauf extension contraire, la dernière forme reste limitée à 4096 octets. Le protocole moderne n’a donc pas aboli l’attente : il l’a conservée là où le droit de refuser avant réception a encore de la valeur.

Le registre IANA contient LITERAL+, LITERAL- et APPENDLIMIT. Il fixe les références et les noms, pas leur déploiement actuel.

La trajectoire historique ne va pas de la lenteur vers la vitesse, puis vers la prudence. Elle va d’une décision prise à chaque littéral à une délégation négociée, puis à une délégation bornée et complétée par une information de politique. Chaque étape précise qui peut engager les prochains octets et qui assumera leur refus.

Sources et limites

Ces textes n’établissent ni adoption présente, ni gain mesuré, ni fréquence d’abus. Une continuation n’est pas une acceptation finale, 4096 n’est pas un quota, et APPENDLIMIT ne garantit pas la réussite d’un message plus petit.