Resumo

  • A seleção por uso especial procura primeiro uma caixa postal no espaço pessoal do usuário. O destino indicado pelo nome entra em cena quando não há correspondência ou o atributo é desconhecido pela implementação.
  • Se a entrega falha na caixa escolhida por um motivo alheio à existência dela, o Sieve não pode tentar em seguida a pasta padrão. Isso evita espalhar mensagens conforme a disponibilidade momentânea do armazenamento.
  • Inicialização de funções, escolha entre várias caixas, permissões e capacidade exigem evidências distintas. Um filtro intacto pode produzir outro destino quando as atribuições mudam.

Os dois lados esperavam que o outro começasse

Uma funcionalidade pode existir no cliente e no servidor sem que ninguém tenha preparado o estado necessário para usá-la. Foi esse o problema descrito no registro 4422 das erratas da RFC 6154.

O relato trata de um teste informal de interoperabilidade realizado em 19 de julho de 2015. Um servidor esperava que o cliente estabelecesse os atributos de uso especial das caixas postais; um cliente esperava que o servidor fizesse essa preparação. A concordância sobre o mecanismo não resolveu a divisão do trabalho inicial.

O registro está classificado como Held for Document Update. As soluções sugeridas nele não são novas exigências obrigatórias já incorporadas à especificação. O relato tampouco permite diagnosticar um produto atual. Seu valor é mostrar uma lacuna concreta de responsabilidade: saber trocar um atributo não significa que alguém tenha assumido a tarefa de atribuí-lo.

Para um filtro de correio, essa lacuna pode ficar escondida. Se existe uma pasta indicada pelo nome, as mensagens continuam sendo guardadas nela. O contador de sucesso não revela que a seleção pela função pretendida nunca chegou a entrar em operação.

Primeiro a função, depois o nome

A RFC 6154 definiu atributos como \Archive, \Sent e \Junk para ajudar clientes IMAP a identificar a finalidade de uma caixa postal. Isso reduz a necessidade de adivinhar pelo nome qual pasta guarda arquivos, cópias de mensagens enviadas ou conteúdo considerado indesejado.

Um usuário pode dar nomes diferentes à mesma função ao trocar de idioma ou reorganizar a conta. Também pode conservar uma pasta chamada Arquivo sem que ela continue sendo o destino de arquivamento preferido. Nome e função são referências relacionadas, mas não equivalentes.

A RFC 8579 levou essa seleção ao Sieve. Com o argumento :specialuse, a ação de classificação procura uma caixa que tenha o atributo solicitado no espaço de nomes pessoal do usuário. Encontrando-a, usa essa caixa em vez do destino indicado pelo nome convencional da ação.

Se nenhuma caixa correspondente for encontrada, ou se a implementação não conhecer o atributo, a ação segue como seguiria sem o argumento especial. O nome padrão volta a determinar o tratamento ordinário do destino.

Esse desenho oferece uma compatibilidade importante com contas sem atribuições preparadas. Mas a compatibilidade se aplica a uma condição definida: não conseguir resolver o destino pela função. Não é uma ordem para tentar qualquer lugar disponível até que alguma gravação funcione.

Uma caixa cheia continua sendo uma caixa encontrada

Considere agora uma situação construída para explicar a regra. O atributo de arquivamento está devidamente atribuído e o filtro encontra a caixa correta. A gravação da próxima mensagem, porém, ultrapassaria a cota. Outra pasta, cujo nome também consta da ação, ainda tem espaço.

Guardar ali parece uma forma simples de manter o serviço. Só que a escolha já foi feita. A capacidade insuficiente não apagou a caixa nem desfez a atribuição da função.

A RFC 8579 determina que, se a entrega à caixa especial falhar por razões sem relação com sua existência, o interpretador não deve tentar depois o destino padrão. Deve seguir o comportamento ordinário de falha da ação. Esse trecho não define uma política universal de enfileiramento, devolução ou descarte; define uma substituição que não pode ocorrer.

A justificativa é a consistência da localização. Falhas intermitentes não deveriam fazer o correio se espalhar inesperadamente por duas caixas. Caso contrário, a disponibilidade do armazenamento passa a classificar a correspondência: as mensagens de um intervalo ficam no arquivo, as do período problemático vão para outra pasta, as seguintes voltam ao arquivo.

Tudo pode ter sido gravado em algum lugar e, ainda assim, o serviço original ter sido alterado. Um cliente que consulta a função de arquivo, uma pessoa que verifica apenas aquela pasta e um processo que acompanha novas mensagens ali não recebem necessariamente a mesma visão.

O argumento legítimo da continuidade

É possível preferir uma entrega em outro lugar a uma interrupção. Essa preferência não é irracional, nem precisa ser descartada em nome de uma leitura mecânica do protocolo.

Ela exige, contudo, uma decisão adicional. Quem autoriza o novo local? Como o usuário descobre a mudança? Os demais clientes passam a acompanhá-lo? Quem confere e reúne o material que ficou dividido? Uma pasta padrão destinada ao caso de função ausente não responde a essas perguntas.

A regra impede que o sistema tome essa decisão por conta própria apenas para eliminar um erro. Ela não elimina a responsabilidade por restaurar capacidade ou tratar a mensagem que não pôde ser arquivada.

A disponibilidade precisa ser recuperada sem esconder a alteração de significado. Essa é uma obrigação operacional mais exigente do que simplesmente conseguir uma escrita em algum ponto do armazenamento.

O teste não promete a próxima gravação

