Resumo

  • A RFC 2017 acrescentou o acesso URL a message/external-body: a mensagem carregava a instrução de busca, enquanto o objeto permanecia externo.
  • Fragmentação e codificação preservavam o localizador no cabeçalho, mas não provavam alcance, identidade estável, autenticidade ou autorização.
  • Concordância de tipo, consentimento explícito e Content-MD5 eram controles independentes; o registro oficial não demonstra implantação ampla.

Antes da RFC 2017, MIME já admitia um corpo ausente. A RFC 1521 listava FTP, FTP anônimo, TFTP, arquivo local e servidor de correio como maneiras de chegar a ele. O novo texto registrou mais uma: URL. O parâmetro de mesmo nome era obrigatório, e o cabeçalho da entidade interna declarava o tipo de mídia esperado depois da recuperação.

Nem todo esquema com aparência de URL servia. A RFC exigia uma forma que recuperasse diretamente algum objeto e excluía mailto. Esse esquema aponta para uma caixa postal e uma ação de envio, não para os dados que comporiam o corpo externo. A diferença está no efeito operacional, não na pontuação da string.

Havia também um problema material: fazer um localizador longo sobreviver ao cabeçalho do e-mail. A solução foi uma sequência entre aspas de fragmentos URL-word, cada qual com no máximo quarenta caracteres e separado por espaço linear. O receptor removia aspas e espaços para recompor o endereço. Antes da divisão, espaços crus, controles, aspas, barras invertidas e octetos altos precisavam ser codificados conforme a RFC 1738.

A regra garante uma representação transportável. Ela não garante que a origem responda, que as credenciais autorizem acesso, que redirecionamentos preservem a confiança ou que o mesmo endereço devolva os mesmos bytes. É possível transportar perfeitamente uma instrução que nunca produz um objeto.

O tipo vinha antes do conteúdo

O cabeçalho interno antecipava o tipo do que seria recuperado. A RFC 2017 exigia concordância entre a versão usada pela aplicação e essa declaração porque escolhas irreversíveis já poderiam ter sido feitas. Selecionar um decodificador ou acionar um manipulador antes da validação dá consequência prática a uma afirmação ainda não confirmada.

No acesso por URL, o chamado corpo fantasma não era usado e deveria ficar vazio. O vazio dizia a verdade: não havia uma pequena cópia anexada. A regra também distinguia essa modalidade de mail-server, na qual a área carregava um comando para o servidor.

A RFC 2046, que substituiu a RFC 1521 no mês seguinte, manteve a arquitetura e exigiu Content-ID para corpos externos, permitindo relacionar cache e confirmações posteriores. Também formulou o risco: resolver um external-body leva o destinatário a executar uma operação indicada pelo remetente. O agente deve explicar o que fará e solicitar permissão explícita.

Logo, sintaxe válida não é consentimento. Um digest coincidente também não autentica o autor. A RFC 2017 aceita Content-MD5 como teste de integridade e de correspondência com o objeto pretendido, mas avisa que ele não é assinatura digital. A RFC 1864 preserva o mesmo limite.

Mensagem e objeto externo podem pertencer a cadeias de evidência diferentes. Verificar a mensagem não cobre automaticamente bytes obtidos depois por outro protocolo. O caminho pode ser desviado e o conteúdo pode mudar. Um localizador descreve como buscar; não constitui identidade permanente do material.

Os registros atuais mantêm a RFC 2017 como Proposed Standard, e a consulta não mostrou erratas correspondentes nesta revisão. A RFC 1738, usada historicamente para codificação, hoje está obsoleta; a RFC 3986 oferece a sintaxe URI genérica posterior. Esses dados situam os documentos, mas não comprovam adoção, escala de uso nem descendência direta em produtos atuais.

O legado útil é um vocabulário de separação. Endereço recebido, ação autorizada, objeto recuperado, tipo confirmado e integridade verificada são fatos diferentes. Quando um sistema os resume em um único ícone, ele assume uma responsabilidade que a RFC jamais eliminou.

Fontes