Resumo

  • O literal original era uma cadeia enquadrada por contagem dentro de um comando. Depois de {n}, o cliente aguardava + antes de enviar os octetos e o restante da sintaxe.
  • LITERAL+ autorizou {n+} sem a viagem de continuação, mas deixou o servidor entre drenar dados já permitidos e encerrar a conexão quando a carga era indesejada.
  • LITERAL- limitou a iniciativa a 4096 octetos sem mudar o marcador. APPENDLIMIT informou separadamente a política global ou por caixa, e IMAP4rev2 incorporou a forma limitada.

A quebra de linha não fechava o comando

Um literal pode carregar CR e LF; portanto, nenhum desses caracteres encerra sua carga. A contagem define exatamente o fim. Logo depois, o analisador volta ao comando que já estava em curso.

Em RFC 2060, A001 LOGIN {11} obrigava o emissor a aguardar uma solicitação de continuação. O servidor podia detectar erro no prefixo e responder BAD antes de receber a cadeia. RFC 3501 preservou o procedimento.

O + não aprovava LOGIN, APPEND ou o comando completo. Apenas abria a próxima etapa. Até {0} precisava dele, prova de que a pausa representava decisão e não tempo de transmissão.

Também não era controle de fluxo TCP. A janela do transporte administra buffer sem entender caixa postal ou argumento. A continuação era um limite de admissão no nível da aplicação.

O direito anunciado em CAPABILITY

RFC 2088, de janeiro de 1997, criou LITERAL+. Um servidor que anunciasse a capability aceitava {n+}. O cliente não esperava resposta e já enviava os n octetos.

A gramática continuava contada. O servidor precisava reconhecer o marcador no final da linha, consumir a quantidade exata e retomar os argumentos do mesmo comando. O ganho estava em remover uma volta pela rede, não em criar uma mensagem independente.

Sem capability, a forma antiga permanecia. Essa regra localizava a inovação: o servidor voluntariamente delegava o consentimento, e o cliente só antecipava quando essa delegação era visível.

O texto de 1997 não registrou problemas de segurança. Anos de operação tornaram mais nítido um problema de recursos que não alterava o enquadramento correto, mas alterava quem arcava com o erro.

O servidor já queria recusar

RFC 7888 explica o impasse. Com LITERAL+, um literal enorme pode estar em trânsito quando o servidor decide que não o aceitará. Para preservar a sincronização, ele lê e descarta toda a quantidade. Para proteger recursos, pode enviar BYE e fechar.

BAD ou NO antecipados anunciam a decisão, mas não anulam os bytes autorizados pela capability. A opção de drenar desperdiça rede e processamento; a de fechar força reconexão e pode estimular novas tentativas.

APPEND amplia isso porque leva mensagens e anexos. Limites locais contra memória, armazenamento ou CPU encontram o cliente já transmitindo. O emissor economizou latência; o receptor recebeu a responsabilidade pelo descarte.

A fronteira fixa de LITERAL-

RFC 7888 substituiu RFC 2088 com dois contratos. LITERAL+ permite a forma não sincronizada sem limite próprio. LITERAL- permite apenas até 4096 octetos; acima disso, o cliente usa {n} e aguarda.

O marcador continua {n+}. O hífen só aparece no nome anunciado. Por isso o servidor não anuncia LITERAL+ e LITERAL- ao mesmo tempo: é a capability que diz se o mais tem alcance irrestrito ou pequeno.

4096 não é limite de mensagem. É limite para enviar sem nova permissão. Um APPEND menor pode falhar e um maior pode funcionar depois de sincronizar. Muitos pequenos literais ainda podem consumir recursos; o próprio RFC chama a melhora de parcial.

APPENDLIMIT tratou da política, não do enquadramento

No mesmo mês, RFC 7889 definiu APPENDLIMIT. O servidor pode anunciar uma capacidade máxima comum ou indicar que o cliente deve consultar cada caixa com STATUS ou LIST-STATUS.

Conhecer o valor evita uma tentativa grande já condenada. Ficar abaixo dele não garante sucesso: ACL, quota e outras condições permanecem. Quando o limite é desconhecido, o RFC recomenda não usar literal não sincronizado em APPEND.

O desenho mantém duas escalas honestas. LITERAL- fixa uma regra universal para iniciativa sintática. APPENDLIMIT comunica política local, possivelmente diferente por caixa. Uma não deve fingir ser a outra.

A forma limitada entrou no núcleo

RFC 9051 incorporou LITERAL- ao IMAP4rev2 em 2021. Cadeias sincronizadas, não sincronizadas e entre aspas são formas normais; salvo extensão, cargas acima de 4096 voltam a esperar.

O registro IANA mantém os três nomes. Isso confirma semântica padronizada, não adoção contemporânea.

A trajetória revela mais que uma otimização. O literal original conservava a decisão no receptor. LITERAL+ delegou-a ao cliente. LITERAL- limitou a delegação, e APPENDLIMIT forneceu evidência adicional para que um cliente cooperativo não começasse o que a política recusaria. Poupar uma viagem exigiu nomear quem ficava com a conta.

Fontes e limites

As fontes não medem suporte atual, economia real ou ataques. Continuação não é aceitação final, 4096 não é quota e APPENDLIMIT não promete êxito abaixo do valor.