Estou tentando usar meu próprio servidor de envio exclusivo para enviar e-mails. Estou executando este gateway SMTP para usar TLS, por isso o cliente que utilizo para enviar e-mails exige um certificado. Estou usando um certificado autoassinado, que é muito fácil de configurar se eu usar o postfix/ssmtp para enviar e-mails, mas não tenho certeza de como posso usar um certificado personalizado no cliente de e-mail do Discourse.
Gostaria de corrigir minha pergunta. Então, realmente não preciso adicionar nenhum certificado para que isso funcione, mas ainda assim está falhando na comunicação via TLS. Se eu estiver testando com o swaks, está funcionando perfeitamente. Exemplo de comando:
@itsbhanusharma O AWS SES oferece 60 mil e-mails gratuitos por mês e, até onde sei, essas chamadas de e-mail devem ser solicitadas a partir de uma instância EC2 para funcionar; caso contrário, são cobradas como envio normal. Minha instância do Discourse está hospedada em um droplet da Digital Ocean. Posso estar errado, mas essa é minha compreensão e o raciocínio por trás disso.
Então, mesmo que sua API do SES esteja recebendo e-mails de um IP do DigitalOcean, isso tornaria o serviço cobrável. Você pode decidir usar outro serviço ou configurar o Exim em uma instância EC2 para atuar como ponte entre seu Droplet do DO e o AWS SES. Não acho que funcione, mas você pode tentar.
Isso deveria (em teoria, pelo menos) funcionar assim:
O Discourse (no DO) envia e-mails para o IP do Exim na EC2
A EC2 encaminha os e-mails recebidos do DO para o SES
Já resolvi o problema de retransmissão executando um servidor SMTP local no EC2, que eventualmente encaminha a solicitação SMTP para o SES. O problema é que o Discourse está falhando no handshake TLS com esse servidor SMTP, enquanto o Postfix, o swaks e aplicativos similares estão funcionando perfeitamente.
Existe alguma maneira de ver onde essa negociação SMTP é tratada? Tipo alguma biblioteca que o Discourse usa em Ruby nos bastidores? Não quero desabilitar o TLS aqui.
Usar um certificado válido do Let’s Encrypt não ajudou por algum motivo. Não sei o porquê.
Mas depois de definir isso no app.yaml, os e-mails estão funcionando agora.
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
Alguém com mais conhecimento sobre SMTP pode explicar por que isso está funcionando, mas por enquanto estou bem, acho.
Tenho uma instância EC2 de $5 rodando na AWS, que estou usando para fazer o relay de vários domínios. Migrar o Discourse para a EC2 seria um pouco mais caro em comparação ao Digital Ocean, mas não muito, na verdade (alguns dólares no total).
Mas o ponto é que, mesmo que eu migre o Discourse para a EC2, ainda precisaria desse serviço de relay para dar suporte aos outros droplets que tenho no DO para os demais domínios que possuo. Então, por que não apenas corrigir o Discourse?
Isso é verdade, mas o Discourse não tem nada a ver com o SES aqui. O Discourse se comunica com um servidor SMTP, que pode ser qualquer coisa (no momento, é um serviço de retransmissão). Eu estava me perguntando como o Postfix, o Swaks e outros funcionam perfeitamente com esse servidor SMTP (da mesma VPC do DO) e o Discourse não. Após definir essa variável, ele está funcionando, no entanto. Ainda assim, gostaria de saber qual biblioteca o Discourse está usando para o handshake SMTP, para que eu possa verificar pessoalmente se há algo que possamos fazer para melhorar no Discourse.
