Summary

  • O rascunho básico de Structured Email propõe application/ld+json para dados legíveis por software. O rascunho de confiança, revisão 02, descreve quando o aplicativo pode mostrá-los ou processá-los.
  • A seção 4.1 apresenta sete condições alternativas, entre elas remetente ou signatário confiável, conversa já estabelecida e ligação com uma mensagem anterior confiável.
  • DKIM pode assinar o email inteiro; JWS pode cobrir a parte estruturada. A confiança no signatário continua sendo uma decisão do aplicativo.

O texto simples de uma mensagem informa a hora do voo. A versão HTML organiza o itinerário. Uma terceira representação entrega ao programa campos sobre reserva e ação. O rascunho principal dá formato a essa representação. O texto de confiança publicado em 2 de novembro tenta definir em que circunstâncias o programa pode promovê-la a interface. O botão de “alterar reserva” nasce dessa escolha, não do carimbo criptográfico isolado.

No modelo proposto, mensagens são tratadas como spam, comuns ou confiáveis. Dados estruturados são processados na última classe. A seção 4.1 explica maneiras de chegar à exibição: conteúdo sem superfície de ataque adicional em relação ao HTML; tratamento equivalente ao de convite ou atualização de calendário; remetente confiável acompanhado de assinatura pessoal ou de domínio; remetente confiável com DKIM; signatário JWS confiável; conversa em andamento com remetente confiável; ou ligação com um email antigo considerado confiável. Sete caminhos possíveis dão sete motivos diferentes para o mesmo controle aparecer.

Uma conversa antiga pode abrir a porta

O histórico local torna a decisão particular a cada caixa de entrada. Um remetente que participou de uma conversa conhecida ganha uma rota que um estranho não possui. Se a conta conhecida cair nas mãos erradas, uma nova ação pode aproveitar o prestígio do fio antigo. A equipe responsável pelo aplicativo precisa saber qual mensagem serviu de âncora e qual política transformou essa âncora em permissão visual.

As assinaturas têm escopos distintos. DKIM cobre a mensagem. JWS pode cobrir apenas os dados estruturados. O rascunho ainda discute cargas JWS destacadas e a comparação por bytes ou por JSON canônico.

Esses detalhes ficam concretos quando o filtro de spam lê uma versão, o renderizador HTML mostra outra e o processador estruturado cria uma terceira ação. Uma verificação positiva de assinatura pode coexistir com informações conflitantes sobre o voo. A auditoria precisa guardar tanto o objeto assinado quanto o controle efetivamente exibido.

Referências externas criam outra saída. Um aplicativo que busca dados remotos ao abrir a mensagem pode revelar a leitura e receber material fora do conteúdo assinado. A seção 4.3 recomenda dados autocontidos quando a interação útil dependeria de uma busca na Web. Falta uma prova pública com o mesmo MIME assinado, uma resposta relacionada e uma referência remota executados em vários aplicativos. O registro de tela e tráfego dessa prova mostraria onde cada produto traça sua linha.

Histórico do rascunho · Structured Email · DKIM · JWS