Je tente d’utiliser mon propre serveur d’envoi exclusif pour envoyer des e-mails. J’exécute cette passerelle SMTP pour utiliser TLS, ce qui signifie que le client que j’utilise pour envoyer des e-mails nécessite un certificat. J’utilise un certificat auto-signé qui est très facilement configurable si j’utilise postfix/ssmtp pour l’envoi d’e-mails, mais je ne suis pas sûr de savoir comment utiliser un certificat personnalisé dans le client de messagerie de Discourse.
Je souhaiterais corriger ma question. Je n’ai donc vraiment pas besoin d’ajouter de certificats pour que cela fonctionne, mais la communication en TLS échoue toujours. Si je le teste avec swaks, cela fonctionne parfaitement. Exemple de commande :
@itsbhanusharma AWS SES offre 60 000 e-mails par mois gratuitement et, à ma connaissance, ces appels d’e-mails doivent être effectués depuis une instance EC2 pour fonctionner, sinon ils sont facturés normalement. Mon instance Discourse est hébergée sur un droplet DigitalOcean. Je pourrais me tromper, mais c’est ainsi que je le comprends et c’est le raisonnement derrière cela.
Donc, même si votre API SES reçoit des e-mails depuis une adresse IP de DigitalOcean, cela entraînera des frais. Vous pourriez décider d’utiliser un autre service ou de déployer Exim sur une instance EC2 pour servir de passerelle entre votre instance DigitalOcean et AWS SES. Je ne pense pas que cela fonctionnera, mais vous pouvez essayer.
Cela devrait (en théorie, du moins) se dérouler ainsi :
Discourse (sur DO) envoie des e-mails à l’adresse IP d’Exim sur EC2.
J’ai déjà résolu le problème de relais en exécutant un serveur SMTP local sur EC2 qui transfère ensuite la requête SMTP vers SES. Le problème est que Discourse échoue lors de la poignée de main TLS avec ce serveur SMTP, alors que des applications comme Postfix et Swaks fonctionnent parfaitement.
Existe-t-il un moyen de voir où cette poignée de main SMTP est gérée ? Comme une bibliothèque que Discourse utilise en Ruby en arrière-plan ? Je ne souhaite pas désactiver TLS ici.
L’utilisation d’un certificat valide de Let’s Encrypt n’a pas fonctionné pour une raison inconnue. Je ne sais pas pourquoi.
Mais après avoir ajouté ceci dans app.yaml, les emails fonctionnent désormais.
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
Quelqu’un de plus compétent en SMTP pourrait expliquer pourquoi cela fonctionne, mais pour l’instant, je suis satisfait je pense.
J’ai une instance EC2 à 5 $ qui tourne sur AWS et que j’utilise pour relayer plusieurs domaines. Migrer Discourse vers EC2 coûterait un peu plus cher par rapport à DigitalOcean, pas vraiment beaucoup, honnêtement (quelques dollars au total).
Mais le point clé est que même si je déplace Discourse vers EC2, j’aurais toujours besoin de ce service de relais pour prendre en charge les autres droplets que j’ai sur DO pour les autres domaines que je possède. Alors pourquoi ne pas simplement corriger Discourse
C’est vrai, mais Discourse n’a rien à voir avec le SES ici. Discourse communique avec un serveur SMTP, qui peut être n’importe quoi (actuellement, c’est un service de relais). Je me demandais comment postfix, swaks et autres fonctionnent parfaitement avec ce serveur SMTP (du même VPC DO) alors que Discourse ne fonctionne pas. Après avoir défini cette variable, cela fonctionne cependant. Je voudrais toujours savoir quelle bibliothèque Discourse utilise pour la poignée de main SMTP afin que je puisse vérifier personnellement s’il y a quelque chose que nous pouvons améliorer dans Discourse.
