Hm. J’ai la même configuration Vultr que @MathiasFoster et @jryans ici, et j’ai rencontré le même problème (Net::OpenTimeout). ufw allow https a permis à mon courrier entrant de fonctionner.
Mais maintenant, le site ne peut envoyer aucun e-mail. Avant de configurer le courrier entrant, le courrier sortant fonctionnait bien.
Je n’ai rien de compliqué :
notification_email est admin@tasat.org.
Le courrier sortant utilise smtp.titan.email chez Hostinger.
Dans les e-mails ignorés, je vois <replies+verp-14c9cc6eb915b08d4983c90c744ba4b4@forum.tasat.org>: Adresse de l'expéditeur rejetée : non détenue par l'utilisateur admin@tasat.org
Je suis nouveau dans la fabrication de saucisses d’e-mail. Dois-je retirer forum. des chaînes de mail_receiver.yml et faire de “replies@tasat.org” un alias d’envoi de “admin@tasat.org” ?
Le récepteur de courrier est indépendant de Discourse et de l’envoi d’e-mails. Il agit simplement comme un serveur de messagerie simple configuré uniquement pour recevoir des e-mails, en utilisant l’API Discourse pour pousser ces e-mails dans Discourse.
La seule chose à laquelle je peux penser lors de sa configuration qui pourrait affecter l’envoi est la définition de « adresse e-mail de réponse », bien que cela ne devrait que définir Reply-To sur les e-mails sortants et n’affecter pas l’adresse de l’expéditeur.
Juste pour confirmer, il semble que vous ayez ces éléments (entre autres) dans app.yml :
Si oui, les notifications par e-mail qui n’acceptent pas de réponses fonctionnent-elles toujours ? Je crois que la vérification par e-mail en est un exemple, vous pourriez donc essayer de créer un compte et de voir si cet e-mail est envoyé avec succès.
Avec cette configuration, ce qui devrait se passer pour les e-mails qui peuvent accepter des réponses, c’est que l’e-mail envoyé utilise : From: admin@tasat.org (également adresse de l’expéditeur) Reply-To: replies+abc123@forum.tasat.org
Généralement, Reply-To n’est pas traité comme faisant partie des informations de l’expéditeur, il fournit simplement une adresse To par défaut à utiliser lorsque les gens répondent, mais peut-être que Hostinger le traite comme tel. Vous pourriez ajouter un alias d’envoi pour replies@forum.tasat.org.
Je pense que Vultr (ou peut-être simplement l’installation de Docker lorsque ufw est présent) a des règles qui empêchent les conteneurs de communiquer entre eux, ce qui signifie que le récepteur de courrier ne peut pas se connecter à Discourse. ufw allow https contourne ce problème.
Sur le réseau par défaut, ce n’est que si un conteneur se connecte directement à un autre conteneur par son adresse IP locale, qu’il s’agit de l’adresse IP locale du conteneur lui-même.
Lorsque le récepteur de courrier recherche votre nom de domaine Discourse, il n’obtiendra pas cette adresse IP locale et devra quitter son réseau Docker et passera au moins une fois par ufw pour atteindre Discourse.
C’est une situation distincte, bien que liée. Il s’agit de connexions provenant de l’extérieur et Docker ajoute des règles pour autoriser le passage des ports exposés.
Je ne suis pas très familier avec les règles de chaînes netfilter/iptables, mais je pense que ce qui précède montre :
Si la connexion provient de docker0, c’est-à-dire du réseau Docker par défaut, retournez à la chaîne précédente (arrêtez le traitement des règles dans cette chaîne).
Sinon, si la connexion provient de tout sauf de docker0, s’il s’agit également de https ou http, spécifiez DNAT, ce qui la fera passer à la chaîne FORWARD.
Ainsi, avec l’agencement montré dans l’autre sujet, si le trafic https ou http arrive de l’extérieur, il est dirigé vers Docker. Si le trafic provient du réseau Docker, il sera retourné et rejeté ou abandonné par la chaîne INPUT.
Ce que fait ufw allow https, c’est d’ajouter une règle à la chaîne INPUT qui l’accepte. De cette façon, lorsque la connexion est retournée à la chaîne INPUT comme ci-dessus, elle sera acceptée et trouvera Docker à l’écoute, étant finalement acheminée vers le conteneur.
Merci pour vos réponses ! J’ai dû m’absenter un peu, mais je m’y remets…
Oui, c’est ce que j’ai pour le moment.
Quand j’essaie de créer un compte maintenant, le bouton de soumission ne fait rien. Comme s’il savait que ça ne fonctionnerait pas. (Et rien n’apparaît dans “Skipped” ou ailleurs.)
Edit : J’ai défini “replies@tasat.org” comme alias d’envoi pour admin@tasat.org, et j’ai confirmé que cela fonctionne pour l’envoi et la réception. J’ai également confirmé la livraison d’un e-mail envoyé depuis un client externe adressé à replies+verp-174bc7d8411bc4ec2cfa84c55bd31425@forum.tasat.org
Dans un souci d’essayer quelque chose, j’ai changé reply by email address :
de replies+%{reply_key}@forum.tasat.org
à replies+%{reply_key}@tasat.org
Mais cela ne change pas les résultats.
Il n’arrive pas sur mail-tester. Toutes les tentatives sortantes finissent dans “skipped” avec un message de ce type :
553 5.7.1 <replies+verp-8c79cd4e83023bda6df0624c2cacd36e@tasat.org> :
Sender address rejected: not owned by user admin@tasat.org
Peut-être que c’est intéressant… ? Lorsque j’exécute discourse-doctor, l’e-mail sortant échoue comme suit :
==================== MAIL TEST ====================
Pour un test robuste, obtenez une adresse sur http://www.mail-tester.com/
Envoi d'un e-mail à REDACTED . .
Test d'envoi à admin@tasat.org en utilisant smtp.titan.email:587,
nom d'utilisateur:admin@tasat.org avec authentification simple.
Connexion au serveur SMTP réussie.
Envoi à admin@tasat.org. . .
L'e-mail n'a pas été envoyé.
Raison : 553 5.7.1 <replies+verp-3cc19f7b135e6f56219e030999db9e29@tasat.org> :
Adresse de l'expéditeur rejetée : non détenue par l'utilisateur admin@tasat.org
L’envoi direct à l’adresse replies+ (ou à une adresse forum.tasat.org) depuis un client de messagerie fonctionne – il suit l’alias “replies” et arrive dans la boîte de réception admin. D’où vient le rejet ?
J’ai consulté la section de l’article “Prevent outgoing host email from interfering.” Je n’ai pas de chemin /etc/postfix – mais voici ma sortie netstat :
GROSSE MODIFICATION – J’ai eu une réponse du support Titan ce soir : “L’adresse reply-to et l’adresse de l’expéditeur doivent être identiques, sinon l’e-mail ne passera pas.” Je suppose donc que tous les dépannages sont inutiles et que je dois chercher un nouvel hébergeur d’e-mails qui n’impose pas cette exigence.
Le sujet suivant (lié en bas de ce document) contient également des informations sur la gestion des retours pour ceux-ci et d’autres :
J’utilise personnellement le plan flex de Mailgun (entièrement dans la limite gratuite), mais je sais qu’il y a eu de la confusion autour de leurs prix et que les choses ont potentiellement changé pour les nouveaux utilisateurs depuis que j’ai rejoint. La dernière fois que j’ai vu (je ne sais pas si c’est toujours vrai), il était possible de passer au plan flex après la fin de l’essai, c’était juste incroyablement peu clair.
C’est ça.
Vous pouvez passer à mailgun flex, bien qu’ils rendent les choses difficiles à comprendre. Environ une fois par mois, je leur envoie un e-mail pour leur demander pourquoi il est si difficile de le trouver.
@Simon_Manning & @pfaffman – merci encore pour vos commentaires et vos conseils, cela m’a mis sur la bonne voie.
J’ai décidé d’essayer MailerSend, car leur plan gratuit actuel est assez généreux. Il devrait convenir à notre effort sans but lucratif pendant un certain temps. Tout fonctionne bien jusqu’à présent
