Resumo

  • O RFC 9661 separa o envio dos bytes, a validação, o armazenamento do SieveScript e a ativação de um único script por conta.
  • Uma resposta bem-sucedida de SieveScript/set comprova a transição do objeto, não que todos os workers carregaram o blob nem que uma mensagem recebeu a ação esperada.
  • O comprovante defensável liga hash do blob, capacidades, estado condicional, ativação, releitura entre interfaces, geração do worker, rastreio da mensagem e resultado final.

Na ponte de incidente, duas equipes defendem verdades diferentes. A equipe de API mostra a resposta: o novo script está ativo. A equipe de correio mostra a caixa: a mensagem de teste caiu onde a regra antiga mandava. O erro é exigir que uma evidência invalide a outra. Elas medem etapas distintas.

O RFC 9661 define um modelo JMAP para administrar scripts Sieve. Cada objeto possui id definido pelo servidor, nome único, blobId e isActive; no máximo um pode ficar ativo. A norma torna o estado lógico claro, mas não escolhe como um provedor replica, compila, invalida cache ou atualiza processos de entrega final.

Quatro operações, quatro significados

O upload confirma que bytes chegaram. SieveScript/validate verifica o conteúdo sem armazená-lo como script. A validação cobre sintaxe e extensões declaradas, mas o RFC 5228 diferencia falhas de compilação e de execução. Um script válido ainda pode falhar diante de uma mensagem real, de falta de recursos ou de uma combinação de ações.

Na mutação, as regras gerais do RFC 8620 oferecem ifInState. Se outro ator alterou a coleção, a escrita pode ser recusada em vez de sobrescrever estado novo. É controle de concorrência do objeto; o token opaco não atesta o código residente nos workers.

Na ativação, onSuccessActivateScript só troca o ativo se as demais operações tiverem sucesso. A resposta deve mostrar o objeto ativado e o desativado. Essa atomicidade fecha a transação JMAP, não a distribuição interna. Uma réplica atrasada, fila de invalidação congestionada ou regra compilada em memória pode prolongar a geração anterior.

Paridade de interface não é paridade de execução

O padrão foi desenhado para que JMAP e ManageSieve ofereçam acesso consistente aos mesmos scripts. Reler nome e conteúdo por ambos os caminhos depois da ativação é um ótimo controle. A divergência denuncia problema de armazenamento ou projeção.

A concordância, porém, ainda não inclui o worker. Os dois protocolos podem consultar a mesma fonte enquanto parte da frota usa um cache antigo. Por isso o registro útil precisa juntar conta, id, hash, geração ativa, worker, identificador da mensagem e decisão tomada.

O resultado também precisa de semântica. Uma mensagem no diretório esperado é evidência positiva. Uma mensagem ausente não prova discard: rejeição anterior, atraso, antispam, rota errada e falha de armazenamento competem pela mesma aparência. Testes devem entrar pelo caminho real, usar identificador único, guardar aceitação e observar o worker e a ação de entrega.

O caso de férias mostra quem pode escrever

O RFC 8621 define VacationResponse. Quando ela é implementada como script Sieve, o RFC 9661 permite buscá-la e ativá-la por JMAP Sieve, mas proíbe alterar ou destruir seu conteúdo com SieveScript/set. O conteúdo pertence ao fluxo VacationResponse/set.

Isso impede que duas superfícies legítimas virem autores equivalentes. O hash deve vir acompanhado da origem: editor Sieve, férias, restauração, ManageSieve ou automação. Um objeto correto alterado pela autoridade errada é um sucesso técnico e uma falha de controle.

O RFC 9404 melhora a gestão de blobs; o RFC 9425 expõe cotas; o registro JMAP da IANA coordena capacidades, tipos e erros. Nenhum deles observa o destino de uma mensagem particular.

Começar pelo efeito

Defina a ação esperada da mensagem de teste. Registre o worker que a processou e a geração carregada. Resolva essa geração até o id ativo e o hash exato do blob. Preserve resposta de ativação, estados antigo e novo, ifInState, validação e snapshot de capacidades. Releia o conteúdo por JMAP e ManageSieve.

Inclua falhas deliberadas: id inexistente não pode mudar o ativo; destruir o ativo deve gerar sieveIsActive; um caso válido com erro de execução controlado deve ser classificável; um script de férias deve rejeitar a escrita pelo dono errado. Cota, reinício e atraso de propagação também precisam de ensaio.

A especificação inicial mínima de Heng Lu preserva um contrato comum pequeno e auditável sem fingir que ele resolve a implementação local. As camadas da realidade impedem que “ativo” tome emprestada a autoridade de “executado”. A primazia do código em funcionamento leva a decisão ao ponto onde a mensagem foi realmente tratada.

O RFC 9661 organiza o controle. A liderança ainda precisa exigir o comprovante da execução.

Fontes