Resumo

  • O RFC 9979 registra $istrusted como palavra-chave IMAP/JMAP compartilhada e consultiva, aplicada pelo servidor na entrega quando nome e endereço do remetente foram verificados com alto grau de confiança. A aprovação comum em SPF, DKIM ou DMARC, sozinha, é insuficiente.
  • Clientes podem converter esse estado em um indicador de verificação. O selo, porém, não comprova a segurança do conteúdo, a legitimidade de uma ação pedida, a fidelidade da interface ou a validade permanente da conclusão.
  • Daniel Kade propõe um registro de correção com poucos dados, capaz de ligar a evidência e a versão de política do servidor, a transição do estado, a apresentação nos clientes, a dependência material e a retificação sem armazenar o corpo da mensagem nem segredos.

O veredito nasce uma vez e ganha muitas aparências

Considere um aviso de conta enviado pelo próprio provedor de e-mail. Na chegada, o serviço reconhece evidências fortes de que o nome exibido e o endereço pertencem realmente ao provedor. Ele define $istrusted. O navegador mostra um pequeno visto; o aplicativo móvel escreve “remetente verificado”. Mesmo sem conhecer o mecanismo, a pessoa entende que o serviço de caixa postal está atribuindo uma confiança especial à identidade apresentada.

Dias depois, uma revisão descobre que a marca não deveria ter sido aplicada. Talvez uma fonte de evidência tivesse escopo amplo demais, uma regra antiga continuasse ativa ou a integridade do servidor tivesse sido afetada. Retirar a palavra-chave corrige o presente, mas não recompõe o passado. Quais mensagens receberam o selo? Qual regra decidiu? Quais clientes exibiram qual promessa? Houve início de uma operação sensível enquanto o indicador estava visível?

Publicado em maio de 2026 como documento Informational no fluxo do IETF, o RFC 9979 define 17 palavras-chave de mensagens e três atributos de nomes de caixas postais. Os nomes já apareciam em diferentes implementações; o registro evita colisões e descreve o uso pretendido. É um trabalho de coordenação: servidores e clientes ganham um vocabulário comum para estados que, sem isso, poderiam significar coisas incompatíveis.

$istrusted tem uma formulação exigente. A palavra-chave indica que o servidor verificou com alto grau de confiança a autenticidade tanto do nome quanto do endereço do remetente. O exemplo típico é a própria operadora da caixa postal reconhecendo comunicações legítimas que envia a seus clientes. Um cliente compatível pode mostrar um indicador que ajude a distinguir essa mensagem de uma imitação de phishing.

O RFC impede o atalho óbvio. Servidores devem ter cautela, pois o estado transmite confiança ao usuário e um falso positivo pode fazê-lo acreditar em uma mensagem fraudulenta. A marca não pode ser usada somente porque SPF, DKIM ou DMARC passou. Esses resultados têm valor em seus limites técnicos, mas não produzem automaticamente a conclusão mais forte sobre nome e endereço representada por $istrusted.

O registro identifica o autor do juízo, não documenta todo o raciocínio

No registro de palavras-chave IMAP e JMAP da IANA, $istrusted aparece como SHARED, COMMON e BOTH. O RFC classifica a palavra como consultiva e diz que o servidor a define na entrega. Assim, o cliente sabe que recebeu uma afirmação do servidor, compartilhada na conta, que não é por si mesma um comando automático.

O token não carrega o dossiê. Ele não revela a classe de evidência, qual versão da política foi usada, quando a evidência foi observada, quem reviu a conclusão nem por que ela mudou. O servidor tampouco controla a intensidade da interface. Um ícone discreto, um cabeçalho que diz “mensagem segura”, uma leitura por voz ou nenhuma exibição podem nascer do mesmo estado e provocar expectativas bem diferentes.

As outras entradas do RFC mostram por que essas fronteiras importam. $new é um sinal consultivo de atenção e pode ser removido após interação. $notify pode causar uma notificação. $muted, definido pelo cliente, pode levar o servidor a reduzir o destaque de futuras mensagens de uma conversa. $unsubscribed registra uma tentativa de cancelamento, não sua conclusão bem-sucedida. Cada nome coordena um fato ou pedido; nenhum substitui o fluxo completo.

Os atributos de caixa dão um contraste ainda mais claro. Snoozed identifica o local de armazenamento de mensagens adiadas, mas o RFC afirma que o atributo não define sozinho o mecanismo ou a interface de adiamento. O registro de atributos de caixa da IANA torna uma função localizável; não se transforma no agendador. Do mesmo modo, $istrusted transporta um juízo sem ser seu sistema integral de auditoria e correção.

