Resumo

  • A RFC 5230 definiu uma ação Sieve que gera uma nova mensagem, endereçada ao remetente do envelope da mensagem recebida, e acompanha se aquele endereço já recebeu a mesma resposta.
  • O que importava não era só o texto: a qualificação do destinatário, a identidade da resposta, os cabeçalhos contra loops e um intervalo limitado decidiam quem receberia a mensagem e quando.

A ausência podia atingir outras pessoas

Um aviso de férias parece inofensivo porque costuma ter poucas linhas. Mas a resposta automática é uma ação de saída feita em nome de alguém sem perguntar a cada destinatário. Pode revelar que uma pessoa está ausente, responder a uma lista de discussão ou circular entre dois sistemas automáticos. O desafio era definir quando o sistema não deveria falar, além do que deveria dizer.

Em 2008, a RFC 5230 acrescentou vacation ao Sieve, uma linguagem de filtragem de e-mail deliberadamente limitada. Um script podia informar que o usuário não responderia rapidamente e pedir ao interpretador que gerasse outra mensagem. Foi a primeira extensão Sieve capaz de criar uma mensagem inteiramente nova. O efeito muda de natureza: não é apenas arquivar uma carta em outra pasta; é iniciar uma comunicação externa, que pode provocar outra resposta.

O destinatário é o remetente do envelope SMTP da mensagem original — o MAIL FROM, que pode aparecer no Return-Path se o Sieve rodar após a entrega final — e não apenas o campo From visível. A nova mensagem deveria usar um envelope de envio vazio; se a extensão de notificações de entrega estivesse disponível, a recomendação era impedir que uma falha criasse outra notificação. O cabeçalho Auto-Submitted identifica o envio automático. Data, remetente, destinatário e referências descrevem uma resposta realmente gerada, em vez de fingir que ela veio do remetente original.

Um endereço, uma resposta específica, um intervalo

O estado mais importante quase passa despercebido. A extensão registra as respostas enviadas para cada endereço durante um período. A mesma pessoa pode escrever novamente durante a ausência, mas não receber a mesma mensagem em todas as tentativas. :days define o intervalo de supressão. Quando omitido, vale o maior entre sete dias e o mínimo local. O site pode impor um mínimo positivo e um máximo; valores fora da faixa são limitados. Portanto, o número no script não é necessariamente o intervalo efetivo.

Não é um sinal global de “já estamos de férias”. O sistema diferencia qual resposta aquela pessoa recebeu. Um :handle explícito permite que várias declarações de vacation compartilhem uma identidade. Sem ele, a identidade é derivada de :subject, :from, :mime e do texto da resposta. Assim, ramos distintos podem dar respostas diferentes ao mesmo remetente, enquanto comandos com argumentos idênticos compartilham o histórico de supressão. Quando o Sieve usa a extensão de variáveis, os argumentos não devem ser expandidos antes desse cálculo: a identidade é formada pelos argumentos declarados, não por um valor que muda a cada execução.

O intervalo funciona como uma pequena base de políticas. A chave combina o endereço do remetente com a identidade da resposta. Isso evita repetição inútil sem impedir um aviso novo, para uma circunstância diferente. O autor do script decide quais respostas são equivalentes; o operador limita a frequência efetiva.

A resposta precisava chegar a quem estava ausente

A RFC 5230 exige que o endereço do usuário esteja em To, Cc, Bcc ou campos Resent correspondentes para que haja resposta. O servidor pode reconhecer esse endereço nos dados da conta, no destinatário final do envelope ou numa lista :addresses de aliases. A lista ajuda quem usa vários endereços, mas encaminhamento e subendereçamento podem impedir que ela fique completa.

Há também barreiras contra sistemas e listas. A implementação deve manter endereços que nunca podem receber uma resposta de férias; a RFC cita nomes comuns de daemons e ferramentas de administração de listas. Ela recomenda não responder a mensagens com cabeçalhos de controle de lista nem àquelas cujo Auto-Submitted tenha um valor diferente de no. A implementação também pode suprimir mensagens cujo conteúdo ou cabeçalhos indiquem que a resposta seria inadequada. Não há garantia de que todo servidor reconheça todo fluxo automático: parte da lista é definida pelo operador e depende do que o sistema consegue observar.

A RFC 3834, de 2004, já trazia recomendações mais amplas para respostas automáticas. A RFC 5230 diz que a vacation foi concebida em conformidade com essa orientação para personal responders. Depois, a RFC 6131 acrescentou :seconds, inclusive zero para responder a cada mensagem; a RFC 6133 mostrou a composição com presença e agenda de contatos; e a RFC 8580 permitiu guardar uma cópia local da resposta gerada. Esses documentos registram possibilidades de projeto, não a frequência com que foram implantadas.

A mensagem não era só o texto

A extensão aceita UTF-8 e MIME, inclusive alternativas em vários idiomas. Um script pode escolher a língua pelos cabeçalhos, mas a RFC alerta que uma comparação simplista pode ser enganada. Ela também observa que o tom pode depender de a pessoa ser uma colega ou alguém desconhecido, não apenas do idioma. Escolher a resposta é também decidir para quem ela faz sentido.

A ação é restrita: pode ocorrer uma vez por script, não é compatível com reject ou refuse e não cancela o keep implícito do Sieve. Isso a situa na linguagem, mas não repete a discussão geral da RFC 3028 sobre seleção de ações. A contribuição própria da RFC 5230 é a política em torno de uma nova mensagem de saída: destinatário, identidade da resposta, cabeçalhos e intervalo.

As fontes demonstram o desenho, não que toda implementação tenha sido segura. O servidor talvez não saiba se a mensagem foi enviada diretamente à pessoa ou se um alias encaminhado pertence ao mesmo usuário. O padrão reúne testes observáveis e memória limitada para conter um automatismo tentador. O aviso de ausência nunca foi apenas um texto salvo: era uma autorização para enviar, dirigida a alguém e sujeita a um relógio.

Fontes