Resumo

  • RFC 1524 permitiu que vários leitores compartilhassem regras mailcap: o e-mail fornecia o Content-Type, mas arquivos e precedência locais definiam qual ação de visualizar, compor, editar, imprimir ou testar seria usada.
  • Na semântica UNIX, a regra escolhida virava uma linha para o Bourne shell com valores e nomes temporários substituídos. Correspondência, teste bem-sucedido ou saída zero não comprovavam autenticidade, segurança, consentimento ou compreensão.

O ganho estava na indireção

MIME tornara possível nomear e transportar imagens, áudio e corpos multipartes no correio da Internet. A etiqueta, entretanto, não instalava um programa no computador de destino. Dois locais podiam reconhecer o mesmo nome e dispor de ferramentas, terminais ou dispositivos completamente diferentes.

RFC 1524 propôs que agentes leitores consultassem um arquivo externo ao encontrar um formato não textual. Vários programas de correio poderiam compartilhar a mesma descrição das facilidades instaladas. O site ganhava um novo formato instalando um binário e incluindo uma entrada, sem reescrever cada leitor.

O acordo comum continuava pequeno: um vocabulário para associar tipo declarado e capacidade local. O remetente dizia o que acreditava enviar; não indicava o programa autorizado a receber poder no outro computador.

A precedência fazia parte da política

A configuração efetiva era a concatenação virtual de vários arquivos mailcap. Vencia a primeira entrada que combinasse com o Content-Type, fornecesse a operação procurada e passasse por eventual test=.

Na proposta UNIX, o arquivo do usuário vinha antes de locais do sistema. A variável MAILCAPS podia substituir o caminho inteiro. Assim, o administrador publicava padrões, mas cada pessoa podia ampliar ou sobrepor esses padrões. Guardar apenas a regra do sistema não explicava o comportamento de uma conta.

Cada entrada tinha padrão de mídia e comando de visualização. Campos opcionais separavam composição, composição tipada, edição, impressão e teste. needsterminal exigia ambiente interativo; copiousoutput aconselhava paginação ou rolagem. Um formato poderia ser visível sem ser editável ou produzido. “Suporte” tinha várias superfícies de autoridade.

O teste podia executar lógica complexa para descobrir arquitetura, sistema de janelas ou dispositivo de áudio. Retorno zero só tornava a entrada aplicável. Não examinava automaticamente os bytes do corpo nem emitia um parecer de segurança.

O texto da regra chegava ao shell

Para UNIX, RFC 1524 definiu os campos de ação como linhas completas destinadas ao Bourne shell, na prática precedidas por /bin/sh -c. %t recebia o tipo, %{nome} um parâmetro do Content-Type, %n a quantidade de partes e %F uma sequência de tipos e arquivos. %s indicava um arquivo contendo o corpo.

O caminho incluía analisar metadados, escolher entrada, interpretar escapes, substituir valores, formar argumentos e entregar texto executável ao sistema. Cada conversão precisava de evidência própria. Um parâmetro podia ser válido no cabeçalho e inadequado na linha de comando. Um processo iniciado podia ler o arquivo errado ou produzir saída inútil.

%s também mudava o transporte local dos dados. Sem ele, comandos de ver e editar recebiam o corpo pela entrada padrão. Com ele, o leitor podia criar um arquivo temporário. O documento alertava que esse arquivo não deveria ser presumido existente depois que o comando terminasse; um helper em segundo plano precisava salvar o necessário.

nametemplate permitia criar um nome com extensão, como .gif, para programas sensíveis ao sufixo. A forma do nome não verificava o conteúdo, a origem ou a segurança.

Produzir uma parte exigia outro contrato

Um programa compose gerava dados que o chamador marcava com o tipo da regra. composetyped podia gerar o próprio Content-Type e cabeçalhos relacionados. A codificação de transferência continuava com o software chamador, salvo anúncio explícito.

Portanto, regra, programa produtor, bytes, tipo, codificação e mensagem final eram registros separados. A sessão de edição concluída não assinava os handoffs seguintes.

Um tipo registrado não era permissão

RFC 1524 avisou que o mecanismo podia facilitar problemas de segurança do MIME e pediu cautela na escolha de programas para execução automática. Não relatou ataque, produto vulnerável ou implantação universal. O que sustenta é uma fronteira: dados remotos só alcançam uma ação poderosa porque uma política local os conecta.

RFCs 2045, 2046 e 2048 revisaram MIME, e RFC 6838 atualizou o registro de tipos. O registro compartilha nome e documentação. Não instala handler, não identifica qual regra venceu e não autoriza execução.

Uma apuração deve preservar bytes e tipo declarados, arquivos mailcap efetivos e ordem, ação solicitada, entrada e teste, comando expandido, canal por stdin ou temporário, processo, saída, efeitos e escolha humana. “O anexo abriu” comprime exatamente a passagem que precisa permanecer auditável.

Fontes