Mas também há alguns problemas com o Elastic Email: Add IsTransactional:true to SMTP Mail Headers to satisfy ElasticEmail - #8 by pfaffman
Jay, obrigado por trazer isso à tona. Deixe-me entender melhor:
O que você está chamando a atenção é: quando as pessoas recebem e-mails da Elastic Email, elas recebem um link muito visível e podem cancelar a assinatura unilateralmente, sem que o Discourse fique sabendo? Você, como SA, ficará no escuro?
Não tenho experiência de primeira mão.
Parece que eles inserem um link de cancelamento de inscrição e que é necessário um cabeçalho especial para fazê-lo desaparecer. Não sei se há uma maneira de usar o Elastic Email com um webhook para notificar o Discourse sobre cancelamentos de inscrição, mas eles não estão listados em Configure VERP to handle bouncing e-mails.
Acho que, se você conseguir fazer o AWS funcionar, provavelmente será a melhor solução, mas não é uma boa opção para quem vem aqui aprender a configurar o envio de e-mails.
O Mailgun é realmente fácil.
Obrigado.
Isso é meio irrelevante para mim, e vou explicar o porquê: a SparkPost fez exatamente a mesma coisa — embora, admito, eu nunca tenha verificado se havia algum hook que eu pudesse ter usado (estúpido de minha parte, pois existem e estamos em 2019 FGS).
Nesse caso, só descobri porque o site afetado atende minha comunidade local, então acabei conversando com o cara que, sem querer, clicou no link de cancelamento de assinatura no e-mail enviado pela SparkPost e estava reclamando de não receber nenhum e-mail de redefinição de senha. A SparkPost possui um registro de auditoria para isso e permite que administradores re-subscribam alguém (obviamente, use essa funcionalidade com moderação!), então, assim que soube do problema, foi fácil resolver. Da próxima vez, saberei configurar meu e-mail melhor.
No entanto, você está me inclinando cada vez mais para o Mailgun, obrigado!
Eu gostaria que existisse uma maneira mais “genérica” de o Discourse lidar com webhooks de e-mails com bounce. Nosso provedor preferido (Postmark) também não está na lista, o que significa que continuamos enviando e-mails para pessoas cujo endereço teve bounce.
Uma espécie de parser mágico e genérico de webhooks JSON de entrada para webhooks de e-mails com bounce seria incrível!
O que você quer dizer é que algum “padrão mágico para webhooks JSON” seria incrível. Como as coisas estão, cada serviço de e-mail cria o seu próprio, então é necessário um analisador de webhook separado. Criar um plugin que fizesse isso não seria tão difícil e provavelmente poderia ser encontrado no Marketplace (e talvez ser aceito como um PR) por algo na ordem de $500.
Sim, eu estava apenas pensando que, assumindo que +90% dos dados de bounce recebidos estejam em JSON ou em algum outro formato passível de regex, talvez seja possível indicar, por meio de uma configuração, o “campo” JSON que representa o e-mail de bounce e, possivelmente, outro campo que represente o tipo de bounce (hard, soft, etc.).
Isso poderia ser listado como um “analisador regex genérico para webhook de e-mail de bounce recebido”. O nome sai fácil da língua 
Isso poderia ajudar com a constante rotatividade que provavelmente continuaremos a ver para esse tipo específico de serviço.
Somos um site de intranet corporativa de volume bastante baixo, então provavelmente vamos apenas conviver com isso por enquanto.
Em outro tópico, você também pode fazer o link de cancelamento de assinatura extra do ElasticMail desaparecer informando a eles onde está o do Discourse: anotando-o especificamente como {unsubscribe:{https://.....}} (recomendo confirmar com o suporte antes de enviar um pull request).
Isso provavelmente poderia ser feito editando as traduções?
Eu também usava o SparkPost para minhas instâncias do Discourse e recentemente recebi esta notificação deles.
Então, comecei a procurar uma alternativa.
Configurei o SendGrid e, até agora, parece estar funcionando bem. Estou usando o plano Basic por 15$/mês.