Resumo

  • O RFC 2368 ampliou mailto: para transportar destinatários, cabeçalhos e um corpo curto em texto simples, sem exigir contato imediato com um servidor remoto.
  • O cliente podia rejeitar campos perigosos e deveria mostrar o resultado decodificado antes de pedir aprovação; link, clique e rascunho preenchido não comprovavam envio, entrega ou ação do destinatário.

Um link da Web costuma parecer uma passagem direta para outro sistema. A pessoa clica, o navegador consulta um servidor e algo volta. mailto: podia terminar antes de qualquer uma dessas etapas: uma janela local se abria com campos preenchidos e nenhuma mensagem havia deixado o computador.

No RFC 1738, a forma básica carregava um endereço. O RFC 2368 acrescentou uma lista de caixas postais e pares de nome e valor depois de ?, separados por &. O nome especial body fornecia o primeiro corpo text/plain. Isso permitia preparar pedidos para robôs de informação, comandos de inscrição em listas, respostas a arquivos ou mensagens com cópia sem obrigar a pessoa a transcrever cada detalhe.

A economia de digitação não eliminava os diferentes donos do fato. O editor da página controlava a sequência original. O analisador convertia escapes em destinatários, cabeçalhos e corpo. O cliente de correio aplicava sua política. O usuário inspecionava o resultado. Só depois um servidor de submissão poderia aceitar o material, outros servidores poderiam transportá-lo e uma caixa remota poderia recebê-lo. Cada passagem precisava do próprio recibo.

A codificação fazia parte do controle. ?, = e & eram delimitadores, portanto precisavam de escape quando apareciam como dados. Espaço virava %20, quebra de linha no corpo virava %0D%0A e um sinal de porcentagem literal virava %25. Em HTML, o separador & precisava ser escrito como &. O código da página, o URL interpretado e o rascunho visível eram representações relacionadas, mas não idênticas. Uma decodificação dupla ou fora de ordem podia mudar o destino ou criar um campo inesperado.

O documento também preservava os limites internacionais de 1998. Caracteres de oito bits eram proibidos sem codificação. Palavras codificadas de MIME podiam aparecer em valores de cabeçalho, mas não no valor de body. Não havia substituição de variáveis: um link estático não podia inserir com segurança o endereço de quem clicou nem gerar uma assinatura dependente de dados locais. Era um modelo limitado, não um programa geral.

A gramática aceitava nomes de cabeçalho que o cliente não tinha obrigação de obedecer. O agente podia recusar a criação da mensagem ou manter apenas um subconjunto seguro. Subject, Keywords e Body eram considerados úteis; From, Bcc, campos de roteamento e vários campos MIME eram particularmente suspeitos. A possibilidade de escrever um nome na URL não concedia autoridade sobre identidade ou encaminhamento.

Antes de transmitir, o cliente deveria exibir a mensagem completa e decodificada, inclusive os cabeçalhos fornecidos pelo URL, deixar claro que um e-mail seria enviado e pedir aprovação. A precaução tratava de consequências reais: revelar o usuário a terceiros, gerar cobrança, produzir uma mensagem ilegal ou acionar uma operação danosa atribuída ao remetente.

Daí nasce uma leitura rigorosa da evidência. A presença do link mostra apenas que um publicador ofereceu um modelo. O clique, quando registrado, mostra ativação. O compositor preenchido mostra que o cliente aceitou alguns campos. A decisão de enviar, a aceitação pelo servidor, a entrega, a leitura e a execução do pedido pertencem a registros posteriores.

O RFC 6068 substituiu a especificação em 2010. Ele melhorou a internacionalização com UTF-8 seguido de codificação percentual, esclareceu duplicidades e revisou detalhes de segurança. Não aboliu a fronteira principal: a URI continuou sendo um modelo para uma mensagem possível. Caracteres corretos não viraram consentimento, e consentimento não virou prova de entrega.

O valor histórico do RFC 2368 está nessa automação contida. Um documento externo podia reduzir o trabalho de composição, mas não recebia por isso o poder de falar em nome do usuário.

Fontes