Estou pensando na arquitetura de um sistema que deve lidar com os e-mails recebidos e passá-los para um aplicativo Rails que processa os e-mails recebidos. Não tenho certeza de qual é a melhor maneira de fazer algo assim.
Deve funcionar assim:
- Os e-mails são enviados para algo como contact@user_id.myapp.com
- O servidor de correio aceita os e-mails e os repassa para o aplicativo Rails (ou os armazena e o aplicativo Rails os busca)
- O aplicativo Rails processa os e-mails (alguns analisam e os jogam no banco de dados)
Deve funcionar basicamente como um queque. Picos repentinos no tráfego de e-mail não devem matar o aplicativo Rails.
Não estou procurando uma solução completa. Estou apenas interessado na sua opinião. Eu imaginei três opções possíveis:
- Rails se conecta via Pop3 ao servidor de email e apenas baixa as mensagens (provavelmente lento)
- O servidor de e-mail canaliza os e-mails com uma solicitação POST para o aplicativo Rails (provavelmente também muito lento, pode matar o servidor da web ao encontrar uma bomba de correio)
- O maildir está virtualmente vinculado ao sistema de arquivos do servidor de aplicativos Rails (o servidor de email e o servidor de aplicativos devem ser separados) e o Rails apenas lê diretamente dele.
Qual você acha que é a melhor abordagem em termos de desempenho e segurança? Estou faltando alguma coisa aqui? Existe uma maneira melhor? Você conhece alguns recursos de práticas recomendadas?
Obrigado!
Responder1
Aqui está uma postagem que pode ajudar:
Recebendo Emails e Anexos com Rails
O artigo também contém links para postagens anteriores sobre como configurar o RailsCron.
Responder2
Já vi aplicativos fazerem isso com POP3 (Spiceworks é um exemplo em que consigo pensar). Acho que é uma maneira decente de separar o aplicativo. servidor de e-mail do servidor de e-mail e permite que o servidor de e-mail se concentre no que ele faz bem e libera o cliente das tarefas de enfileiramento/armazenamento das mensagens.
ref: Segurança
Um problema com o POP3 que vem à mente é o uso padrão de credenciais de texto não criptografado. Se você puder executá-lo em SSL (dependente do servidor de e-mail), poderá mitigar essa preocupação.
re: Desempenho e dimensionamento
Não tenho tanta certeza de que o acesso POP3 será tão lento. Eu ficaria cauteloso ao fazer a integração no nível do sistema de arquivos, porque você pode ter problemas de contenção e bloqueio (ugh - pense em montar maildirs sobre NFS como um exemplo de problemas divertidos de contenção do sistema de arquivos) conforme novos e-mails chegam. um bom método para acessar atomicamente itens na caixa de correio.
Ter vários consumidores em execução na mesma caixa de correio POP3 ao mesmo tempo provavelmente seria problemático (se você estiver tentando expandir para lidar com mais tráfego de mensagens). Para isso, você pode querer criar um script no lado do servidor de correio para distribuir round-robin as mensagens recebidas em um grupo de caixas de correio e vincular cada consumidor a uma determinada caixa de correio. (Você pode considerar usar o IMAP para uma arquitetura de múltiplos consumidores, mas isso sou apenas eu soprando fumaça sem pensar bem.)
Você está adicionando mais camadas e possíveis gargalos, certamente, do que apenas aceitar SMTP diretamente em seu código, mas está aproveitando todo o trabalho que os autores do servidor de e-mail já fizeram. Prefiro ter um problema de dimensionamento em um servidor de e-mail do que um problema de dimensionamento no código do servidor SMTP personalizado.
Responder3
Rails é provavelmente a ferramenta errada para o trabalho. Você provavelmente gostaria de escrever um pequeno script que aceitasse o email no stdin e o inserisse em seu banco de dados. Você pode usar o mesmo código ActiveRecord para fazer isso. Então você só precisa configurar seu MTA para entregar o e-mail canalizando-o para o seu script.
Se precisar de um pouco mais de desempenho, você pode reescrever seu script para ser um daemon que aceita email via LTMP, o que evitará a ineficiência de iniciar um processo para cada email.
Responder4
Em vez de POP (se você seguir esse caminho), use IMAP(S). Dessa forma, você pode deixar as coisas no servidor "lidas" depois de executadas.