Resumo

  • RFC 3028 transformou filtragem de e-mail em uma linguagem limitada de ações e adotou retenção implícita quando nenhuma ação que afetasse a entrega fosse executada.
  • keep, fileinto, redirect, discard e rejeição eram decisões no limite do interpretador, não comprovantes de armazenamento, aceitação remota ou desfecho final.

Levar regras pessoais para um servidor de entrega criava um paradoxo. O usuário queria classificar e encaminhar mensagens antes de abrir a caixa postal. O operador não podia oferecer um ambiente de programação geral no mesmo equipamento. Laços, programas externos e consumo sem limite poderiam fazer de uma conveniência individual um risco coletivo.

RFC 3028 respondeu com uma linguagem deliberadamente menor. Sieve não tinha laços, funções nem acesso a comandos externos. Testes não podiam gerar efeitos colaterais. Controles escolhiam blocos; ações concentravam mudanças. A simplicidade tornava as regras legíveis e, sobretudo, limitava o que uma conta podia pedir ao servidor.

A ausência de correspondência ganhou um padrão seguro

Filtros inevitavelmente deixam casos de fora. Um remetente muda de domínio, uma lista altera cabeçalhos ou uma condição nasce incompleta. Se atravessar todos os ramos sem correspondência significasse perder a mensagem, cada erro de cobertura viraria dano.

Sieve definiu então a retenção implícita. Na ausência de uma ação que a cancelasse, o sistema aplicava seu tratamento normal, em geral gravando a mensagem na caixa principal. Não era uma cópia extra depois de qualquer regra. keep, fileinto, redirect e discard cancelavam a proteção. Extensões posteriores precisavam declarar sua relação com ela.

O comportamento de discard revela a estrutura. A ação cancelava silenciosamente a retenção implícita, mas permitia que outras ações compatíveis continuassem. fileinto mais discard ainda guardava a mensagem na pasta especificada e apenas removia a cópia padrão. A norma não dependia do significado cotidiano do verbo; descrevia sua interação no conjunto de ações.

Cada ação terminava em outro controlador

keep solicitava o destino padrão sem exigir que o autor soubesse o nome físico da caixa ou a tecnologia de armazenamento. Essa abstração oferecia portabilidade. Também impedia concluir, a partir da avaliação bem-sucedida, que espaço, permissões e confirmação da gravação estavam garantidos.

fileinto apontava uma pasta. RFC 3028 recomendava suporte, mas admitia ambientes incapazes de oferecê-lo. O nome era uma instrução ao agente de entrega, não prova de existência ou persistência.

redirect substituía o destinatário do envelope e iniciava um encaminhamento de estilo MTA. O servidor local podia selecionar e tentar a ação; o servidor remoto ainda controlava a aceitação. A prevenção de laços também dependia da implementação. Redirecionar abria outra etapa de transporte, não emitia seu recibo final.

discard tinha de permanecer silencioso, sem relatório de não entrega. A ausência de sinal para o remetente era parte da semântica. Quando a auditoria fosse necessária, o operador precisaria preservar evidência proporcional do lado executor, não inferir o resultado pela falta de retorno.

A composição das ações limitava amplificação

Várias condições podiam produzir várias ações para a mesma mensagem. Por isso, RFC 3028 exigia que extensões declarassem como interagiam com o núcleo. A política local podia limitar quantidade e combinações. Mesmo quando um script pedisse duas gravações na mesma caixa, a implementação deveria evitar duplicidade.

Essas restrições tratavam efeitos sistêmicos. Muitos redirecionamentos poderiam gerar uma bomba de correio. Rejeitar e entregar ao mesmo tempo diria ao remetente que houve falha enquanto uma cópia era mantida. Executar cada verbo de forma independente destruiria a coerência da decisão.

RFC 5228 substituiu RFC 3028, preservou a retenção implícita e esclareceu erros, limites e extensões. RFC 9122 criou depois o registro IANA de ações Sieve, com campos sobre interações e cancelamento da retenção implícita. O registro documenta o contrato de cada ação; não relata o sucesso de uma mensagem específica.

Rejeitar depois de aceitar produzia outro tipo de dano

O reject original de RFC 3028 descartava a mensagem e enviava uma notificação de disposição ao remetente do envelope. O sistema receptor podia já ter aceitado o correio. Se o endereço estivesse falsificado, a notificação atingia uma pessoa inocente e alimentava retorno indevido.

RFC 5429 acrescentou ereject, que prefere recusar durante SMTP ou LMTP quando o componente consegue fazê-lo. Também esclareceu que rejeição cancela a retenção implícita, proibiu mais de uma rejeição e desaconselhou sua combinação com ações de entrega. O motivo era coerência: não se deve anunciar que uma mensagem falhou quando ela também foi armazenada ou encaminhada.

“Rejeitada” poderia, portanto, esconder fatos distintos. O script escolheu a ação; o componente conseguiu ou não recusar no protocolo; o remetente observou resposta imediata, aviso posterior ou silêncio. O estado sem camada e evidência era incompleto.

ManageSieve, em RFC 5804, padronizou outra superfície: enviar, validar, listar e ativar scripts. Um script ativo não prova avaliação de uma mensagem. Uma avaliação que escolheu ação não prova o resultado. Administração, decisão e efeito exigem registros próprios.

Fontes

Lu Heng não escreveu nem endossou RFC 3028, RFC 5228 ou RFC 5429. Seus ensaios são usados aqui como lentes analíticas declaradas.