Resumo

  • O cliente só podia declarar BODY=8BITMIME e enviar octetos com o bit alto depois de o servidor anunciar 8BITMIME na resposta EHLO daquela sessão.
  • A aceitação impunha custódia bit a bit; diante de um próximo salto incapaz, o retransmissor tinha de produzir MIME válido de sete bits sem perda ou registrar falha permanente.

Descrever a carga não alargava a estrada

MIME permitiu declarar tipo de mídia, conjunto de caracteres e codificação de transferência. Isso resolveu como interpretar a mensagem, mas não alterou automaticamente o transporte SMTP. A RFC 2045 distingue 7bit, 8bit e binary: um corpo bem descrito ainda podia conter octetos que o próximo servidor jamais prometera preservar.

O problema histórico era, portanto, atribuir responsabilidade. Qual implementação aceitou aquela representação, em qual conexão, e onde sua autoridade terminava?

Três RFCs mantiveram uma promessa pequena

A RFC 1426 publicou a primeira extensão em fevereiro de 1993. A RFC 1652 a substituiu em julho de 1994, e a RFC 6152 substituiu a RFC 1652 em março de 2011. Essa linha prova evolução normativa, não adoção contemporânea.

O servidor inclui 8BITMIME numa resposta EHLO 250. O registro SMTP da IANA mantém a palavra-chave sem parâmetro EHLO e aponta para a RFC 6152. Nenhum verbo SMTP novo foi criado.

O cliente pode anexar BODY=7BIT ou BODY=8BITMIME a MAIL FROM. BODY descreve o domínio de octetos do conteúdo que virá por DATA; não identifica idioma, charset ou tipo de mídia. Largura de transporte e significado continuam sendo fatos diferentes.

A permissão pertencia à conexão presente

Antes de enviar o corpo de oito bits, o cliente precisa obter EHLO bem-sucedido com a capacidade. Sem isso, não pode transmitir octetos fora da faixa US-ASCII. O fato de TCP carregar bytes arbitrários, ou de o mesmo produto ter funcionado ontem, não substitui a evidência desta sessão.

A promessa cobre um salto. Um retransmissor pode aceitar a mensagem e depois encontrar outro servidor sem 8BITMIME. O primeiro anúncio não fala pelo segundo nem garante que o leitor final entenda os caracteres.

Aceitar era assumir custódia de todos os bits

O servidor capaz deve preservar todos os bits de cada octeto recebido por DATA e manter essa integridade ao entregar ou retransmitir. A obrigação atravessa spool, filtros, filas e o processo de saída. Se um componente interno apaga o bit alto, o anúncio da entrada era falso no sistema em execução.

Isso não autentica remetente, não torna o conteúdo seguro e não garante entrega. É uma responsabilidade mais estreita: a representação aceita não pode mudar por uma suposição herdada de sete bits.

Oito bits não eram binário arbitrário

DATA conserva estrutura de linhas e transparência de ponto. Uma linha contendo apenas ponto ainda termina a transferência; pontos no começo da linha ainda são duplicados. O limite de linha também permanece, e a RFC 6152 admite servidores que garantem somente 1.000 octetos, CRLF incluído.

Assim, 8BITMIME suporta a codificação MIME 8bit, não binary. Ele amplia os valores permitidos dentro da linha sem abolir a linha. CHUNKING e BINARYMIME tratam de outra mudança de enquadramento.

O salto seguinte reabria a decisão

Se o próximo servidor não anuncia a extensão, o retransmissor não pode enviar e torcer. Pode transformar a mensagem em MIME válido de sete bits sem perder informação, usando codificações adequadas, ou tratar a barreira como erro permanente.

A RFC 6152 não define o conversor. Cabeçalhos, limites multipartes, finais de linha, rótulos de codificação e assinaturas precisam permanecer coerentes. Produzir apenas bytes baixos não basta se o leitor recebe outro significado. Quando a transformação não é comprovável, falhar explicitamente é mais honesto que entregar corrupção.

A declaração organizava a prova

BODY=8BITMIME é uma afirmação do cliente, não verdade automática. A operação precisa guardar separadamente a capacidade anunciada, o BODY declarado, o domínio observado e a ação no próximo salto. Essa cadeia permite distinguir erro do remetente, conversão insegura, perda interna e falha de renderização.

O ganho duradouro foi limitar a autoridade. MIME descrevia a carga; a conexão SMTP dizia se este custodiante podia recebê-la; a conexão seguinte fazia a pergunta novamente.

Fontes e limites

A linhagem está na RFC 1426, RFC 1652 e RFC 6152. A RFC 2045 define os domínios MIME, e o registro IANA mantém a entrada atual. Essas fontes não medem implantação, volume ou frequência de conversão.