Resumo

  • A RFC 6154, de março de 2011, definiu atributos opcionais para respostas IMAP LIST. Com \Sent, \Drafts e \Trash, um aplicativo pode descobrir a função de uma caixa sem depender do nome exibido ao usuário.
  • Uma marca de \Sent tanto pode acompanhar arquivamento automático pelo servidor quanto aconselhar o cliente a salvar cópias ali. Uma caixa pode ter várias marcas, e mais de uma caixa pode receber a mesma marca.
  • LIST estendido pode anunciar SPECIAL-USE; CREATE e METADATA permitem pedidos opcionais de criação ou mudança de função, que o servidor pode rejeitar. O registro da IANA mantém os nomes dos atributos e as especificações que os definem.

O nome parecia uma instrução e não era

Uma conta é aberta em dois programas. O primeiro usa a pasta que encontrou para guardar cópias enviadas. O segundo não reconhece o nome e cria outra. O histórico de mensagens da pessoa se divide. Em outra configuração, nenhum salva cópia: ambos esperam que o servidor o faça, enquanto o servidor espera o cliente. O resultado parece um detalhe de interface até a pessoa precisar provar o que escreveu e não encontrar a mensagem.

Um guia de implementação IMAP de 1999 mencionava nomes convencionais como “Sent Mail” e “Trash”. Convenções tornam a lista legível para humanos, mas não são uma linguagem segura entre programas. O servidor pode dar outro nome à pasta, o usuário pode renomeá-la, e um título familiar não esclarece quem colocará mensagens nela. O aplicativo transformava uma decisão de operação em um palpite sobre palavras.

A RFC 6154 pôs as funções nos atributos devolvidos pelo LIST. As sete marcas iniciais foram \All, \Archive, \Drafts, \Flagged, \Junk, \Sent e \Trash. O servidor pode entregá-las com os demais atributos de cada caixa. O nome visível pode continuar SentMail, MyDrafts ou qualquer nome pessoal; a função tem sua própria forma legível para máquina.

Isso deslocou a primeira resposta para quem conhecia a disposição das pastas. Um cliente recém-instalado não sabe que caixas o servidor reservou. O servidor pode declará-las. O usuário ainda pode escolher como usar a conta, mas deixa de ser obrigado a traduzir a arquitetura interna do serviço toda vez que troca de aplicativo.

A marca não executa o trabalho

O texto da RFC 6154 reconhece duas versões de \Sent. Alguns servidores colocam automaticamente ali as cópias de mensagens enviadas. Em outros, a marca só indica onde o cliente deve guardá-las. Se o aplicativo esperar o primeiro comportamento diante do segundo servidor, a caixa ficará vazia. Se salvar outra cópia quando o servidor já a salvou, pode produzir duplicatas. A marca indica um destino previsto, não o agente que executou o arquivamento.

As outras funções também dependem de mecanismos distintos. \All costuma ser uma visão virtual e pode deixar de fora \Trash ou \Junk. O significado de \Archive depende do serviço. \Drafts pode agregar mensagens marcadas como rascunho ou aconselhar o aplicativo a depositá-las ali. \Trash pode refletir o modelo de exclusão do servidor ou servir ao cliente que não segue diretamente a marca IMAP \Deleted. O vocabulário comum torna as diferenças visíveis; não elimina as diferenças.

Uma caixa pode não ter função especial, ter uma ou carregar várias. Duas caixas podem ter \Sent. As funções tendem a ser próprias de cada usuário: compartilhar uma caixa física não significa compartilhar a escolha da caixa de enviados. Se o programa supõe uma única resposta para todo mundo, apenas substituiu o palpite baseado no nome por um palpite baseado na marca.

O registro de atributos de caixas IMAP da IANA coordena os nomes e as referências. Não registra cópias de mensagens nem sabe qual aplicativo as guardou. A linha Sent é uma palavra em comum, não uma cópia do histórico do usuário.

Descobrir, pedir e receber são etapas diferentes

A extensão foi encaixada no LIST estendido. O servidor que o suporta anuncia SPECIAL-USE em CAPABILITY. O cliente pode pedir só as caixas que trazem marca especial ou solicitar as marcas junto da listagem; a seleção implica a devolução dos atributos. Um LIST comum também pode trazer essas marcas, sem uma cadeia de capacidade separada para essa forma. Uma leitura correta da conexão exige acompanhar o comando e a resposta, não procurar uma palavra isolada.

Além de descobrir, o cliente pode pedir uma nova caixa já marcada. RFC 6154 definiu o parâmetro opcional USE para CREATE, anunciado separadamente por CREATE-SPECIAL-USE. O servidor pode recusar conflitos, transferir uma função antiga ou permitir duas caixas com o mesmo papel. Se não conseguir criar a caixa com a função solicitada, deve rejeitar a operação inteira e não criar a caixa. Um pedido recusado não vira configuração só porque o cliente desejava que desse certo.

Em servidores com IMAP METADATA, /private/specialuse pode expor ou alterar funções de caixas existentes. O servidor precisa validar mudanças em vez de aceitar cegamente funções que não suporta. Trocar o nome visível, pedir uma função e mover uma mensagem são operações separadas. Cada uma deixa uma resposta diferente.

Uma marca pode acionar comportamento automático. A RFC 6154 dá o exemplo de \Junk: quando o servidor envia para lá o que classificou como lixo, permitir que um usuário atribua essa função a uma caixa compartilhada pode revelar a outras pessoas mensagens legítimas classificadas por engano. A pequena etiqueta passa a ser uma alavanca de configuração; cabe ao servidor decidir quem pode movê-la.

As especificações mostram como funções são anunciadas e solicitadas. Para saber onde uma conta determinada guardou uma mensagem, faltam respostas CAPABILITY/LIST datadas, eventuais comandos CREATE ou METADATA e o destino observado da cópia. O nome pintado na gaveta informa menos que essas três provas.