9. Respostas a algumas objecções

Há uma comum e mal explicada ideia que o IMAP implica computação centralizada. Isto normalmente é dito no contexto de que como os computadores pessoais são cada vez mais poderosos a computação central tornou-se irrelevante. Indiferentemente da política ou religião da pessoa no assunto de computação central, este assunto não tem nada que ver com IMAP. O IMAP pode ser usado com servidores pessoais, grupos de trabalho, departamentais, ou de grandes empresas. Uma vez tomada a decisão onde os dados das mensagem da pessoa ficarão, a pergunta pertinente é: "qual será o protocolo usado para ter acesso a elas usando outras máquinas?" E para a maioria das pessoas, haverá "outras" máquinas: uma fracção diminuta de utilizadores de computador passará a vida usar um único computador em todas as situações.

Foi dito que o POP é suficiente e o IMAP não vale a pena porque isto porque só acede remotamente a objectos de mensagem, e existem claramente outras classes de dados para qual se poderiam querer aceder remotamente. Certamente é verdade que o IMAP não é uma solução para o acesso remoto a todos os dados, por outro lado, não existe nada que faça prever que o mundo está convergindo para um protocolo único de acesso a ficheiros remotos . Nem o Sun NFS, Transarc AFS, OSF´s OFS, Apple AFP, SMB da Microsoft, nem o NCP da Novell são actualmente, nem é provável que se tornem, protocolos de acesso a ficheiros remotos universais e independentes da plataforma. Mesmo que um único protocolo satisfez-se esta necessidade, existem razões de desempenho para considerar protocolos de aplicação específicos. Também, é certo que os problemas da protecção de ficheiros que são inevitáveis num ambiente real de mensagens é frequentemente mais fácil resolver com um protocolo de aplicação específico. Uma das ironias do argumento " o POP é suficiente porque o IMAP não faz tudo" é que se um protocolo de acesso a ficheiros remotos, então o POP também não seria mais preciso.

Uma variante no mesmo tema é a hipótese que eventualmente toda a gente transporta consigo todos os seus ficheiros pessoais, de forma que acesso remoto para apenas por causa de uma única gota de correio é desnecessária. Enquanto que transportar copias de dados relevantes com a pessoa é claramente útil, quantas pessoas iriam escolher ter com eles os suas cópias primárias.

Alguns observaram que nenhum protocolo de aplicação de correio pode manter-se actualizado com as necessidades sempre crescentes dirigidas por programas cliente de correio crescentemente sofisticados. Eles discutem que definindo uma linguagem em qual escrever programas para serem executados no servidor de correio, é o único modo de fornecer generalidade suficiente para as alterações das necessidades dos clientes. Por outras palavras, qualquer protocolo fixo, até mesmo um com características de extensão negociadas como IMAP têm, estará llogo obsoleto. O contador-argumento é aquela abertura do servidor para executar qualquer programa que pode ser expressado na linguagem candidata é o pesadelo de um administrador de sistema, já que torna tudo mais difícil de manter um tempo de resposta consistente à medida que o numero de aplicações vão aumentando.

Uma recente tendência importante é o advento da World Wide Web, e com isto o Hypertext Transport Protocol (HTTP). Não se poderá o HTTP tornar obsoleto? Parece nos muito mais provável que os dois (HTML e IMAP) coexistirão com vantagem mutuas. Os desenhadores da Rede decidiram explorar sabiamente a tecnologia existente e incorpora-la na sintaxe do URL, fornecendo modos para exibição externa e acesso aos métodos. IMAP e HTTP podem coexistir e complementarem-se nesse contexto. E enquanto alguns trabalhos interessantes foram recentemente acabando permitindo browsers de WWW genérico ter acesso email por HTTP só, as aplicações específico primitivas de IMAP, ainda oferecem um desempenho significante e vantagens de funcionalidade em cima de uma abordagem HTTP pura.

Finalmente, alguém poderia perguntar: por que não ambos POP e IMAP? Realmente, esta estratégia foi adotada com sucesso por muitos sites para fornecendo as vantagens do IMAP e mantendo compatibilidade com os primeiros agentes clientes de correio. Não há nenhuma barreira técnica para fornecer ambos os protocolos em um servidor de correio, desde que ambos usem formatos de caixas de correio compatíveis e disciplinas de protecção de ficheiros. Porém, pode haver razões não técnicas para suportar apenas a um protocolo: existem vários programas clientes de correio que suportam um ou outro protocolo, mas não ambos. Se ambos os serviços estão disponíveis, o pessoal que presta serviços ao cliente (como habitualmente) da dá a conhecer a diversidade de serviços que oferecem.