Resumo

  • Um Internet-Draft individual de 27 de outubro reúne critérios para detectar remetentes que imitam o suporte ou recrutadores em mensagens de plataformas. Seu destino é Informational e ele não define um protocolo.
  • O texto aponta duas armadilhas: igualdade exata de esqueletos Unicode pode perder semelhanças visuais, e validadores pesquisados teriam aceitado nomes de host preservando caracteres invisíveis. A análise precisa juntar remetente, host do link e intenção da mensagem.

No e-mail corporativo, o gateway pode ver uma mensagem antes do empregado. Dentro de um marketplace, uma conversa vai de uma conta da plataforma para outra. Um perfil pode escrever “Suporte” no nome exibido sem fazer parte da equipe. O novo rascunho sobre remetentes parecidos põe a inspeção nesse caminho: conta de origem, endereço, nome mostrado, host dos links e o que o texto pede. A empresa que opera a caixa também decide quem recebeu o direito de usar sua placa de atendimento.

O documento organiza os sinais em três grupos. Compara domínios do remetente e dos links com identidades protegidas. Examina marcas no nome de exibição, na parte local do endereço e em subdomínios estranhos. Depois verifica a ação pedida: entregar credenciais, sair do aplicativo ou obedecer a uma autoridade supostamente oficial. Um único sinal dá trabalho e causa erro. Uma central de carreiras de universidade pode parecer uma conta de recrutamento legítima; uma regra que bloqueia qualquer semelhança penaliza essa conversa.

A primeira falha técnica parece uma economia inocente. A UTS #39 do Unicode define o “esqueleto” usado para comparar caracteres confundíveis e também descreve detecção de escritas misturadas. O rascunho mostra que exigir esqueletos exatamente iguais não alcança algumas imitações visuais. Ele cita a letra grega kappa minúscula e a te cirílica minúscula, que têm protótipos latinos fora do ASCII. Comparar apenas o esqueleto final com a marca ASCII pode deixar um nome semelhante escapar. O texto recomenda acrescentar análise de escritas e distância de edição limitada entre esqueletos.

A segunda falha é invisível no próprio host. O autor relata que vários validadores de sua pesquisa aceitaram nomes contendo U+00AD, U+200B, U+2060 ou U+FEFF e devolveram o caractere escondido junto. A RFC 5890 define a estrutura de nomes internacionalizados, a RFC 5892 trata dos pontos de código e a UTS #46 descreve o processamento de compatibilidade. O rascunho recomenda processar o host sob IDNA2008 ou UTS-46 antes de checá-lo contra uma lista permitida e rejeitar rótulos com caracteres de formatação ou ignoráveis por padrão. Carimbar como “válido” um valor que ainda carrega esse caractere passa a confusão para o próximo serviço.

O operador da plataforma controla a lista de nomes próprios, as contas autorizadas e o efeito de uma detecção. Pode mostrar um alerta ou impedir o envio; precisa justificar cada degrau. O rascunho também considera modelos de linguagem, desde que tratem o texto da mensagem como entrada não confiável e não se sobreponham às evidências determinísticas do remetente. O Datatracker ainda registra a proposta individual como I-D Exists, destinada a ser Informational.

O rascunho não publica os nomes e versões dos validadores testados nem uma tabela reproduzível de entradas e saídas. Essa tabela diria quanto da falha persiste nas versões atuais.