Resumo
- O RFC 9979 define 17 keywords IMAP/JMAP e três atributos de caixa postal. O vocabulário comum reduz colisões, mas não prova que um classificador, uma ação do usuário ou um fluxo externo terminou corretamente.
$memoe$hasmemoprecisam permanecer coerentes em dois objetos;$istrustedprecisa de evidência além de SPF/DKIM/DMARC;$unsubscribedregistra tentativa;Scheduledregistra localização.
No celular, a observação aparecia corretamente junto da mensagem. No desktop, havia o marcador de que a mensagem tinha um memo, mas o memo não existia. Um cliente havia criado a nota, marcado os dois lados e caído antes de concluir a sincronização. O outro recebeu apenas metade da relação.
Nenhum token era desconhecido. O problema estava entre eles.
O caso é ilustrativo e não descreve um produto ou incidente real. RFC 9979, publicado em maio de 2026 como documento Informational do IETF, reúne 17 palavras-chave de mensagem e três atributos de nome de caixa que já circulavam em diferentes implementações. Registrar esses nomes evita que a mesma palavra ganhe sentidos incompatíveis. Não transforma estado corrente em histórico completo.
O registro IANA de IMAP and JMAP Keywords conserva nome, tipo, uso, escopo e referência. O registro de IMAP Mailbox Name Attributes inclui Memos, Scheduled e Snoozed. Essas tabelas provam coordenação do namespace. Não provam que um servidor inspecionou aquela mensagem, que o usuário confirmou uma ação ou que outro sistema entregou um resultado.
As keywords têm autores e forças diferentes. Algumas são aplicadas pelo servidor durante a entrega. Outras são definidas ou removidas pelo cliente por causa de uma interação do usuário. Algumas são informativas. Outras podem acionar classificação, notificação, arquivamento ou prioridade. Uma exportação que leva só a string deixa para trás justamente quem assumiu a responsabilidade.
RFC 5788 criou o registro. RFC 8457 ofereceu um precedente para importância compartilhada. RFC 9051 define IMAP4rev2 e RFC 8621 define JMAP Mail. O RFC 9979 melhora a projeção entre essas superfícies, sem centralizar o critério local.
O par de anexos mostra por que ausência não é negação. $hasattachment e $hasnoattachment são mutuamente excludentes. Se o primeiro não aparece, ainda não sabemos se não havia anexo ou se nenhuma análise ocorreu. Um modelo correto guarda três estados: positivo, negativo explícito e desconhecido. Uma tela com ícone ou vazio costuma apagar essa diferença.
A propriedade hasAttachment de JMAP deve espelhar a mesma informação. Isso cria coerência entre protocolos. Não cria uma segunda observação. Se o parser errou ou trabalhou sobre uma versão anterior da mensagem, todos os clientes podem concordar com o mesmo fato errado.
Nos memos, $memo identifica a mensagem que contém a anotação e $hasmemo identifica a mensagem anotada. Criar ou apagar exige alterar os dois lados. RFC 8474 fornece identidade de objeto e thread para relações desse tipo. A identidade estável ajuda a endereçar; ela não torna duas escritas atômicas. Por isso o ledger precisa do ID da operação, antes/depois e confirmação de ambos os objetos.
$istrusted acrescenta um julgamento de segurança. O servidor a aplica como indicação consultiva de que verificou nome e endereço do remetente com alto grau de confiança. O RFC alerta que uma aplicação errada pode levar pessoas a confiar em fraude e proíbe usar o marcador apenas porque SPF, DKIM ou DMARC passaram.
Cada mecanismo responde a uma pergunta menor. RFC 7208 trata da autorização do host para uma identidade de envelope. RFC 6376 valida assinatura de domínio sobre material selecionado. RFC 9989 trata de alinhamento com o domínio visível e política solicitada. Nenhum deles, sozinho, verifica a pessoa por trás do nome exibido, a autoridade comercial, a segurança de um link ou a veracidade do pedido.
“Alto grau” não vem com algoritmo ou limiar universal. O operador pode usar evidência própria, mas precisa preservar o recibo: servidor que afirmou, versão da regra, classes de sinais, confiança, horário, validade, condição de revogação e dono. O cliente pode resumir isso em uma interface compacta; não deveria esconder que se trata de uma asserção local.
A seção de segurança diz que cliente e usuário dependem da confiança no servidor IMAP. Um servidor comprometido ou malicioso pode manipular labels para enganar. Sincronização perfeita não corrige a origem. Cinco telas iguais continuam sendo uma única afirmação replicada.
No cancelamento de assinatura, $canunsubscribe significa que o servidor encontrou um mecanismo List-Unsubscribe compatível e aplicou seus próprios testes de reputação. RFC 8058 define a sinalização one-click. O estado autoriza oferecer a ação, não declarar sua conclusão.
$unsubscribed registra que o usuário tentou sair, mesmo sem confirmação de sucesso. Não pode ser aplicado quando já se sabe que houve falha. Capacidade, tentativa, falha certa, resultado desconhecido e sucesso confirmado são pontos distintos. A palavra curta é boa para sincronização; é insuficiente para comprovar obrigação atendida.
$new também não descreve idade. Uma mensagem antiga pode recebê-la quando desperta de snooze e precisa voltar à atenção. $notify pede ao cliente uma notificação, subordinada à preferência local. Pedido, apresentação, visualização e resposta precisam de quatro eventos, não de um badge.
Snoozed apenas identifica a caixa usada para guardar mensagens temporariamente retiradas de foco; não define o mecanismo de despertar. Scheduled identifica onde ficam mensagens planejadas para envio futuro. Estar nessa pasta não comprova que o job disparou, o relay aceitou ou o destinatário recebeu. Planejamento e entrega pertencem a relógios e autoridades diferentes.
$followed e $muted não deveriam coexistir; se coexistirem, followed prevalece. A regra garante uma resposta determinística, mas não explica se a contradição veio de cliente velho, corrida, restauração ou invasor. O RFC observa que um intruso pode silenciar threads para ocultar respostas e recomenda conferir essas ações na recuperação da conta.
Recuperar a credencial sem revisar estado sincronizado deixa decisões do atacante no sistema. Filtros, mutes e notificações compõem a superfície de autoridade tanto quanto a senha, pois decidem o que o titular consegue perceber.
A página de informação do RFC e a busca de errata fixam a referência documental. Não são inventário de implantação, teste de classificador ou relatório de incidente. A filiação dos autores também não demonstra adoção por empresa alguma.
As Reality Layers de Heng Lu separam significado registrado, regra local, asserção, estado sincronizado, apresentação, crença, ação e efeito. Running-Code Primacy manda observar o classificador e a operação que realmente rodaram. Minimum Initial Specification sustenta um núcleo pequeno de nomes e conflitos, mantendo decisões futuras sob responsabilidade local.
O recibo complementar deve registrar mensagem, thread ou caixa, keyword exata, ator autorizado, servidor, cliente e protocolo, estado anterior e novo, regra ou gesto, evidência e confiança, tempo e expiração, sincronização, projeção visual, preferência, ação, resposta externa e correção. Dados sensíveis podem ficar restritos, mas método e responsável precisam existir.
O RFC 9979 faz o estado viajar. A operação responsável preserva também a história que diz o que aquele estado pode — e não pode — afirmar.
Fontes
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance

