Resumo

  • O RFC 3516 permitiu ao servidor remover o Content-Transfer-Encoding de uma seção MIME e entregar os octetos decodificados por BINARY, inclusive NUL em literal8. Essa era uma visão transformada, não a serialização original da mensagem.
  • Tamanho e deslocamentos parciais pertenciam aos dados decodificados. Armazenamento, FETCH BODY, CRLF textual, cabeçalhos codificados e operações criptográficas continuavam com fronteiras próprias.

Base64 tornou possível levar conteúdo arbitrário por caminhos de correio incapazes de preservar qualquer octeto. Na leitura por IMAP, porém, o cliente podia baixar uma representação maior apenas para desfazê-la imediatamente. O RFC 3516 tratou essa sobrecarga como custo concreto em rádio lento e mídia contínua.

Publicado em abril de 2003, o IMAP4 Binary Content Extension deslocou a decodificação para o servidor. Ao anunciar BINARY em CAPABILITY, o servidor aceitava FETCH BINARY, removia a codificação de transferência da seção selecionada e enviava o resultado. A resposta poupava bytes no enlace, mas não recuperava automaticamente a sequência original da mensagem.

Toda seção de corpo IMAP possui um Content-Transfer-Encoding, explícito ou implicitamente 7bit. No MIME, o CTE define tanto a transformação inversa quanto o domínio dos dados decodificados. Base64 e quoted-printable alteram a representação. Um CTE identidade pode não exigir cálculo e ainda assim produzir valores, como NUL, que o literal original do IMAP não consegue transportar.

Por isso o RFC descreveu duas etapas lógicas. Primeiro o servidor executa a decodificação relacionada ao CTE. Depois determina o domínio do resultado. Ter uma sequência de octetos ainda não informa qual elemento do protocolo pode carregá-la.

O novo literal8 ampliou esse domínio. Sua sintaxe usa til e contagem antes de octetos arbitrários, inclusive NUL. Quando os dados cabem no domínio de oito bits e não contêm zero, o servidor deveria preferir a string ordinária. O formato externo então informa a restrição sem obrigar o cliente a varrer o fluxo inteiro.

A contagem é prova da extensão daquele elemento na resposta, não do modo de armazenamento. Ela não diz se a carga já estava decodificada no disco, se foi recriada de base64 naquele instante, se finais de linha foram ajustados ou se o servidor mantém outra forma interna compatível.

BINARY.PEEK separou o estado da caixa. Ele solicita a mesma visão sem marcar implicitamente a mensagem com \\Seen. Preservar o estado não lido é uma garantia operacional útil, mas não demonstra proveniência. O conteúdo ainda é a visão decodificada pelo servidor.

BINARY.SIZE retorna o número de octetos esperado no FETCH BINARY correspondente. Não mede o corpo codificado, o espaço físico ocupado, a mensagem completa nem o arquivo renderizado. A especificação alertou que o cálculo poderia ser caro quando a implementação precisasse decodificar tudo só para contar.

Nos pedidos parciais, a referência muda. Offset e quantidade apontam para a seção decodificada. Uma posição dentro do texto base64 ou do resultado de FETCH BODY não identifica necessariamente o mesmo trecho. Reaproveitar o ponto de retomada de outra representação pode gerar resposta válida começando no lugar lógico errado.

Se o servidor não soubesse decodificar o CTE, ele não poderia adivinhar. BINARY e BINARY.SIZE deveriam falhar com NO [UNKNOWN-CTE]. O recibo prova incapacidade diante daquela regra, não corrupção do conteúdo.

O RFC 4466 atualizou depois o mecanismo de códigos de resposta, e o RFC 9051 incorporou a extensão ao IMAP4rev2. Essas versões importam na leitura de um traço moderno. Nenhuma tornou idênticos corpo codificado, seção decodificada e forma armazenada.

Cabeçalhos tinham outro tipo de codificação. Os encoded-words do RFC 2047 levam texto não ASCII a certas posições de cabeçalho; não são CTE de corpo. O RFC 3516 proibiu convertê-los durante BINARY FETCH ou APPEND. A ordem de decodificar uma seção não autorizava reescrever toda sequência parecida com código.

Texto orientado a linhas recebia ainda uma normalização definida. O servidor devia usar terminações CRLF do IMAP, independentemente de como guardava o texto. Isso estabilizava a interface, mas fazia da resposta uma prova inadequada dos bytes locais de quebra de linha.

A fronteira de armazenamento era expressa. Um servidor podia guardar o conteúdo binário sem codificação. Mesmo assim, BODYSTRUCTURE tinha de descrevê-lo como se usasse um CTE aceito pelo IMAP base, e FETCH BODY precisava produzir essa representação. A interface era contrato de interoperabilidade, não exposição de disco.

APPEND atravessava o caminho contrário. Um cliente podia submeter dados com NUL por literal8. Sem armazenamento binário, a caixa deveria rejeitar com UNKNOWN-CTE. Com suporte, o servidor podia trocar o CTE, desde que a transformação não perdesse a carga útil.

Não perder a carga não preserva necessariamente a mensagem serializada. Base64, quoted-printable e representação direta podem recuperar o mesmo conteúdo a partir de octetos diferentes. Rótulo CTE, dobramento de cabeçalhos e finais de linha pertencem à serialização. Uma mudança fiel ao conteúdo ainda pode invalidar um hash ou uma assinatura aplicada sobre ela.

O próprio RFC avisou que trocas gratuitas de codificação inutilizariam a maioria das operações criptográficas feitas sobre a mensagem. As promessas tratam de objetos diferentes: uma garante a carga recuperável; a outra depende dos bytes e campos cobertos. Registrar apenas “sem perda” não preserva a entrada do verificador.

BINARY também não eliminou a obrigação do cliente de entender MIME. Era otimização para casos específicos, não formato universal de armazenamento. Clientes deveriam continuar aptos a executar sua própria decodificação CTE. A capacidade negociada oferece uma rota eficiente, não licença para abandonar a rota comum.

A separação de Heng Lu entre realidade simbólica e operacional organiza os recibos. BINARY em CAPABILITY declara uma aptidão. BINARY.SIZE promete a extensão de uma visão. O literal contado é observado numa conexão. Bytes de armazenamento, mensagem RFC 5322, carga MIME, apresentação e entrada de assinatura ocupam camadas vizinhas, mas não substituíveis.

Uma cadeia suficiente preserva identificador e contexto, BODYSTRUCTURE, seção, CTE, comando, efeito em \\Seen, código, domínio, comprimento, offset e hash da resposta inteira. Se a identidade original importa, mantém uma recuperação raw e seu hash. Para assinatura, registra canonicalização e sequência exata consumida.

Assim, duas frases verdadeiras deixam de competir: o servidor entregou corretamente o corpo decodificado; o arquivo recebido não tem o hash da mensagem serializada. O RFC 3516 definiu a transformação entre os dois fatos.

Seu resultado histórico foi prático: conteúdo binário deixou de pagar a sobrecarga criada para outro transporte em cada consulta IMAP. A lição probatória é mais duradoura. O servidor decodificou o corpo e o cliente obteve octetos úteis; a mensagem original ainda exigia sua própria leitura e sua própria prova.

Fontes