Resumo

  • O RFC 3462 exigiu que multipart/report fosse o contêiner MIME mais externo, com duas partes obrigatórias em ordem: uma explicação para pessoas e um registro tipado para máquinas. Uma terceira parte podia devolver a mensagem original ou um trecho útil.
  • O formato tornava o relatório reconhecível, não confiável. report-type anunciava o subtipo da segunda parte, mas um relatório forjado ainda podia enganar leitores ou acionar uma automação destrutiva.

Um incidente, dois modos de leitura

Texto livre explica contexto, mas varia conforme idioma, produto e julgamento humano. Campos estruturados favorecem classificação automática, porém dizem pouco ao remetente que quer saber se deve corrigir um endereço ou tentar de novo. A tarefa histórica não era escolher um deles. Era transportar os dois e impedir que suas funções se confundissem.

Publicado em janeiro de 2003, o RFC 3462 definiu esse arranjo. O texto simples, o registro do RFC Editor, a página no Datatracker, o histórico, as referências, as citações posteriores e a consulta de erratas compõem o registro verificável. O documento substituiu o RFC 1892 e transformou a embalagem de avisos em uma família genérica de relatórios MIME.

multipart/report precisava ocupar o nível mais externo do conteúdo MIME. Além do boundary dos multipartes descrito no RFC 2046, exigia report-type. Esse parâmetro indicava o subtipo MIME da segunda parte. Um agente conseguia olhar o cabeçalho externo, identificar um relatório e antecipar o formato do registro automático antes de percorrer o corpo inteiro.

A ordem carregava significado

A primeira parte era obrigatória e destinada à leitura humana. Podia empregar qualquer tipo MIME definido em norma, com idioma e conjunto de caracteres adequados, e até multipart/alternative para mais de uma apresentação. A flexibilidade reconhecia que uma explicação útil depende de quem a recebe.

A segunda parte também era obrigatória, mas voltada à máquina. Um tipo de mídia registrado descrevia o evento de tratamento e podia incluir detalhes para especialistas. Em notificações de status de entrega, o RFC 3464 usou message/delivery-status. Isso não fazia do contêiner a regra de toda a entrega: o RFC 3461 tratava da solicitação SMTP de notificações, e o RFC 3463, dos códigos de status aprimorados. O RFC 3462 dizia onde encontrar a afirmação de máquina e qual era seu tipo, não provava sozinho o evento relatado.

A terceira parte era opcional. Ela trazia a mensagem original ou uma porção suficiente para diagnóstico e correlação. Sem uma preferência explícita de retorno, a recomendação era devolver a mensagem completa, o que consumia banda e podia expor conteúdo. Se o caminho de volta não garantisse oito bits ou binário, o gerador podia recodificar para MIME legal de sete bits ou retornar somente text/rfc822-headers. Esses cabeçalhos, herdeiros do formato do RFC 822, não eram uma mensagem completa e não podiam ser rotulados honestamente como message/rfc822.

O desenho criava uma disciplina de evidência: a primeira parte explicava, a segunda permitia cálculo e a terceira fornecia contexto. Uma frase convincente não se tornava campo de status. Um campo não era o objeto original. Cabeçalhos isolados não eram a mensagem inteira. Viajar juntos não apagava essas fronteiras.

Reconhecimento não era autenticação

A posição externa facilitava separar relatórios olhando o Content-Type. O registro de tipos de mídia da IANA oferecia o vocabulário comum. A estrutura também abrigou notificações de disposição do RFC 3798, depois revistas pelo RFC 8098, e status de entrega internacionalizado no RFC 6533.

O próprio RFC advertiu que a forma não autenticava o conteúdo. Um relatório negativo forjado podia levar um gerenciador de lista ou diretório a remover um endereço válido, convertendo manutenção automática em negação de serviço. Um relatório positivo falso podia criar a crença de uma entrega inexistente. Uma assinatura sobre a estrutura completa poderia reduzir o risco, mas o mecanismo ficou fora do escopo.

A sintaxe confirma apenas que bytes seguem uma gramática. Não estabelece autoria, ocorrência do evento nem leitura humana. Quando a automação apaga essas diferenças, um resultado de parser ganha autoridade operacional que nunca recebeu do protocolo.

A posterior disciplina das camadas de realidade de Heng Lu ajuda a separar objeto recebido, interpretação, evento do sistema e ação administrativa. A defesa da primazia do código executado leva a examinar a árvore MIME real, o gerador, a autenticação e o consumidor automático. São lentes editoriais posteriores, não evidência sobre a intenção privada dos autores.

O RFC 3462 não tornou os relatórios verdadeiros. Ele tornou visível onde ficavam a explicação, a afirmação automática e o material de apoio. A estrutura coordenava a leitura; a confiança ainda precisava de outra origem.

Fontes