Existem várias soluções possíveis para esse problema, e todas são bastante complexas. Esta é a configuração mais transparente que eu poderia imaginar, mas honestamente eu mudaria os hosts se o serviço SMTP não fosse confiável. Há muitos fornecedores bons e baratos de serviços de correio. Além disso, considere o uso do IMAP em vez do POP3, pois isso aliviará os problemas com a sincronização que provavelmente surgirão dessa configuração.
A solução é complicada devido ao acoplamento necessário entre um agente de transferência de email (MTA) e um agente de entrega de email (MDA). Para que um e-mail exista no servidor POP3 (o MDA), ele deve ter sido entregue por meio do servidor SMTP não confiável (o MTA). Seu MTA não pode armazenar mensagens no MDA remoto, e o MTA remoto não pode enviar mensagens para o seu MDA. Sem a sincronização completa das mensagens em ambas as direções, o e-mail interno da empresa (a parte "envio entre endereços de e-mail em nosso domínio") enviado do escritório só será armazenado no MDA local. Isso significa que os usuários que trabalham fora do escritório não receberão e-mails internos ao verificar a conta POP3 hospedada.
Você precisará no mínimo:
- MTA para SMTP - Courier é o padrão para o CentOS e uma boa escolha
- Firewall (para redirecionamento de IP / porta) - o netfilter ou rinetd funcionará
- MDA e proxy para contas POP3 / IMAP - Perdição provavelmente é o melhor, o Courier tem essa funcionalidade
MTA local para SMTP de backup
Adicione o servidor SMTP do seu host de e-mail (o MTA remoto) em /etc/courier/esmtproutes (ou onde quer que o arquivo seja instalado no CentOS) para fazer com que o Courier encaminhe todas as mensagens para ele. Quando o SMTP do seu host estiver inativo, o MTA local enfileirará o email de saída e tentará novamente a entrega para o MTA remoto em um intervalo configurável.
Redirecionamento de portas
Configure seu firewall para encaminhar todo o tráfego de saída na porta 25 para o seu MTA local.
Você pode implementar apenas o acima para a configuração mais simples. Ele não permitiria que o email interno continuasse normalmente, mas tornaria o tempo de inatividade do MTA remoto menos perceptível
MTA local com domínio hospedado
Adicione o domínio da sua empresa como um domínio hospedado para o Courier (o MTA local) em /etc/courier/hosteddomains . Isso substituirá o smarthost e entregará mensagens de acordo com as regras de roteamento configuradas. Veja makehosteddomains e Módulos de transporte para mais informações.
MDA e proxy locais Isso pode ser implementado de várias maneiras, mas por exemplo:
- Mantenha uma cópia local das credenciais da conta de e-mail e use-as para autenticar os usuários no MDA local, que poderia, por padrão, entregar em uma pasta "Local" para cada conta de usuário
- Use courier-authlib / authpipe ou Perdition para retransmitir essas credenciais para o MDA remoto ao mesmo tempo, incluindo o restante das pastas
- Configure um cron job para tentar enviar novas mensagens na pasta "Local" para o MTA remoto quando o serviço SMTP estiver ativo
... ou implemente o DNS interno e:
- Alterar as preferências do MX no domínio da empresa, roteando tudo para os dois MTAs (tecnicamente, seria necessário dois MTAs internos)
ou
- Basta usar um nome de domínio diferente (até mesmo falso) para e-mails internos e implementá-lo como um sistema de failover