Internet Message Access Protocol - Internet Message Access Protocol

Na computação, o Internet Message Access Protocol ( IMAP ) é um protocolo padrão da Internet usado por clientes de e-mail para recuperar mensagens de e-mail de um servidor de e - mail por meio de uma conexão TCP / IP . IMAP é definido pelo RFC 9051 .  

O IMAP foi projetado com o objetivo de permitir o gerenciamento completo de uma caixa de e - mail por vários clientes de e-mail, portanto, os clientes geralmente deixam mensagens no servidor até que o usuário as exclua explicitamente. Um servidor IMAP geralmente escuta na porta número 143. IMAP sobre SSL / TLS ( IMAPS ) é atribuído ao número de porta 993.

Praticamente todos os clientes e servidores de e-mail modernos suportam IMAP, que junto com o POP3 (Post Office Protocol) anterior são os dois protocolos padrão mais prevalentes para recuperação de e-mail. Muitos provedores de serviço de webmail , como Gmail e Outlook.com, também oferecem suporte para IMAP e POP3.

Protocolos de e-mail

O Internet Message Access Protocol é um protocolo da camada de aplicativo da Internet que permite que um cliente de e-mail acesse o e - mail em um servidor de e-mail remoto . A versão atual é definida pelo RFC  3501 . Um servidor IMAP normalmente escuta na porta bem conhecida 143, enquanto IMAP sobre SSL / TLS (IMAPS) usa 993.

As mensagens de e-mail recebidas são enviadas para um servidor de e-mail que armazena as mensagens na caixa de e-mail do destinatário. O usuário recupera as mensagens com um cliente de e-mail que usa um de vários protocolos de recuperação de e-mail. Embora alguns clientes e servidores usem preferencialmente protocolos proprietários específicos do fornecedor , quase todos suportam POP e IMAP para recuperação de e-mail - permitindo a escolha livre entre muitos clientes de e-mail como Pegasus Mail ou Mozilla Thunderbird para acessar esses servidores e permite que os clientes para ser usado com outros servidores .

Os clientes de e-mail que usam IMAP geralmente deixam mensagens no servidor até que o usuário as exclua explicitamente. Esta e outras características da operação IMAP permitem que vários clientes gerenciem a mesma caixa de correio. A maioria dos clientes de e-mail oferece suporte a IMAP além do Post Office Protocol (POP) para recuperar mensagens. IMAP oferece acesso ao armazenamento de correio. Os clientes podem armazenar cópias locais das mensagens, mas são consideradas um cache temporário.

História

O IMAP foi projetado por Mark Crispin em 1986 como um protocolo de caixa de correio de acesso remoto, em contraste com o POP amplamente usado, um protocolo para simplesmente recuperar o conteúdo de uma caixa de correio.

Ele passou por uma série de iterações antes da atual VERSÃO 4rev1 (IMAP4), conforme detalhado a seguir:

IMAP original

O protocolo de acesso temporário original foi implementado como um cliente da máquina Xerox Lisp e um servidor TOPS-20 .

Não existem cópias da especificação do protocolo provisório original ou de seu software. Embora alguns de seus comandos e respostas fossem semelhantes ao IMAP2, o protocolo provisório não tinha marcação de comando / resposta e, portanto, sua sintaxe era incompatível com todas as outras versões do IMAP.

IMAP2

O protocolo provisório foi rapidamente substituído pelo Interactive Mail Access Protocol (IMAP2), definido na RFC  1064 (em 1988) e posteriormente atualizado pela RFC  1176 (em 1990). IMAP2 introduziu a marcação de comando / resposta e foi a primeira versão distribuída publicamente.

IMAP3

IMAP3 é uma variante extremamente rara do IMAP. Foi publicado como RFC  1203 em 1991. Foi escrito especificamente como uma contraproposta ao RFC  1176 , que propunha modificações ao IMAP2. IMAP3 nunca foi aceito pelo mercado. O IESG reclassificou o RFC1203 "Interactive Mail Access Protocol - Versão 3" como um protocolo histórico em 1993. O IMAP Working Group usou o RFC 1176 (IMAP2) em vez do RFC 1203 (IMAP3) como ponto de partida.

IMAP2bis

Com o advento do MIME , o IMAP2 foi estendido para oferecer suporte a estruturas corporais MIME e adicionar funcionalidade de gerenciamento de caixa de correio (criar, excluir, renomear, upload de mensagem) que estava ausente do IMAP2. Esta revisão experimental foi denominada IMAP2bis; sua especificação nunca foi publicada em forma de rascunho. Um rascunho do IMAP2bis na Internet foi publicado pelo Grupo de Trabalho IETF IMAP em outubro de 1993. Esse rascunho foi baseado nas seguintes especificações anteriores: documento IMAP2bis.TXT não publicado , RFC  1176 e RFC  1064 (IMAP2). O rascunho IMAP2bis.TXT documentou o estado das extensões para IMAP2 em dezembro de 1992. As primeiras versões do Pine foram amplamente distribuídas com suporte para IMAP2bis (Pine 4.00 e posterior oferece suporte para IMAP4rev1).