O nome specialuse_exists pode sugerir uma verificação definitiva. Na prática, ele estabelece condições delimitadas sobre caixas, atributos e permissão de entrega no contexto do usuário que executa o script.

Quando não se especifica uma caixa, cada atributo solicitado deve existir em pelo menos uma caixa do espaço pessoal que permita entrega. Atributos diferentes podem ser atendidos por caixas diferentes. Quando uma caixa é indicada explicitamente, ela deve existir, permitir entrega e possuir todos os atributos da lista.

A possibilidade de entrega é definida a partir da RFC 5490. O documento ressalta que um teste de existência bem-sucedido não garante o sucesso posterior da ação de arquivamento. A mensagem pode, por exemplo, exceder a cota disponível.

Não há contradição entre permissão válida e gravação malsucedida. O teste não reserva espaço para o conteúdo que virá nem garante que todas as condições permanecerão iguais. Ele responde a uma pergunta de existência e autorização, não registra uma operação já concluída.

Por isso, o histórico útil precisa ligar o contexto do usuário, as atribuições consultadas, a caixa selecionada e o resultado efetivo. Um único indicador de pré-verificação aprovada apaga justamente a separação necessária para investigar a falha.

O mesmo atributo pode levar a escolhas diferentes

Uma função especial não precisa ter uma única caixa correspondente. A RFC 8579 admite várias caixas pessoais com o mesmo atributo.

Se a caixa indicada pelo nome padrão estiver entre essas correspondências, ela deve ser escolhida. O nome funciona, nesse caso, como critério obrigatório de desempate. Se não estiver entre as opções, a escolha é definida pela implementação.

A especificação recomenda consistência enquanto as atribuições relevantes permanecerem iguais. Quando elas mudam, a caixa escolhida também pode mudar. Não há um algoritmo universal que faça dois sistemas selecionar sempre o mesmo destino entre várias correspondências.

Essa flexibilidade permite reorganizar o armazenamento sem editar todos os filtros. Também cria uma obrigação de observação: uma comparação que mostre scripts idênticos não prova que os próximos depósitos irão para o mesmo lugar. O estado de atribuições participa da decisão.

Em uma migração, preservar os atributos e seus nomes pode conservar o vocabulário sem conservar o resultado da seleção. A aceitação do novo serviço precisa considerar esse resultado, não apenas a fidelidade da cópia dos arquivos de configuração.

Mesmo a função Archive tem significado dependente do servidor na RFC 6154. O atributo não certifica prazo de retenção, imutabilidade ou uma obrigação legal específica. Reconhecer um local de arquivamento é diferente de comprovar o regime de conservação que a organização espera dele.

Criar a pasta não conclui toda a preparação

Quando nem a caixa especial nem o destino padrão existem, aplicam-se as regras ordinárias de destino inexistente. O argumento explícito :create solicita que a caixa indicada pelo nome seja criada quando necessário.

Se o servidor admite CREATE-SPECIAL-USE, a RFC 8579 recomenda atribuir a função pedida à nova caixa. Essa recomendação não deve ser apresentada como uma garantia independente das capacidades e do comportamento da implementação.

A criação com uso especial é uma capacidade opcional separada. Alterações de atribuição por metadados também dependem do suporte do servidor, que deve validar mudanças que aceita. Não basta presumir que todo cliente possa atribuir qualquer função a qualquer local.

Uma pasta nova que já recebe mensagens pode, portanto, existir sem que a configuração baseada em funções tenha sido concluída. O sucesso por nome é um resultado real, mas não comprova que o serviço esteja usando o mecanismo esperado. O episódio de interoperabilidade registrado em 2015 ajuda a tornar visível esse trabalho de preparação, sem transformar uma sugestão histórica em mandato atual.

O limite da busca também limita influência

A seleção por atributo fica restrita ao espaço pessoal do usuário. Procurar no armazenamento inteiro poderia encontrar mais candidatas, mas também aumentaria a carga e abriria a possibilidade de mensagens serem dirigidas, inesperada ou maliciosamente, a caixas compartilhadas.

A pergunta deixa de ser apenas onde há uma função e passa a ser quem consegue tornar um local elegível para receber o correio de outra pessoa. Uma atribuição em uma caixa compartilhada não deveria ganhar essa influência por causa de uma busca ampliada informalmente.

A restrição da RFC 8579 se aplica à descoberta por uso especial. Ela não garante que toda caixa pessoal jamais seja compartilhada, nem estende automaticamente o mesmo requisito a qualquer destino padrão explicitamente nomeado. A RFC 6154 alerta separadamente que certas funções podem provocar ações automáticas e expor correspondência privada em locais compartilhados.

Manter o alcance exato dessas regras evita trocar uma limitação útil por uma promessa de segurança que ela não fornece.

Fontes e limites da análise

Este artigo não relata uma inspeção de conta, incidente ou implementação de fornecedor. A errata técnica verificada 5877 da RFC 8579 corrige um operador de correspondência em um exemplo posterior; não altera a regra que separa seleção e falha de entrega. Nenhum dos exemplos do protocolo foi executado nesta pesquisa.

A análise de Lu Heng sobre o problema de agência oferece uma lente: quem decide pode não arcar com o custo que transfere. O serviço que grava em outra pasta melhora seu indicador, enquanto o usuário e a equipe de suporte recebem a tarefa de reconstruir a correspondência.

A definição do propósito de BTW pede descrição estrutural, não campanha. Aqui, descrever corretamente significa mostrar que uma capacidade disponível não amplia, sozinha, a autorização de uso. A pasta padrão resolve uma ausência particular. A falha do destino escolhido continua exigindo uma resposta própria.