J’ai des difficultés à passer de SendGrid à Amazon SES.
Pourriez-vous partager gentiment vos paramètres depuis app.yml ou confirmer que les miens sont corrects ?
## TODO: Le serveur de messagerie SMTP utilisé pour valider les nouveaux comptes et envoyer des notifications
DISCOURSE_SMTP_ADDRESS: email-smtp.eu-west-2.amazonaws.com
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: xxxxxxx
DISCOURSE_SMTP_PASSWORD: "xxxxxxxxxx"
DISCOURSE_SMTP_ENABLE_START_TLS: true # (facultatif, par défaut true)
DISCOURSE_SMTP_AUTHENTICATION: login
Le paramètre d’authentification est-il correct ici ?
Le domaine est vérifié sur SES, vous n’avez pas besoin du paramètre d’authentification SMTP.
De plus, vous devrez peut-être sortir votre compte SES du mode bac à sable si ce n’est pas déjà fait et demander une augmentation de la limite. La condition de bac à sable s’applique par région.
Je suis toujours sans réponse quant à l’absence d’envoi d’e-mails via AWS SES.
Lorsque j’envoie un e-mail de test via la page d’administration de notre Discourse, il indique simplement « envoyé ». Une tentative de demande de réinitialisation de mot de passe suit également la procédure correctement, mais aucun e-mail n’arrive jamais.
Je ne pense pas que SES conserve des journaux, je ne peux donc pas vérifier s’il reçoit bien les e-mails.
La seule chose qui pourrait poser problème est que notre adresse de réponse utilise un compte gmail.com, et non notre domaine de site.
Quelqu’un a-t-il déjà rencontré cette combinaison ou ce scénario ?
C’est l’adresse e-mail qui apparaîtra dans la ligne « De ». Elle doit être une adresse du domaine depuis lequel SES enverra les e-mails. SES n’envoie pas de courriels qui prétendent provenir de Gmail. Vous n’avez pas le contrôle sur gmail.com, donc SES n’envoiera pas de courriels avec cela dans la ligne « De ». notification_email doit être quelquechose@votre_domaine_vérifié.
Est-ce que vous voulez dire que ce que j’essaie de faire n’est tout simplement pas possible dans SES à cause de l’adresse de réponse qui se trouve sur le domaine gmail.com ?
L’e-mail de notification est ce qui figure dans la ligne « De », et oui, je suis assez certain que c’est là votre problème. Avez-vous essayé de le modifier ?
J’utilise également SES et cela fonctionne bien pour moi. La seule différence que je vois par rapport à la vôtre est que la ligne DISCOURSE_SMTP_AUTHENTICATION: login n’existe pas dans ma configuration. De plus, DISCOURSE_SMTP_ENABLE_START_TLS: true et DISCOURSE_SMTP_PORT: 587 sont tous deux commentés, bien que cela ne devrait pas faire de différence.
Les seules 3 lignes que je modifie dans app.yml sont l’adresse SMTP, le nom d’utilisateur et le mot de passe. Le reste est commenté tel quel depuis une installation fraîche, en utilisant les valeurs par défaut. Après une reconstruction, je dois simplement m’assurer que le paramètre du site notification email est défini sur une adresse utilisant un domaine vérifié dans SES. Je n’utilise plus de guillemets pour le mot de passe, mais mes anciennes installations le faisaient et cela fonctionnait bien dans les deux cas.
Oui, cela vaudrait la peine d’essayer de changer l’adresse de réponse pour utiliser une adresse avec le domaine SES vérifié, comme recommandé dans la réponse ci-dessus, juste pour tester si cela permettra un envoi correct.
Si cela ne fonctionne pas, je vérifierais si votre hébergeur bloque certains ports et je vérifierais à nouveau que les identifiants SES ont été générés correctement. Je vois que vous avez confirmé ci-dessus que votre domaine est vérifié avec SES.
La réponse est bien sur le même domaine que l’expéditeur, oui, mais dans certains cas, ce n’est pas le même sous-domaine (toutefois, il s’agit toujours du même domaine racine). Les deux cas fonctionnent parfaitement pour moi.
Je suis certain que vous avez remarqué cela : avez-vous vérifié l’adresse e-mail de sortie utilisée par Discourse pour envoyer ?
Si elle est notify@votredomaineverifié, vous devez vous rendre dans SES, deuxième ligne sous « Gestion des identités », ajouter puis vérifier l’e-mail d’envoi. Rien ne part tant que vous n’avez pas fait cela.
Pas d’alarmes, pas de sirènes, simplement rien ne fonctionne.
Avoir une réponse Gmail est excellent. C’est ce que j’ai fait. Ensuite, les e-mails d’autorisation destinés aux membres étaient bloqués par les filtres anti-spam car l’expéditeur et la réponse ne correspondaient pas.
Finalement, j’ai écrit une simple fonction AWS Lambda (il m’a fallu une semaine pour apprendre à le faire) qui transmet les e-mails entrants à l’API Discourse. Très propre. Pas besoin de POSTFIX.
