Resumo

  • A RFC 5232 permite que o Sieve monte e consulte um conjunto de flags para a mensagem em processamento e o associe à cópia entregue por keep ou fileinto.
  • Isso não transforma o filtro numa ferramenta geral de edição do armazenamento IMAP: flags que a caixa não possa guardar permanentemente devem ser ignoradas, sem provocar falha de execução do script.

A marca acompanha a decisão de entrega

Uma mensagem recebida passa por análise, roteamento e, por fim, chega a uma caixa postal. Uma flag IMAP é um estado associado à mensagem armazenada. Publicada em janeiro de 2008, a RFC 5232 conectou a filtragem Sieve a esse estado, mas manteve a diferença entre decidir o destino da mensagem atual e alterar uma caixa inteira.

A extensão imap4flags exige quatro ações ou testes — setflag, addflag, removeflag e hasflag — e acrescenta o argumento :flags a keep e fileinto. As três primeiras operam sobre conjuntos de flags; o teste verifica se determinados nomes estão presentes. O argumento na ação de entrega leva um conjunto para a cópia da mensagem que está sendo encaminhada à caixa de destino.

Esse conjunto tem duração local à execução do Sieve. A variável interna começa vazia. setflag substitui o conteúdo; addflag acrescenta; removeflag retira nomes; hasflag verifica o conjunto atual. Se o mecanismo também oferece a extensão Variables, o script pode manter conjuntos nomeados. Sem ela, informar um nome de variável causa erro, mas o conjunto interno continua disponível. Os nomes das flags não diferenciam maiúsculas e minúsculas. O script não deve depender da preservação de ordem, grafia ou duplicatas.

A passagem decisiva ocorre na entrega. Quando keep ou fileinto recebe :flags, a lista indicada vale para a cópia armazenada. Se o argumento for omitido, vale o conteúdo atual da variável interna. A mesma regra alcança o keep implícito — o comportamento padrão quando nenhuma ação explícita de entrega o substitui. Uma ramificação pode adicionar um marcador e deixá-lo seguir com a ação posterior, ou especificar outro conjunto no momento de arquivar.

O escopo, porém, é a mensagem que aquela execução do Sieve está processando. A RFC 5232 não permite escolher uma mensagem antiga na caixa e alterar suas flags. Também não alcança uma mensagem diferente criada como efeito colateral de outra ação. É um ponto de integração na entrega, não uma API para reescrever qualquer estado armazenado em IMAP.

A caixa de destino é outro limite. :flags expressa quais flags devem acompanhar a cópia, mas não garante que todo armazenamento possa conservá-las permanentemente. O intérprete deve ignorar as que não puder salvar de forma permanente e não pode transformar apenas isso numa falha de execução do Sieve. A RFC usa o exemplo de fileinto :flags "\\Deleted": se a caixa não puder guardar essa flag, o resultado equivale a fileinto sem a solicitação. Em IMAP, \\Deleted marca a mensagem para expurgo posterior; não é um comprovante de apagamento físico.

Por isso, “a regra marcou a mensagem” pode esconder etapas diferentes: uma condição foi avaliada; o intérprete montou a lista; uma ação pediu seu uso; o armazenamento conservou parte ou nada dela de modo permanente; um cliente exibiu o estado depois. São evidências distintas. A RFC 5232 também não determina se o intérprete se conecta ao servidor como cliente IMAP ou acessa diretamente o armazenamento. A arquitetura pode variar, mas o escopo da extensão continua sendo a mensagem atual.

Quando ações diferentes acabam reunidas numa cópia após eliminação de duplicatas, a norma define a precedência: deve prevalecer o último conjunto de flags. A cópia que sobra não necessariamente reúne todas as intenções registradas em ramificações anteriores. É preciso acompanhar a ordem das ações e a lógica de entrega; somar cada addflag encontrado no script não revela o estado final.

A RFC 5232 faz parte da família Sieve ao lado da linguagem básica da RFC 5228, das variáveis da RFC 5229 e dos testes relacionais da RFC 5231. Esses documentos explicam como instruções e valores são processados, sem deslocar o limite de entrega. Mais tarde, a RFC 9051 distinguiu flags permanentes das que duram apenas a sessão e marcou \\Recent como obsoleta. Pedir uma flag e provar que o estado ficou guardado são coisas diferentes. O padrão descreve um contrato, não demonstra que um servidor específico o implementou, que a mensagem chegou ao leitor ou que a interface mostrou um símbolo.

Fontes