IMAP4

Um grupo de trabalho IMAP formado na IETF no início de 1990 assumiu a responsabilidade pelo design do IMAP2bis. O IMAP WG decidiu renomear IMAP2bis para IMAP4 para evitar confusão.

Vantagens sobre POP

Modos conectado e desconectado

Ao usar o POP, os clientes geralmente se conectam ao servidor de e-mail brevemente, apenas o tempo necessário para baixar novas mensagens. Ao usar o IMAP4, os clientes geralmente permanecem conectados enquanto a interface do usuário estiver ativa e baixam o conteúdo da mensagem sob demanda. Para usuários com muitas ou grandes mensagens, esse padrão de uso de IMAP4 pode resultar em tempos de resposta mais rápidos.

Múltiplos clientes simultâneos

O protocolo POP requer que o cliente atualmente conectado seja o único cliente conectado à caixa de correio. Em contraste, o protocolo IMAP permite especificamente o acesso simultâneo por vários clientes e fornece mecanismos para que os clientes detectem as alterações feitas na caixa de correio por outros clientes conectados simultaneamente. Consulte, por exemplo, RFC  3501, seção 5.2, que cita especificamente "acesso simultâneo à mesma caixa de correio por vários agentes" como exemplo.

Acesso a partes da mensagem MIME e busca parcial

Normalmente, todo e-mail da Internet é transmitido em formato MIME , permitindo que as mensagens tenham uma estrutura de árvore em que os nós folha são qualquer um de uma variedade de tipos de conteúdo de parte única e os nós não folha são qualquer um de uma variedade de tipos de várias partes. O protocolo IMAP4 permite que os clientes recuperem qualquer uma das partes individuais do MIME separadamente e também recuperem partes das partes individuais ou da mensagem inteira. Esses mecanismos permitem que os clientes recuperem a parte do texto de uma mensagem sem recuperar os arquivos anexados ou transmitam o conteúdo à medida que ele é buscado.

Informação do estado da mensagem

Por meio do uso de sinalizadores definidos no protocolo IMAP4, os clientes podem acompanhar o estado da mensagem: por exemplo, se a mensagem foi lida, respondida ou excluída ou não. Esses sinalizadores são armazenados no servidor, de forma que diferentes clientes que acessam a mesma caixa de correio em momentos diferentes possam detectar alterações de estado feitas por outros clientes. O POP não fornece nenhum mecanismo para que os clientes armazenem essas informações de estado no servidor, portanto, se um único usuário acessar uma caixa de correio com dois clientes POP diferentes (em momentos diferentes), as informações de estado - como se uma mensagem foi acessada - não podem ser sincronizadas entre os clientes. O protocolo IMAP4 suporta sinalizadores de sistema predefinidos e palavras-chave definidas pelo cliente. Sinalizadores de sistema indicam informações de estado, como se uma mensagem foi lida. Palavras-chave, que não são suportadas por todos os servidores IMAP, permitem que as mensagens recebam uma ou mais tags cujo significado depende do cliente. As palavras-chave IMAP não devem ser confundidas com rótulos proprietários de serviços de e-mail baseados na web , que às vezes são traduzidos em pastas IMAP pelos servidores proprietários correspondentes.

Várias caixas de correio no servidor

Os clientes IMAP4 podem criar, renomear e / ou excluir caixas de correio (geralmente apresentadas ao usuário como pastas) no servidor e copiar mensagens entre as caixas de correio. O suporte a várias caixas de correio também permite que os servidores forneçam acesso a pastas públicas e compartilhadas. A extensão da lista de controle de acesso (ACL) IMAP4 ( RFC  4314 ) pode ser usada para regular os direitos de acesso.

Pesquisas do lado do servidor

O IMAP4 fornece um mecanismo para um cliente solicitar ao servidor que procure mensagens que atendam a uma variedade de critérios. Esse mecanismo evita exigir que os clientes baixem todas as mensagens da caixa de correio para realizar essas pesquisas.

Mecanismo de extensão embutido

Refletindo a experiência de protocolos anteriores da Internet, o IMAP4 define um mecanismo explícito pelo qual pode ser estendido. Muitas extensões IMAP4 para o protocolo de base foram propostas e são de uso comum. O IMAP2bis não tinha um mecanismo de extensão e o POP agora tem um definido pela RFC  2449 .

Desvantagens

