Há algum tempo venho trabalhando em um sistema que filtra emails.
Para tanto, precisei implementar uma solução que se conecte ao servidor de email e permaneça ?ouvindo? esta conexão, para que, quando um novo email seja recebido, o processo seja disparado.
Acontece que, primeiramente, optei pelo protocolo POP3.
Então surgiram os problemas.
O POP3 não implementa um recurso como flag para novos emails e, o pior, enquanto o folder POP3 está aberto, nenhuma alteração pode ser verificada (emails recebidos, lidos, excluídos).
Ok, vamos tentar com IMAP.
Bom, imap resolveu o problema.
Consigo conectar, criei um messagecountlistener e, quando um email chega, o ?proxy? é disparado, analisa o remetente e o domínio de onde a mensagem partiu e realiza o que deve fazer.
Até aí tudo bem.
A questão que me deixa encasquetado é, se POP3 não permite que uma alteração seja apontada enquanto o folder está aberto, como mail clients como o thunderbird e o outlook conseguem receber emails ?real time? conectados através deste protocolo?
Alguém aí tem esse conhecimento? Sabe como isso é possível?
Isso, com certeza, não seria a forma mais inteligente.
Mesmo por que, eu cheguei a implementar, como solução alternativa, caso o imap torne-se indisponível, algo assim.
O problema é que, POP3 não aceita “flagar” como READ, por exemplo, quem dirá DELETED, e, tanto no thunder quanto no outlook é possível baixar o email e deletar do servidor…
Isso, com certeza, não seria a forma mais inteligente.[/quote]
Mas é assim mesmo que ele funciona. Dá pra perceber isso quando se utiliza clients de email comuns, de tempo em tempo ele fica “Procurando novas mensagens no servidor”. Quando chega um email na caixa, só é baixado na próxima atualização, ou clicando no “Enviar/Receber” para verificar na hora.
O motivo de não poder “escutar” ou marcar as mensagens é que originalmente o protocolo foi pensado de forma bem simples, o client conecta, recebe as mensagens, elas são apagadas do servidor automaticamente. Só isso, daí pra frente o client faz o que quiser com os emails.
Recentemente é que os serviços POP passaram a ser configurados para não remover as mensagens, mas ele continua sem os recursos do IMAP, feito especialmente para que as mensagens permaneçam no servidor.
drsmachado, também fiz um client de e-mail e tive de implementar da mesma forma que você.
Na época, realizei pesquisas e não encontrei outra solução viável.
Eu usava Camel para isso, mas como não suportou tudo o que eu quis (ou eu não soube configurar), acabei tendo de implementar no braço mesmo. E como já disseram, acredito que essa seja realmente a implementação padrão.
Pelo que me parece, é a forma mais usual, porém, ainda penso ser algo meio ‘noob’. Pense, seria o mesmo que um telefone celular ter que requisitar para a operadora se existe ligação sendo recebida… Lógica totalmente inversa…
Pois é. Talvez as “nativas” usem de outra solução. Exemplo. Servidor gmail. Todos que possuem e-mail deles e acessam via aplicativo criado por eles, talvez seja registrado no servidor deles ou algo do tipo, para que o servidor possa ter conhecimento dos seus “ouvinte” e disparar uma mensagem de aviso.
Não conheço a fundo, bem superficialmente isso. Mas como comentei, as pesquisas que realizei demonstraram que essa era a forma comum de se desenvolver, mesmo não sendo a mais adequada, talvez. Mas você chegou a pensar em outro formato machado ? Algo como envio de um multicast por parte do servidor aos que se cadastrem nele?
Fiz alguns testes utilizando um cliente de e-mail POP3 que desenvolvi em Java, utilizando a API Javamail, e percebi que cada servidor e aplicação “nativa” do servidor reage de maneiras diferentes. Exemplos:
Gmail: Aplicação lê as mensagens. Mensagem continua no cliente app “nativo” do Gmail. Mensagem excluída do servidor Gmail.
Hotmail: Aplicação lê as mensagens. Mensagem continua no cliente app “nativo” do Hotmail. Mensagem NÃO excluída do Servidor Hotmail.
Bol: Aplicação lê as mensagens. Mensagem é apagada do cliente app “nativo” do Bol. Mensagem excluída do Servidor Bol.
IG: Aplicação lê as mensagens. Mensagem continua no cliente app “nativo” do IG> Mensagem excluída do Servidor IG.
Os testes mostraram que cada servidor e cliente app “nativo” processa de uma forma.
Outro Exemplo: Se eu tentar ler denovo com minha aplicação cliente o servidor Gmail, as mensagens lidas anteriormente não seram mais encontradas, porém estas mensagens ficam no cliente app dos caras.
Tenho uma pergunta pros amigos do GUJ.
Como, por exemplo, como o Outlook faz para deixar essas mensagens no Servidor sem apagar, utilizando POP3? :shock:
Nunca configurei o Gmail no Outlook, mas já ouvi dizer que as mensagens não são apagadas do Servidor.
Alguém tem alguma idéia de como isso é feito? Falta só isso pra que minha aplicação seja entregue no trabalho. Mas não tenho em mente como fazer isso. Isso é possível em Java?
Telefones tinham requisitos totalmente diferentes na época que foram concebidos. O sistema de push e-mail é muito mais recente. O padrão para e-mails é sistema de pull mesmo.
O problema de sistema de push é o que servidor tem que manter um cadastro de onde entregar o e-mail, assim como o sistema de telefonia móvel precisa saber a tua localização para saber para que antena/base mandar o chamado. Isso é bem mais caro e complicado de fazer que um sistema de pull/pooling.
