Resumo

  • name e version são strings associadas ao produto do interpretador. O próprio RFC diz que o significado da versão é específico do produto e depende do nome.
  • A decisão auditável precisa ligar o valor de ambiente ao build carregado, ao ramo executado e ao resultado observado; a etiqueta sozinha não faz essa ligação.

A política emergencial deveria rejeitar mensagens processadas por uma versão vulnerável. O script comparava name e version, encontrou a versão aprovada e liberou o fluxo. O painel considerou o controle satisfeito.

Depois surgiu a pergunta que o campo nunca prometera responder: qual imagem e qual conjunto de patches aquele worker havia carregado? O mesmo texto de versão era usado por builds diferentes, e o valor não continha digest, geração de implantação nem identidade do processo.

O caso é conceitual. Ele não descreve um produto real. Serve para separar compatibilidade de script de atestação de execução antes que uma string amigável passe a autorizar decisões irreversíveis.

Um vocabulário para adaptar, não para atestar

O teste environment recebe o nome de um item e as chaves de comparação. A correspondência padrão é :is, com i;ascii-casemap. O valor vem do ambiente operacional do interpretador, não diretamente da mensagem.

Essa arquitetura permite que uma regra mude de comportamento conforme domínio, host, localização no serviço, fase de entrega, produto ou conexão remota. Ela não define um protocolo de atestação. O interpretador afirma um contexto segundo sua configuração; o operador decide que peso essa afirmação recebe.

Os itens iniciais deixam o escopo claro. domain e host situam a execução. location classifica MTA, MDA, MUA ou armazenamento. phase diferencia pré, durante e pós-entrega final. name e version identificam o produto. remote-host e remote-ip descrevem o cliente SMTP, LMTP ou Submission quando disponíveis.

Para version, o RFC faz uma ressalva expressa: o significado é específico do produto e deve ser considerado junto com name. Isso impede comparar números de produtos distintos como se formassem uma ordem universal. Também impede supor que a mesma string representa sempre o mesmo binário.

Capacidade, item e build são objetos diferentes

Um servidor pode anunciar environment e ainda não oferecer todos os itens. O documento recomenda suportar tantos itens iniciais quanto possível, não exige uma matriz completa em qualquer contexto.

Se um item não existe, o teste precisa retornar falso sem encerrar o script. Uma comparação :contains com string vazia descobre a existência do item. Se o item existe mas retorna vazio, RFC 5231 faz :count valer zero; se não vazio, um.

Nenhum desses estados fornece um digest de artefato. A capacidade prova que a sintaxe é compreendida. A existência prova que o nome é reconhecido. Um valor não vazio prova que alguma string foi produzida. Um controle de patch precisa de identidade do pacote ou imagem, assinatura, geração implantada e evidência de que o processo que tratou aquela mensagem carregou esse artefato.

RFC 5463 permite testar capacidades com ihave, resolvendo outro problema de portabilidade. ManageSieve administra scripts e divulga recursos. Nem uma resposta de capacidade nem o estado administrativo do script substituem o recibo runtime da mensagem.

O risco de confiança também aparece no nome remoto

O exemplo de segurança de RFC 5183 mostra que a limitação não se restringe a versões. A implementação pode determinar remote-host por qualquer técnica, com confiabilidade variável. Um método comum é o PTR da direção cliente, que pode vir de fonte não confiável.

Quem administra o reverso pode escolher um nome sob o domínio que quiser. Portanto, casar *.example.com não comprova que a mensagem veio de dentro da organização. A regra pode executar corretamente sobre uma premissa inadequada.

O registro de decisão deve guardar IP do par, consulta, resolvedor, resposta, idade do cache, validação e política de confirmação. Mesmo assim, um nome DNS não prova sozinho a função empresarial do remetente. remote-ip também representa o salto observado, que pode ser relay, proxy ou serviço compartilhado.

O princípio é idêntico ao da versão: preservar a cadeia que produz a string e limitar a conclusão ao que essa cadeia realmente suporta.