Remetente autêntico não significa instrução autorizada

O objeto semântico é o nome e o endereço no campo From. Não há certificação de que cada afirmação no corpo seja verdadeira, que um link seja benigno, que um anexo esteja livre de risco ou que um pagamento seja devido. Uma identidade legítima ainda pode cometer erro, sofrer abuso interno ou enviar uma solicitação que aquele destinatário não deveria executar.

A linguagem do produto pode preservar ou apagar a diferença. “Identidade reconhecida pelo servidor” descreve o alcance. “Este e-mail é seguro” promete muito mais. Colocar o selo ao lado de um botão de pagamento pode fazer o reconhecimento de identidade funcionar psicologicamente como autorização da transação. A palavra-chave compartilhada não registra essa escolha editorial.

Não é razoável exigir que cada cliente repita toda a avaliação do servidor. A decisão central pode ser consistente e usar evidências indisponíveis no dispositivo. A disciplina está em manter os donos separados: o servidor responde pelo juízo de autenticidade; o cliente, por explicar esse juízo; a pessoa ou o sistema seguinte, por autorizar a ação. Um veredito não pode fingir que já contém o outro.

Why BTW Media Exists oferece a regra editorial adequada: separar o que foi observado da narrativa atribuída depois. O fato observável é que um servidor específico, sob uma política específica, aplicou um estado a uma mensagem específica. “A mensagem é segura” exige demonstração adicional.

A confiança no servidor integra a própria afirmação

A seção de segurança do RFC 9979 põe o servidor dentro do problema. O uso e a interpretação dessas palavras-chave e atributos dependem de cliente e usuário poderem confiar no servidor IMAP. Um servidor comprometido ou malicioso pode definir ou manipular estados para enganar. $istrusted não é uma testemunha independente de quem o emitiu.

Uma captura de tela comprova, no máximo, que uma interface mostrou um indicador em certo momento. Para examinar autenticidade, a investigação precisa ligá-lo ao estado sincronizado, ao servidor que o forneceu, à versão do serviço decisor e à categoria de evidência aceita. Se a integridade do servidor está em dúvida, o selo é parte da evidência contestada.

O caráter compartilhado cria ainda uma questão temporal. O estado some do servidor; o cliente conectado atualiza; outro, offline, mantém o cache; uma notificação antiga continua na memória do leitor. O RFC 9979 não promete um comportamento único de cache ou apresentação. “Bit removido” e “promessa visual retirada” são eventos diferentes.

The Policy Mirror pede que políticas reflitam o controle real. O servidor controla a conclusão, sincronização e cache controlam o trânsito, o produto controla a expressão, e a pessoa ou serviço posterior controla a ação. Fundir os quatro em um único sinal verde esconde quem precisa agir numa correção.

É possível preservar a linhagem sem copiar mensagens

A solução não deve virar uma central de vigilância. Corpo do e-mail, credenciais, chaves, traços criptográficos completos e hábitos detalhados de leitura seriam dados excessivos. A pergunta é limitada: como o juízo do servidor chegou a uma superfície e o que aconteceu quando esse juízo mudou?

O primeiro plano de um registro usa identificador restrito à caixa ou hash com sal, horário de entrega e escopo da conta. O conteúdo não é duplicado. O segundo informa serviço decisor, classes de evidência, época da política, instante da decisão e faixa de confiança, sem guardar material secreto.

O terceiro preserva a mudança do estado: quem definiu $istrusted, versão, alcance de sincronização, remoção ou substituição e categoria do motivo. O quarto resume a apresentação: família e versão do cliente, rótulo semântico, equivalente de acessibilidade, primeira e última exibição conhecidas e disponibilidade de explicação.

O quinto registra apenas categorias de consequência material que a organização tenha legitimidade para observar, como o início de um fluxo de alto risco enquanto o selo estava presente. Nada de conteúdo ou comportamento sem relação. O sexto documenta a correção: autoridade da investigação, nova conclusão, intervalo afetado, clientes ou contas avisados, remediação, recurso e responsável pelo fechamento.

Cada parte deve limitar o que afirma. O servidor não sabe que o ícone sumiu só porque retirou o estado. O cliente não pode inventar a base de autenticidade a partir de um cache. A equipe de resposta não deve atribuir uma ação ao selo se não consegue provar o momento e a apresentação. Manter a incerteza explícita é uma característica do registro.

Esta é uma proposta de Daniel Kade, não um requisito do RFC 9979. Ela mantém a semântica do protocolo e torna revisável seu percurso operacional.

Fontes