Extensões de protocolo IMAP 4

Transcrição

1 Extensões IMAP ANÁLISE Extensões de protocolo IMAP 4 Um conjunto de extensões de protocolo mantém o legado IMAP 4 utilizável, o que também ajuda os clientes móveis. Apresentamos uma mistura saudável de extensões úteis. por Patrick Ben Koetter e Kristian Kissling Quando a primeira versão do Internet Message Access Protocol 4 (IMAP 4) apareceu, em 1994, os telefones celulares pareciam mais com tijolos do que com telefones propriamente ditos e não era possível ir muito além disso. Os dados digitais corriam pela Internet através de modems em doses homeopáticas. O Universal Mobile Telecommunications System (Sistema Universal de Telecomunicações Móveis ou UMTS) e clientes de móveis sequer existiam e o ganhava terreno timidamente. Demanda crescente Para adaptar o IMAP 4 às exigências modernas e especialmente de clientes móveis, o Network Working Group of the Internet Engineering Task Force enriqueceu o protocolo IMAP com uma série de RFCs com extensões que oferecem novos recursos ao IMAP, mas sem incomodar clientes e servidores que utilizam versões mais antigas. Muitas das extensões de protocolo ainda estão na fase de proposta; a wiki IMAP não oficial [1] contempla uma lista bastante abrangente (figura 1) se o usuário estiver interessado em saber mais. Algumas destas extensões são também parte do perfil do Lemonade (licença para aprimorar o acesso à rede orientado por mensagem para diversos ambientes). Sob este guarda-chuva, a RFC 4550 [2] reuniu mais de 20 extensões do protocolo IMAP explicitamente para melhorar a comunicação com os clientes móveis. Embora seja possível que nenhum servidor tenha implementado as extensões mais exóticas, os administradores estão surpresos de que precisem habilitar outras extensões no servidor por não serem parte integrante do protocolo (tabela 1). Neste artigo, apresentamos uma seleção de extensões comumente usadas e explicamos brevemente sua utilidade. Mais detalhes estão disponíveis nas RFCs relacionadas, que muitas vezes possuem dezenas de páginas. Figura 1 Esta matriz tenta esclarecer quais servidores IMAP implementam quais melhorias. Descobertas: CAPABILITY O comando CAPABILITY [3] não é uma extensão, mas um recursoimportante do IMAP 4. O cliente a utiliza para descobrir quais extensões o servidor suporta. O servidor retorna uma longa linha que lista as capacidades como palavras- 70