location e phase não identificam o worker

location=MS diz que um armazenamento de mensagens avalia o script. Não especifica o pod, o host físico, a imagem, a réplica ou o domínio de falha. phase=post situa a execução depois da entrega final no modelo, mas não confirma replicação, indexação ou visibilidade.

RFC 6785 usa essas etiquetas para Sieve acionado por eventos IMAP e acrescenta contexto como usuário, causa, caixa e flags alteradas. imap.mailbox fica fixo no início e não muda com fileinto. imap.changedflags não informa se cada flag foi ligada ou desligada.

Essas regras mostram que os itens são observações delimitadas. Um sistema de auditoria precisa registrar o worker real, o script carregado, a ação escolhida e o recibo do componente que realizou a mudança.

Se o objetivo é bloquear um build vulnerável, a condição decisiva não pode ser somente version. Ela precisa apontar para uma lista local de artefatos aceitos e verificar a identidade do processo. A string pode continuar útil para diagnóstico e compatibilidade, sem carregar a autoridade de um atestado.

O namespace do fornecedor não cria portabilidade

Itens padronizados e itens locais aparecem no registro IANA. Os locais começam por vnd.. O registro evita que dois produtores escolham o mesmo nome acidentalmente; não transforma a semântica local em padrão da Internet.

Uma organização pode expor vnd.fabric.generation e construir controles úteis. Ao migrar, porém, deve mapear origem, tipo, ciclo de vida e condições de atualização. Reutilizar o mesmo valor numa plataforma diferente sem esse contrato apenas preserva a aparência.

Mesmo os campos padrão precisam de uma ficha local. Quem define host em um ambiente com proxies? Qual componente publica domain? Em que ponto phase muda? Quando name e version são atualizados durante um rollout? As respostas pertencem ao running code e à operação.

O modelo de adoção voluntária é vantajoso. Cada participante pode aceitar os itens que entende e recusar os que não consegue verificar, sem declarar inválido todo o ecossistema. O erro seria criar um fallback que trata o desconhecido como aprovado.

Um gate de patch que produz evidência

O controle robusto começa com um ID de política e a lista de builds autorizados. No momento de execução, vincula hash do script, identidade criptográfica ou digest do artefato do worker, configuração e geração de rollout. name e version entram como metadados explicativos, não como raiz única.

Para qualquer teste de ambiente, o recibo registra presença, valor cru, método de derivação, location, phase, comparador e ramo. Depois acompanha a ação Sieve e o resultado de transporte ou armazenamento. Se a exigência é entrega visível, verifica a caixa final.

Essa trilha permite distinguir três falhas: string errada, build errado e efeito errado. Um dashboard que mostra apenas “versão permitida” torna as três indistinguíveis.

A pergunta de encerramento é: podemos provar qual código tomou a decisão e qual mudança ocorreu, ou apenas repetir o texto que o próprio processo informou? RFC 5183 torna o texto portável. A organização continua responsável pela prova.

Fontes

  1. RFC 5183 — HTML
  2. RFC 5183 — texto simples
  3. Página de informações do RFC Editor
  4. Documento no IETF Datatracker
  5. Histórico no IETF Datatracker
  6. Referências no IETF Datatracker
  7. Erratas do RFC 5183
  8. RFC 5228 — especificação base de Sieve
  9. Página de informações do RFC 5228
  10. RFC 5231 — extensão relacional
  11. RFC 5598 — arquitetura do correio da Internet
  12. RFC 6785 — eventos IMAP em Sieve
  13. Página de informações do RFC 6785
  14. RFC 5804 — ManageSieve
  15. RFC 5463 — extensão Sieve ihave
  16. Registro IANA de extensões Sieve
  17. Registro IANA de itens de ambiente Sieve
  18. Heng Lu — camadas da realidade
  19. Heng Lu — especificação mínima e adoção voluntária
  20. Heng Lu — primazia do código em execução