Resumo

  • Aceitar um servidor antigo era uma escolha de implementação; a RFC 2061 não transformava adaptações em equivalência integral.
  • Uma busca podia exigir compensação de estado, enquanto o sucesso de uma cópia não assegurava a preservação de seus metadados.

Uma prévia pode entregar o trecho solicitado e, ainda assim, alterar a caixa postal. A substituição de BODY.PEEK[section] por BODY[section], acompanhada da eventual remoção de \Seen, expõe o problema central da RFC 2061: manter a conversa com software antigo não significava preservar todos os efeitos da operação original.

Uma escolha delimitada no tempo

Publicado em dezembro de 1996 por Mark Crispin, da University of Washington, o memorando informativo deixava a aceitação de software antigo a critério dos implementadores; suas adaptações não eram exigências do IMAP4. Descrevia o IMAP2bis como muito comum e amplamente distribuído com Pine, embora sem documento descritivo definitivo. Admitia lacunas e conhecimento informal acumulado: não oferecia participação de mercado medida nem diagnóstico do presente.

A base IMAP2 estava na RFC 1176, de agosto de 1990. A RFC 1730, de dezembro de 1994, especificava IMAP4; a RFC 2060, de dezembro de 1996, IMAP4rev1. Atender às duas versões exigia consultar ambas. A RFC 1732, de dezembro de 1994, abrangia variantes antigas mais diversas; a RFC 2061 restringia o foco ao IMAP2bis mais provável de ser encontrado, sem pretender cobrir tudo.

Reconhecer o caminho não certificava o destino

No roteiro da RFC 2061, CAPABILITY concluído com OK anuncia as variantes IMAP4 suportadas. Sem reconhecer nenhuma delas, o cliente trata o servidor como IMAP2bis; BAD indica IMAP2bis ou anterior. Trata-se de uma regra de encaminhamento para compatibilidade, não de identificação definitiva nem de prova sobre os comandos seguintes. Erros quaisquer, tempo esgotado ou falhas de segurança não equivalem a BAD.

As adaptações permitem três classes de análise editorial, não categorias formais do memorando:

Operação útil ou próxima do equivalente. LIST cede lugar a FIND ALL.MAILBOXES, cuja sintaxe e resposta lembram FIND MAILBOXES da RFC 1176; este último dificilmente forneceria informação útil. O * numa sequência vira a contagem recebida em EXISTS não solicitado. Isso não congela a caixa numa fotografia estável. São os caminhos descritos na RFC 2061.

Aproximação semântica. Extensões de SEARCH exigem reformulação na sintaxe da RFC 1176, possivelmente com várias buscas, sem garantia dos mesmos critérios ou conjuntos de caracteres. BODYSTRUCTURE vira o item BODY, não extensível; as seções HEADER, TEXT, MIME, HEADER.FIELDS e HEADER.FIELDS.NOT reduzem-se a números de seção. Essas substituições não fabricam a estrutura ou a seleção mais rica.

Ausência de equivalente. O item UID de FETCH, os comandos UID e CLOSE não têm equivalente funcional. LSUB, SUBSCRIBE e UNSUBSCRIBE não têm equivalente direto. Os antigos bboards eram outro conceito; a RFC 2061 desaconselha seus comandos em software novo, inclusive servidores que atendam clientes antigos.

Compensar não é deixar intacto

A RFC 2060 distingue BODY[section], que define implicitamente \Seen, de BODY.PEEK[section], que não o faz. A RFC 2061 propõe buscar e remover manualmente a marca quando necessário. Uma marca preexistente não deve ser apagada indiscriminadamente.

A consequência operacional é uma inferência: quando há alteração, a busca seguida de compensação produz uma sequência de escritas, sem garantir uma restauração atômica. A RFC 2060 admite mudanças por outros agentes e recomenda atualizações automáticas das marcas. Onde o estado é compartilhado e mutável, outro cliente pode observar a transição ou alterar a marca; a compensação pode desfazer essa alteração. Isso não estabelece uma corrida universal, uma política universal de compartilhamento ou um incidente documentado.

FLAGS.SILENT, +FLAGS.SILENT e -FLAGS.SILENT tornam-se os itens correspondentes sem .SILENT em STORE; o cliente ignora as respostas FETCH sem identificador de comando. Ignorá-las localmente não impede sua emissão nem elimina os efeitos observáveis no servidor ou por outros clientes.

Uma cópia confirmada ainda deixava perguntas

A RFC 2061 declara ambígua a preservação de marcas e datas internas em COPY: sua descrição de compatibilidade não permite saber o comportamento do servidor. O SHOULD de preservação na RFC 2060 não cria retroativamente um contrato para IMAP2bis. Sucesso não é recibo de preservação; testes por servidor evidenciam o caso observado, não uma regra universal. Também é preciso interpretar TRYCREATE num OK não solicitado separado, não dentro de NO, mantendo o contexto da falha: a indicação não transforma uma cópia fracassada em sucesso.

Na direção inversa, a RFC 2061 registra somente a incompatibilidade de barra invertida em cadeias entre aspas para um cliente IMAP2bis bem escrito diante de um servidor IMAP4. Recomenda literais quando há barra invertida ou aspas embutidas. A avaliação permanece restrita àquela qualificação e ao conhecimento do memorando.

A troca de AUTHENTICATE por LOGIN é igualmente um conselho histórico da RFC 2061, que não discute segurança. A RFC 8314, de janeiro de 2018, ao recomendar TLS para submissão e acesso ao correio eletrônico, delimita a leitura atual: a substituição antiga não autoriza texto claro nem redução de segurança. Isso tampouco comprova uso de TLS em 1996.

Duas lentes posteriores, não provas históricas

Em seu ensaio de 2026 sobre adoção voluntária, Lu Heng escreveu: “Non-adoption is not a violation.” A aplicação editorial aqui distingue aceitar um conjunto reduzido de funções de uma obrigação de emular tudo. No ensaio de 2025 sobre camadas de realidade, Lu Heng observou: “Most conflicts persist because participants mix these layers.” Aqui, a distinção ajuda a separar compatibilidade declarada de efeitos executáveis. Esses julgamentos posteriores não comprovam fatos históricos do IMAP nem as intenções de Mark Crispin.

Fontes e limites da evidência

Fonte Contribuição e limite
RFC 2061 Memorando central; adaptações, incertezas e alcance limitado.
RFC 2060 IMAP4rev1 de 1996; referência contemporânea de semântica.
RFC 1176 IMAP2 de 1990; não especificação definitiva do IMAP2bis.
RFC 1730 IMAP4 de 1994; distinto da revisão de 1996.
RFC 1732 Antecedente de compatibilidade com escopo mais amplo.
RFC 8314 Orientação da IETF sobre TLS em 2018; limite de segurança posterior.
Lu Heng sobre adoção voluntária Interpretação de coordenação, publicada em 2026.
Lu Heng sobre camadas de realidade Interpretação de 2025; não evidência de implementação IMAP.