2 Extensões IMAP ANÁLISE -chave. Se o ID do comando [4] é habilitado no lado do servidor, o cliente tem permissão para enviar informações sobre si mesmo para o servidor, como o número de versão e nome. No entanto, a RFC dispõe que servidor e cliente não devem usar esta informação para tentar contornar os erros; em vez disso, eles devem ajudar o postmaster a identificar erros e a notificar o fornecedor do software. Observador silencioso: IDLE De acordo com o protocolo IMAP 4, o cliente deve informar ativamente ao servidor por um novo disponível, ou por alguém que tenha excluído mensagens existentes, apesar de fazer mais sentido ao servidor notificar o cliente quando um novo chega, já que tais pedidos sob demanda acabam por salvar recursos. Embora o servidor possa ocasionalmente responder com EXISTS (por exemplo, se for alterado o tamanho das caixas de correio), o cliente não pode contar com este comportamento e terá que solicitá-lo de qualquer maneira. Se o servidor retorna IDLE [5] como um recurso, o cliente pode permitir que ele envie mensagens não solicitadas sobre o novo , enquanto o cliente estiver no modo IDLE. Para permitir isso, o cliente envia um comando IDLE para o servidor, que responde com um pedido de continuação (+). Enquanto existir o status IDLE, o servidor pode enviar mensagens sem sequência numérica (não tagueadas), tais como EXISTS ou EXPUNGE. O cliente em si não pode enviar quaisquer comandos próprios neste momento. A relação master/slave termina assim que o cliente envia um DONE. Neste caso, o servidor envia quaisquer linhas não tagueadas e responde com um número de sequência para o DONE. Se o cliente não consegue terminar o comando IDLE enviando DONE, o servidor pode jogá-lo fora, assumindo um tempo limite definido. Assim, a RFC recomenda que os clientes enviem outro IDLE aos 29 minutos para evitar este problema. Pré-filtrado: NOTIFY O IDLE tem a desvantagem de não controlar nem limitar quais comandos o servidor envia e como ele responde a determinados eventos. Como o idle também só funciona para uma única caixa de , o servidor e o cliente configuram outra conexão TCP para cada consulta de caixa adicional. O NOTIFY [6], no entanto, coloca o cliente no comando. Ele estende o IDLE, deixando que o cliente determine as caixas de a partir das quais deseja receber mensagens. Isso torna o NOTIFY uma caixa de IDLE múltipla, ao mesmo tempo em que simplifica a comunicação. Cliente Servidor Explicação * OK IMAP4rev1 Service Ready Servidor recebe cliente a001 login mrc secret Client logs in Cliente faz o log a002 select inbox a001 OK LOGIN completed Servidor reconhece Cliente escolhe Inbox como pasta ativa * 18 EXISTS 18 mensagens encontradas * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) Flags definidas * 2 RECENT 2 mensagens urgentes (por exemplo, novo ) * OK [UNSEEN 17] Message 17 is the first unseen message a002 OK [READ WRITE] SELECT completed Mensagem 17 está como não lida; todas as mensagens antigas foram lidas Cliente pode ter feito alterações ao a003 fetch 12 full Cliente solicita informações sobre a mensagem 12 * 12 FETCH (FLAGS (\Seen) O foi lido INTERNALDATE 17 Jul :44: Entregue em 17 de julho de 1996 RFC822.SIZE 4286 ENVELOPE ( Wed, 17 Jul :23: (PDT) IMAP4rev1 WG mtg summary and minutes ((NIL NIL imap cac.washington.edu )) (( John Klensin NIL KLENSIN MIT.EDU )) NIL NIL Mais que 4KB Cabeçalho do Tabela 1 Quando um cliente se comunica com um servidor IMAP 4* (nota: *da Wikipedia alemã para IMAP) Data Assunto De Remetente Responder para Para CC Linux Magazine #102 Maio de

3 O cliente usa NOTIFY SET para especificar tanto as caixas de como o tipo de informação que deseja receber. O servidor, em seguida, envia um conjunto de atributos juntamente com a resposta FETCH para o cliente, que agora torna-se um observador passivo. O efeito NOTIFY continua até que o cliente envie um novo comando NOTIFY ou até que uma das entidades feche a conexão IMAP. Como alguns clientes móveis só desejam atualizações para mensagens que correspondem a um determinado padrão de busca, o NOTIFY RFC também define atributos adicionais para a opção UPDATE, que entra em vigor neste caso. Sincronizado: QRESYNC A extensão QRESYNC [7] ressincroniza rapidamente com uma caixa de do usuário. É uma extensão do comando CONDSTORE. Este, por sua vez, verifica a caixa de para as mudanças de estado que ocorrem quando um usuário está usando diferentes clientes de ou quando vários usuários compartilham uma caixa de . Se um usuário no cliente A altera o status de um para não lida, também queremos que o cliente B se dê conta disso; o cliente precisa vasculhar a caixa de novamente (ressincronização) para fazer isso. Embora o CONDSTORE identifique essas mudanças e resolva conflitos causados por acesso simultâneo de vários clientes, o Thunderbird e outros clientes de precisam enviar os comandos UID FETCH e SEARCH, neste caso. Em contraste, o QRESYNC permite um resync, incluindo o rastreamento de arquivos excluídos de uma só vez. A resposta VANISHED introduzida para isto (e substituindo EXPUNGED) descobre se o foi excluído de forma eficiente. Figura 2 Os conteúdos das caixas de podem ser baixados de forma direcionada, como mostrado aqui no Thunderbird, e também restaurados e buscados localmente, se necessário. O uso do comando SELECT no lado do cliente elimina a necessidade de conexões simultâneas para o servidor, que só existem para evitar resyncs. O QRESYNC beneficia especialmente os dispositivos móveis, porque eles muitas vezes têm de recuperar os dados com mais frequência por conta da fraca cobertura de rede. Não admira que esta extensão seja uma das extensões Lemonade mencionadas anteriormente. Para usar o QRESYNC, o servidor precisa retornar ENABLE [8] como um recurso. A extensão ENABLE permite que os clientes habilitem um recurso especial de forma explícita. No caso do QRESYNC, o RFC requer que os clientes tenham enviado previamente um alvo ENABLE QRESYNC para o servidor. No movimento: MOVE Antes do IETF emitir uma RFC útil [9] com duas declarações MOVE e UID MOVE, tornando possível mover mensagens de entre caixas de correio a única opção era combinar vários comandos independentes (COPY, STORE, e EX- PUNGE) para obter o mesmo efeito. Esta implementação foi considerada abaixo da ideal por várias razões: se a comunicação quebrar entre as três etapas, os processos move tornam-se estanques. Este efeito também confunde os usuários, pois os clientes continuam a mostrar as mensagens neste estado intermediário. Além disso, em caixas de compartilhadas, a terceira etapa pode mudar não apenas as mensagens selecionadas, mas também, inadvertidamente, as mensagens marcadas para exclusão por terceiros. O MOVE resolve estes problemas, enquanto o UID MOVE move mensagens em função de identificadores únicos. Para um cliente descobrir se um servidor suporta este recurso, o servidor 72

4 Extensões IMAP ANÁLISE precisa responder à requisição CAPABILITY com MOVE. Pesquisa rápida: ESEARCH O padrão IMAP já inclui duas funções de pesquisa na forma de SEARCH, que procura mensagens de com base em seus Message Sequence Numbers (MSNs) e UID SEARCH, que usa o identificador único. Uma desvantagem, no entanto, é que não se pode limitar o número de resultados retornados. O ESEARCH [10], por outro lado, oferece várias opções de resultado para o buscador. Assim, podemos limitar os resultados da pesquisa para um valor mínimo e máximo ou retornar apenas um certo número de resultados. Até mesmo encontrar todos os resultados é mais rápido, porque os resultados da pesquisa são retornados como um conjunto de sequência, que é compacto e economiza largura de banda. Além do mais, este conjunto pode ser usado em um comando subsequente. Novo: SORT e THREAD As próximas duas extensões, SORT e THREAD, compartilham uma RFC comum [11]. O SORT, surpreendentemente, não é uma parte fixa do protocolo IMAP. Representar o em tópicos não é realmente novo também, mas fundamentalmente apenas um algoritmo de ordenação. SORT e THREAD ocorrem no lado do servidor, economizando recursos do cliente (figura 2). Ambas as extensões têm de processar os termos a serem classificados de acordo com os requisitos do I18NLEVEL=1, que é parte de uma RFC [12] que regula a manipulação de conjuntos de caracteres internacionais. O servidor anuncia a capacidade de ordenação retornando SORT como resposta, e isso também produz o algoritmo de segmentação para o recurso THREAD. Uma resposta do servidor poderia ser THREAD=ORDEREDSUBJECT, que é o mais simples dos dois algoritmos de segmentação disponíveis que a RFC apresenta como the poor man s threading. O algoritmo primeiro ordena o por assunto e, em seguida, dada a mesma linha no assunto, por tipo de data de entrega, onde ORDEREDSUBJECT então converte essas mensagens em threads. Claro, isso pode causar problemas se alguém responder à thread mas alterar a linha do assunto. Neste caso, o algoritmo REFERENCES está gravado. É muito mais sofisticado que ORDEREDSUBJECT e precisa de seis etapas principais para criar uma thread (explicado em detalhes pela RFC 5256 [11] nas páginas 8-11). Mais acessível: UIDPLUS De acordo com a RFC, a UIDPLUS [13], parte da especificação Lemonade, é uma extensão que trata particularmente de clientes difíceis de alcançar. A extensão é projetada para reduzir tempo e consumo de recursos. Para isso, ela define um comando adicional: o UID EXPUNGE apaga mensagens que possuem o parâmetro \Delete definido e um identificador único (UID) que aparece na sequência do conjunto da caixa de selecionada. Ela se revela particularmente adequada quando um cliente que está apenas temporariamente conectado se ressincroniza com o servidor. Se a extensão UID EXPUNGE é usada em vez de EXPUNGE, o cliente não mais acidentalmente apaga mensagens de outros usuários que foram marcados para exclusão enquanto estava offline. Neste caso, o segundo critério não se aplica, pois os UIDs das mensagens excluídas não pertencem à caixa de . Este comportamento tornase relevante quando os usuários compartilham caixas de ou tanto para usuários de clientes móveis como fixos. Difícil: LIST- EXTENDED Tradicionalmente, os comandos LIST e LSUB mostram o conteúdo das caixas de . Mas novas extensões IMAP deram origem a uma necessidade de determinados tipos de listas. Como LIST e LSUB não são naturalmente extensíveis, os clientes foram obrigados a executar uma série de comandos cada vez mais longos para alcançar o efeito exigido pelas extensões. A extensão LIST-EXTENDED [14] resolve o problema modificando o comando LIST existente, de tal forma que já não requer quaisquer comandos especiais, mas pode ser Figura 2 Este servidor IMAP 4 revela suas capacidades indicando que, entre outras coisas, suporta o NAMESPACE, bem como o IDLE e o ID. Linux Magazine #102 Maio de

5 complementada com uma variedade de opções e padrões de busca. A nova sintaxe é descendentemente compatível e é usada somente se a primeira ou segunda palavra depois do comando inicia-se com um parênteses, ou se o comando LIST tiver mais de dois parâmetros. Caso contrário, o comando LIST tradicional serve como um fallback. Nomes reais: NAMESPACE Como o IMAP 4 não define um namespace padrão, duas convenções namespace genéricas surgiram: no modelo Personal Mailbox ( Caixa de pessoal ), o namespace padrão representa apenas as caixas de pessoais do usuário. Em contraste, o modelo Complete Hierarchy ( Hierarquia completa ) inclui todas as outras caixas de digitais que o usuário pode acessar além da sua própria caixa de . O problema com estes modelos relaciona-se com a sobrecarga de configuração a eles associados. O comando NAMESPACE [15] permite que os clientes descubram automaticamente os prefixos definidos pelo servidor para caixas de (figura 3), assim distinguidas entre caixas de pessoais, caixas de de outros usuários e pastas compartilhadas. Isso permite que os administradores atribuam caixas de públicas (por exemplo, listas de discussão), um prefixo público, para distinguir caixas de compartilhadas com o prefixo compartilhado, e para marcar as caixas de por u- suário como privadas. Isso não só economiza trabalho manual, mas as caixas de em um namespace podem, também, residir em diferentes locais na rede e usar diferentes formatos como, por exemplo, Maildir e Mbox. Tudo permitido: ACL Caixas de especificadas com NAMESPACE geralmente também possuem direitos de acesso diferentes. As Access Control Lists para caixas de e a extensão ACL [16] permitem que o administrador visualize e modifique os direitos usando comandos IMAP. A RFC associada, a partir de 1997, acabou sendo extinta; assim, a RFC 4314 [17] acompanhou a definição de novos direitos de acesso e adicionou clareza para a situação dos direitos. Além da string ACL, o servidor precisa usar RIGHTS = para indicar os direitos que ele suporta ao responder a CAPABILITY: atualmente 11 direitos padrão e dois direitos virtuais (d e c), que existem por razões de compatibilidade com a RFC Comandos possíveis em combinação com a RFC incluem: SETACL, GETACL, DELETEACL, LISTRIGHTS e MYRIGHTS. Entradas ACL consistem de dois componentes (identificador de acesso e direitos) e podem ser atribuídas a caixas de específicas. O identificador de acesso em geral é o nome de usuário (uma string UTF8) e também é aceito com LOG e AUTHENTICATE. No entanto, mais de um identificador pode existir para cada usuário. Além disso, arfc define um identificador a qualquer um, que faz referência a uma identidade genérica que inclui logins anônimos. Se o identificador é precedido por -, serão negados os direitos atribuídos ao usuário associado. Enquanto que as letras minúsculas mostram os direitos do u- suário, a RFC usa números para atribuições de direito no contexto de implementações do servidor: postmasters podem usá-los para atribuir ou negar certos direitos em todos os sentidos, garantindo assim, por exemplo, que os usuários só possam gerenciar caixas de próprias. n Mais informações [1] List of Imap extensions: [2] Lemonade RFC: tools.ietf.org/html/rfc4550 [3] CAPABILITY: tools.ietf.org/search/ rfc3501#section [4] ID: org/html/rfc2971 [5] IDLE: org/html/rfc2177 [6] NOTIFY: ietf.org/html/rfc5465 [7] QRESYNC: ietf.org/html/rfc5162 [8] ENABLE: ietf.org/html/rfc5161 [9] MOVE: ietf.org/html/rfc6851 [10] ESEARCH: ietf.org/html/rfc4731 [11] SORT and THREAD: org/html/rfc5256 [12] Internationalization: tools.ietf.org/html/rfc5255 [13] UIDPLUS: ietf.org/html/rfc4315 [14] LIST EXTENDED: tools.ietf.org/html/rfc5258 [15] NAMESPACE: tools.ietf.org/html/rfc2342 [16] ACL: ietf.org/html/rfc2086 Gostou do artigo? Queremos ouvir sua opinião. Fale conosco em: cartas@linuxmagazine.com.br Este artigo no nosso site: [17] ACL update: ietf.org/html/rfc