Ceci concerne une installation initiale, et je ne suis absolument pas un expert en DNS ! Voici où j’en suis :
Les tests d’envoi d’e-mails fonctionnent parfaitement. J’utilise MailGun avec leur sous-domaine recommandé « mg ». J’envoie sur le port 2525. J’ai bien saisi l’API MailGun pour les webhooks dans le champ correspondant des paramètres (ils ont TROIS API différentes — est-ce la bonne ??). J’ai également configuré les enregistrements MX pour le sous-domaine mg dans mes paramètres DNS. La validation de MailGun indique que tout fonctionne correctement, tout comme mail-tester.com.
La réception est configurée avec un sous-domaine appelé « inbound ». Si j’envoie un e-mail depuis un compte Gmail vers fake@inbound.[mondomaine].org, je vois cet e-mail arriver dans le journal du récepteur de courriels. Si j’envoie, depuis Discourse, un e-mail de test vers la même adresse via Paramètres > E-mail, l’e-mail semble disparaître — rien n’apparaît dans la corbeille des rejetés. Pour le reste, j’utilise la réception directe et simple des courriels entrants.
En raison d’autres erreurs que je me suis infligées lors du processus de configuration, j’ai décidé de repartir de zéro : j’ai supprimé mon droplet, réinstallé Discourse et je recommence tout. Je n’ai cependant pas supprimé le compte MailGun et j’utilise toujours le même webhook API qu’avant. Cela pourrait-il être le problème ? J’utilise toutefois une nouvelle clé API générée par Discourse (l’ancienne, évidemment, a été vaporisée lorsque j’ai supprimé le droplet).
La seule autre chose à laquelle je peux penser, c’est le point de terminaison dans mail-receiver.yml. Le mien ressemble à ceci : DISCOURSE_MAIL_ENDPOINT: 'https://inbound.[mondomaine].org/admin/email/handle_mail'.
Avez-vous des idées sur l’origine du blocage ? (Pour couronner le tout, cela fonctionnait parfaitement il y a peu de temps — avant que je ne supprime le droplet. Apparemment, j’apprends lentement ). Merci à tous !
Cela devrait être le domaine de votre forum, et non celui de votre adresse e-mail. Pouvez-vous confirmer que votre forum n’est pas situé à inbound.[mydomain].org ? Par exemple, si Meta utilisait cette méthode, l’URL ressemblerait à ceci :
De plus, cela n’a rien à voir avec Mailgun, sauf pour vous assurer d’ignorer les instructions de Mailgun concernant l’ajout d’enregistrements MX pour le domaine. Comme indiqué :
Remarque : les fournisseurs d’e-mails sortants comme Mailgun peuvent vous demander d’ajouter des enregistrements MX pointant vers leurs serveurs. Vous devez les supprimer afin que les enregistrements MX de votre forum pointent uniquement vers le nom de domaine de votre forum. Les enregistrements SPF et DKIM doivent toujours pointer vers les serveurs de votre fournisseur d’e-mails sortants afin que vous puissiez envoyer des e-mails.
@tobiaseigen On s’en rapproche ! J’ai apporté la modification en supprimant le sous-domaine de messagerie entrante de l’endpoint. J’ai enregistré, puis redémarré le récepteur de courriels (parce que je ne sais pas ce que je fais !). J’ai effectué un test. Pas de succès. Ensuite, j’ai procédé à une reconstruction complète de l’application. Puis j’ai créé deux nouveaux comptes en utilisant des adresses e-mail distinctes. J’ai ensuite utilisé le compte administrateur pour envoyer un message privé à l’un d’eux. Cela a généré un e-mail comme prévu. J’ai ensuite répondu par e-mail au message privé. Voici le résultat dans le journal de messagerie :
En effet, on s’en rapproche ! Je ne suis pas sûr de savoir ce que signifie cet échec temporaire ? Cela fait 13 minutes, et cela ne s’achemine toujours pas vers Discourse. Étrange.
Je dois préciser que j’ai créé le sous-domaine « inbound » car je souhaite qu’une adresse e-mail admin@[mydomain].org soit gérée par un autre serveur de messagerie.
J’ai un peu de mal à comprendre votre utilisation des noms de domaine. Sur mon site, le DISCOURSE_MAIL_ENDPOINT et l’enregistrement MX pour les e-mails entrants sont sur le même domaine, pointant vers le serveur Discourse, comme expliqué dans le message d’origine sur Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver. Vous semblez essayer d’utiliser des domaines différents.
Généralement, vous voulez utiliser un sous-domaine du type forum.mondomaine.org pour votre Discourse, afin de séparer votre forum de votre site web principal et de vos e-mails sur mondomaine.org.
Je suis ravi de clarifier cela et je vais faire semblant que mon domaine est thesite.org pour simplifier. Ce que je constate, c’est un problème SSL dans les journaux du récepteur de courriels : <19>Nov 25 19:11:29 receive-mail[160]: Échec de la requête POST du courriel vers https://inbound.thesite.org/admin/email/handle_mail : le nom d'hôte "inbound.thesite.org" ne correspond pas au certificat du serveur (OpenSSL::SSL::SSLError)
Pour répondre à votre question, j’avais deux objectifs, que je suppose être extrêmement courants :
admin@thesite.org devient une adresse pour que les utilisateurs puissent contacter l’administrateur.
thesite.org lance le forum (sans sous-domaine).
Actuellement, mes paramètres DNS chez Namecheap ressemblent à ceci (TTL = Auto et Priority = 10) :
Mes paramètres containers/mail-receiver.yml sont les suivants : MAIL_DOMAIN: inbound.thesite.org DISCOURSE_MAIL_ENDPOINT: 'https://thesite.org/admin/email/handle_mail' DISCOURSE_API_KEY: (stuff) DISCOURSE_API_USERNAME: system ← identique à la clé API
* note—> J’ai laissé les lignes LetsEncrypt telles quelles (je n’ai pas retiré le “#”)
Autres paramètres :
Modifié via la ligne de commande le nom d’hôte en inbound.thesite.org
Courriel de contact = admin@thesite.org
Courriel de notification = noreply@mg.thesite.org
Courriel de réponse par email1 = replies+%{reply_key}@inbound.thesite.org
Courriel de réponse par email2 = %{reply_key}@inbound.thesite.org
Trouver le post associé avec la clé = ACTIVÉ
Sondage manuel = ACTIVÉ
Clé API Mailgun = SAISIE …mais cela pourrait poser problème car elle provient d’une tentative d’installation précédente
Avez-vous des idées sur la marche à suivre ? … et un énorme MERCI d’avance ! Je signale également @pfaffman, car il a également été une ressource précieuse pour m’aider avec mes luttes passées liées à la configuration. Votre guide “Straightforward” était également extrêmement utile. Salutations !
Avez-vous reconstruit à la fois les conteneurs mail et app ? Je pense que la solution la plus simple est de supprimer les éléments qui tentent d’attribuer un certificat au récepteur de courrier. Le certificat fonctionne-t-il pour le site ?
Si le site Discourse n’est pas situé sur inbound.thesite.org, c’est là que réside le problème. L’idée est que le nom d’hôte du site Discourse et celui du récepteur de courrier soient identiques. Vous devrez consulter Configuration de Let’s Encrypt avec plusieurs domaines pour résoudre cela.
Cela dépasse quelque peu le cadre prévu du tutoriel sur le récepteur de courrier. Si cela ne suffit pas à vous remettre sur la bonne voie et que vous disposez d’un budget, n’hésitez pas à me contacter.
La question devient donc : les deux objectifs que j’ai définis ci-dessus peuvent-ils être atteints (ils semblent absurde de banalité) ? La seule solution de contournement consiste-t-elle à rediriger, dans les paramètres DNS, les visiteurs qui tapent www.thesite.org et/ou thesite.org vers subdomain.thesite.org ? Si c’est le cas, je devrai simplement accepter de modifier l’adresse e-mail affichée pour quelque chose d’aussi laid que admin@subdomain.thesite.org.
Je peux accepter de modifier l’adresse e-mail de l’administrateur si je n’ai pas le choix. Il semble que nous passions à côté de quelque chose d’évident, mais peut-être que je suis dans le champ (ce qui est probablement le cas !).
Si ce que vous voulez, c’est que le destinataire du courriel reçoive les messages sur un domaine différent de celui de votre instance Discourse, je pense que c’est possible. La chose la plus simple est de ne pas utiliser le certificat Let’s Encrypt sur le destinataire du courriel.
@pfaffman tu es un génie ! Ça a marché !! :clap : En suivant Configuration de Let’s Encrypt avec plusieurs domaines, puis en reconstruisant Discourse suivi de la reconstruction de mail-receiver (l’une des deux étapes était probablement inutile), l’astuce a fonctionné. Voila !
Plus tard ce soir, je voudrais copier-coller l’OP « Livraison directe simplifiée des e-mails entrants » dans un document Google et proposer mes modifications suggérées. Sans que cela soit de la faute de qui que ce soit, certaines parties de l’OP ne sont pas intuitives pour quelqu’un comme moi qui ne connaît pas ou ne comprend pas les commandes en ligne. Je pense que les deux objectifs que j’ai définis ci-dessus sont très courants pour de nombreuses installations, et maintenant je sais que l’objectif final peut être atteint.
J’ai d’autres suggestions pour le tutoriel complet de configuration. J’ai une liste à jour de modifications suggérées pour rendre le processus aussi simple que possible.
Merci beaucoup de m’avoir aidé ici ! Super apprécié !
). Merci à tous !
et je vais faire semblant que mon domaine est 