Embora o IMAP corrija muitas das deficiências do POP, isso inerentemente apresenta uma complexidade adicional. Grande parte dessa complexidade (por exemplo, vários clientes acessando a mesma caixa de correio ao mesmo tempo) é compensada por soluções alternativas do lado do servidor , como Maildir ou back-ends de banco de dados.

A especificação IMAP foi criticada por ser insuficientemente rígida e permitir comportamentos que efetivamente negam sua utilidade. Por exemplo, a especificação afirma que cada mensagem armazenada no servidor possui um "id único" para permitir que os clientes identifiquem as mensagens que já viram entre as sessões. No entanto, a especificação também permite que esses UIDs sejam invalidados sem restrições, praticamente frustrando seu propósito.

A menos que o armazenamento de correio e os algoritmos de pesquisa no servidor sejam implementados com cuidado, um cliente pode potencialmente consumir grandes quantidades de recursos do servidor ao pesquisar caixas de correio enormes.

Os clientes IMAP4 precisam manter uma conexão TCP / IP com o servidor IMAP para serem notificados da chegada de um novo e-mail. A notificação de chegada de e-mail é feita por meio de sinalização in-band , o que contribui um pouco para a complexidade do tratamento do protocolo IMAP do lado do cliente. Uma proposta privada, push IMAP , estenderia o IMAP para implementar push e-mail enviando a mensagem inteira em vez de apenas uma notificação. No entanto, o push IMAP não foi geralmente aceito e o trabalho atual da IETF abordou o problema de outras maneiras (consulte o Perfil de limonada para obter mais informações).

Ao contrário de alguns protocolos proprietários que combinam operações de envio e recuperação, enviar uma mensagem e salvar uma cópia em uma pasta do lado do servidor com um cliente IMAP de nível básico requer a transmissão do conteúdo da mensagem duas vezes, uma para SMTP para entrega e uma segunda vez para IMAP para armazenar em uma pasta de correio enviado. Isso é abordado por um conjunto de extensões definidas pelo Perfil Limonada da IETF para dispositivos móveis: URLAUTH ( RFC  4467 ) e CATENATE ( RFC  4469 ) em IMAP e BURL ( RFC  4468 ) em SMTP-SUBMISSION. Além disso, o Courier Mail Server oferece um método não padrão de envio usando IMAP, copiando uma mensagem de saída para uma pasta de caixa de saída dedicada.

Segurança

Para proteger criptograficamente as conexões IMAP, pode-se usar IMAPS na porta TCP 993, que utiliza SSL / TLS. Desde janeiro de 2018, o TLS é o mecanismo recomendado.

Alternativamente, STARTTLS pode ser usado para fornecer comunicações seguras entre o MUA que se comunica com o MSA ou MTA que implementa o protocolo SMTP .

Exemplo de diálogo

Este é um exemplo de conexão IMAP, retirado do RFC 3501 seção 8 :

C: <open connection>
S:   * OK IMAP4rev1 Service Ready
C:   a001 login mrc secret
S:   a001 OK LOGIN completed
C:   a002 select inbox
S:   * 18 EXISTS
S:   * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S:   * 2 RECENT
S:   * OK [UNSEEN 17] Message 17 is the first unseen message
S:   * OK [UIDVALIDITY 3857529045] UIDs valid
S:   a002 OK [READ-WRITE] SELECT completed
C:   a003 fetch 12 full
S:   * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
      RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
      "IMAP4rev1 WG mtg summary and minutes"
      (("Terry Gray" NIL "gray" "cac.washington.edu"))
      (("Terry Gray" NIL "gray" "cac.washington.edu"))
      (("Terry Gray" NIL "gray" "cac.washington.edu"))
      ((NIL NIL "imap" "cac.washington.edu"))
      ((NIL NIL "minutes" "CNRI.Reston.VA.US")
      ("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
      "<B27397-0100000@cac.washington.edu>")
      BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
      92))
S:   a003 OK FETCH completed
C:   a004 fetch 12 body[header]
S:   * 12 FETCH (BODY[HEADER] {342}
S:   Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S:   From: Terry Gray <gray@cac.washington.edu>
S:   Subject: IMAP4rev1 WG mtg summary and minutes
S:   To: imap@cac.washington.edu
S:   cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
S:   Message-Id: <B27397-0100000@cac.washington.edu>
S:   MIME-Version: 1.0
S:   Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S:   )
S:   a004 OK FETCH completed
C    a005 store 12 +flags \deleted
S:   * 12 FETCH (FLAGS (\Seen \Deleted))
S:   a005 OK +FLAGS completed
C:   a006 logout
S:   * BYE IMAP4rev1 server terminating connection
S:   a006 OK LOGOUT completed

Veja também

Referências

Leitura adicional

links externos