Configurer la réception des e-mails en livraison directe pour sites auto-hébergés avec Mail-Receiver

Bonjour ! J’ai un problème étrange où j’ai configuré ceci en suivant le guide, et ça fonctionne très bien ! Cependant, quelque chose s’est mal passé avec l’e-mail sortant, ce qui, je pensais, ne serait pas affecté par tout cela. Sidekiq donne l’erreur suivante pour chaque tentative d’e-mail (tous bloqués dans la liste des tentatives) depuis que j’ai activé mail-receiver :

Jobs::HandledExceptionWrapper: Wrapped OpenSSL::SSL::SSLError: SSL_read: unexpected eof while reading

Mes recherches me font penser que cela est lié au TLS d’une manière ou d’une autre. J’avais décommenté les lignes liées au TLS dans le fichier .yml, mais les re-commenter n’a pas non plus résolu le problème. J’ai essayé les instructions du guide pour résoudre les conflits Postfix, mais apparemment je n’ai pas Postfix ? (Le répertoire /etc/postfix du guide n’existe pas sur mon instance, et il ne reconnaît pas non plus postfix comme un service.) Et selon les résultats de netstat, seul docker-proxy utilise le port 25.

Nous utilisons Gmail comme service SMTP sortant, et en fait, nous utilisions Gmail pour le polling POP3 entrant avant cela. J’ai supprimé un tas d’enregistrements MX pointant vers Google, mais le guide disait de le faire.

Voici mon mail-receiver.yml, avec certains détails bien sûr masqués :

## ceci est le modèle de conteneur de réception d'e-mails
##
## Après avoir apporté des modifications à ce fichier, vous DEVEZ reconstruire
## /var/discourse/launcher rebuild mail-receiver
##
## SOYEZ *TRÈS* PRUDENT LORS DE LA MODIFICATION !
## LES FICHIERS YAML SONT EXTRÊMEMENT SENSIBLES AUX ERREURS D'ESPACEMENT OU D'ALIGNEMENT !
## visitez http://www.yamllint.com/ pour valider ce fichier si nécessaire

base_image: discourse/mail-receiver:release
update_pups: false

expose:
  - "25:25"   # SMTP

env:
  LC_ALL: en_US.UTF-8
  LANG: en_US.UTF-8
  LANGUAGE: en_US.UTF-8

  ## Où les e-mails vers votre forum doivent être envoyés. En général, il est tout à fait acceptable
  ## d'utiliser le même domaine que le forum lui-même ici.
  MAIL_DOMAIN: discourse.[mydomain].org
# décommentez ceci (et le volume ci-dessous !) pour prendre en charge TLS
  POSTCONF_smtpd_tls_key_file:  /letsencrypt/discourse.[mydomain].org/discourse.[mydomain].org.key
  POSTCONF_smtpd_tls_cert_file:  /letsencrypt/discourse.[mydomain].org/fullchain.cer
  POSTCONF_smtpd_tls_security_level: may


  ## L'URL de base pour cette instance Discourse.
  ## Ce sera quelle que soit l'URL de votre site Discourse. Par exemple,
  ## https://discourse.example.com. Si vous utilisez une configuration de sous-dossier,
  ## assurez-vous d'en tenir compte (par exemple, https://example.com/forum).
DISCOURSE_BASE_URL: 'https://discourse.[mydomain].org'

  ## La clé API principale de votre forum Discourse. Vous pouvez l'obtenir
  ## dans l'onglet "API" de votre panneau d'administration.
  DISCOURSE_API_KEY: [myapikey]

  ## Le nom d'utilisateur à utiliser pour le traitement des e-mails entrants. Sauf si vous avez
  ## renommé l'utilisateur `system`, vous devriez le laisser tel quel.
  DISCOURSE_API_USERNAME: system

volumes:
  - volume:
      host: /var/discourse/shared/mail-receiver/postfix-spool
      guest: /var/spool/postfix
# décommentez pour prendre en charge TLS
  - volume:
      host: /var/discourse/shared/standalone/letsencrypt
      guest: /letsencrypt

La technologie des e-mails est un peu en dehors de mon expertise, donc j’apprécie tout conseil, même s’il s’agit de signaler que j’ai manqué quelque chose de stupide lors de la configuration. Merci !

1 « J'aime »

Comme vous le pensiez, cela n’a rien à voir avec le récepteur du cou. L’hôte par lequel vous envoyez des e-mails a un certificat SSL défectueux.

Eh bien, j’ai trouvé la solution après beaucoup de dépannage. Le problème venait probablement du fait que le domaine sur lequel nous hébergeons notre instance Discourse n’est pas le même que le domaine sur lequel se trouvaient nos enregistrements MX. Une fois que j’ai surmonté cette confusion, tout s’est éclairci.

C’est certainement ma propre stupide erreur, mais le guide a un peu contribué à ma confusion avec ceci :

Il n’est pas très clair que les deux entrées forum.example.com n’ont pas besoin d’être identiques, et dans mon cas, elles devaient être différentes. C’est peut-être quelque chose que les utilisateurs de ce guide devraient savoir, mais je ne le savais pas. Je laisse donc cela ici pour quiconque pourrait rencontrer un problème similaire. J’ai appris quelques notions sur le DNS que j’ignorais, donc ce fut une bonne expérience d’apprentissage, et tout fonctionne parfaitement maintenant. :slight_smile:

Eh bien, j’ai parlé trop vite. Les e-mails sortants fonctionnent bien, les réponses entrantes semblent fonctionner, mais l’envoi à l’adresse e-mail d’une catégorie échoue silencieusement. J’ai copié-collé l’adresse directement depuis les paramètres dans un nouvel e-mail, donc je sais qu’il n’y a pas de fautes de frappe.

Les journaux de mon mail-receiver contiennent essentiellement trois types d’entrées. L’entrée réussie, qui était une réponse par e-mail à un message existant, ressemble à ceci :

Sep 20 16:59:44 discourse-mail-receiver postfix/smtpd[277]: connect from server168-1.web-hosting.com[68.65.122.144]
Sep 20 16:59:45 discourse-mail-receiver postfix/smtpd[277]: NOQUEUE: reject: RCPT from server168-1.web-hosting.com[68.65.122.144]: 454 4.7.1 <[category]@discourse.[domain].org>: Relay access denied; from=<ryan@[redacted].com> to=<[category]@discourse.[domain].org> proto=ESMTP helo=<server168-1.web-hosting.com>
<22>Sep 20 16:59:45 policyd-spf[288]: : prepend Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=[redacted]; helo=server168-1.web-hosting.com; envelope-from=ryan@[redacted].com; receiver=discourse.[domain].org Sep 20 16:59:45 discourse-mail-receiver postfix/cleanup[281]: 4CCED114200: message-id=<20240920165945.4CCED114200@discourse-mail-receiver.localdomain>
Sep 20 16:59:45 discourse-mail-receiver postfix/smtpd[277]: disconnect from server168-1.web-hosting.com[68.65.122.144] ehlo=1 starttls=0/1 mail=1 rcpt=0/1 data=0/1 quit=1 commands=3/6

En dehors de cela, il y a deux types d’erreurs (que je suppose être des erreurs), chacune se répétant assez souvent. La première ressemble à ceci :

Sep 20 17:00:23 discourse-mail-receiver postfix/qmgr[124]: 5D162FC26D: from=<double-bounce@discourse-mail-receiver.localdomain>, size=960, nrcpt=1 (queue active)

Et l’autre :

Sep 20 17:00:23 discourse-mail-receiver postfix/error[293]: 8DC3BFC141: to=<postmaster@discourse-mail-receiver.localdomain>, orig_to=<postmaster>, relay=none, delay=126622, delays=126622/0.05/0/0, dsn=4.4.3, status=deferred (delivery temporarily suspended: Host or domain name not found. Name service error for name=discourse-mail-receiver.localdomain type=MX: Host not found, try again)

Et voici à quoi ressemble mon mailq, juste des entrées comme celle-ci encore et encore et encore :

3D07BFC23D      960 Fri Sep 20 06:42:23  double-bounce@discourse-mail-receiver.localdomain
(delivery temporarily suspended: Host or domain name not found. Name service error for name=discourse-mail-receiver.localdomain type=MX: Host not found, try again)
                                         postmaster@discourse-mail-receiver.localdomain

Une partie de cela semble avoir trait aux e-mails que Discourse envoie, qui sont ensuite rejetés pour une raison quelconque. Le mail-receiver a-t-il une fonctionnalité pour traiter ces rejets, ou resteront-ils dans la mailq pour toujours ?

Deuxièmement, pourquoi les réponses fonctionnent-elles, mais pas l’envoi direct d’e-mails à une catégorie ? Merci encore pour votre aide et votre patience. :slight_smile:

Cela ressemble aux entrées de journal d’échec à l’adresse d’une catégorie plutôt qu’à une réponse réussie à un message.

Je ne suis pas sûr à 100 %, mais je pense que relay access denied suggère que discourse.[domain].org n’est probablement pas le domaine utilisé pour MAIL_DOMAIN dans mail-receiver.yml. Il est possible que l’adresse de réponse soit autorisée par d’autres moyens.

Je sais que ce qui est utilisé dans MAIL_DOMAIN se retrouve au moins à un endroit dans un fichier de configuration postfix, donc le changer nécessite probablement de reconstruire le conteneur. Avez-vous changé MAIL_DOMAIN et, si oui, avez-vous exécuté ./launcher rebuild mail-receiver ensuite ?

2 « J'aime »

[Désolé d’avoir accidentellement appuyé sur Entrée prématurément avant de terminer mon message précédent]

Je me casse toujours la tête sur ce problème. Mais j’ai une nouvelle idée sur ce qui pourrait être le problème. Je travaille avec deux domaines, appelons-les [domain1] et [domain2]. Mon relais SMTP Gmail est hébergé sur [domain1]. Mon instance Discourse, ainsi que mon mail-receiver, sont hébergés sur [domain2].

Comment configurer le paramètre reply-by-email-address dans Discourse pour forcer une adresse de réponse sur [domain2], lorsque l’e-mail est envoyé depuis [domain1] ? J’obtiens l’erreur SSL EOF mentionnée ci-dessus en essayant de faire cela. Je suppose qu’il y a une astuce de DNS ou quelque chose que je manque.

Il semble que j’aie enfin trouvé la solution. Pour que l’adresse « reply-to » soit dans un domaine différent de celui du relais SMTP, j’ai dû assouplir certains paramètres dans Google Workspace. Tout semble fonctionner comme prévu dans les deux sens.

1 « J'aime »

Une dernière question ici. Même si tout fonctionne correctement maintenant, j’ai encore un tas d’anciennes entrées dans ma mailq. Ce sont très probablement des e-mails qui ont été générés avec les mauvais paramètres et qui resteront donc bloqués dans les limbes pour toujours. Je préférerais simplement les supprimer et passer à autre chose. Alors, comment puis-je vider la mailq ?

Un peu ancien, mais la raison la plus courante de l’erreur SSL EOF est un conflit entre les versions d’OpenSSL : v1.1.1f contre v3. La mise à niveau de cet ancien 1.1.1f sera la solution. Et la mauvaise nouvelle est que, par exemple, Ubuntu 20.x ne peut pas utiliser une version plus récente, donc tout Ubuntu doit être mis à niveau.

1 « J'aime »

Je suis à bout de mes ressources, après avoir passé des heures. Je n’arrive pas à dépasser cette erreur de Launcher, même si les noms de mes fichiers de configuration sont tous en minuscules.

“ERREUR : Le nom de la configuration ne doit pas contenir de caractères majuscules, d’espaces ou de caractères spéciaux. Corrigez le nom de la configuration et relancez ./launcher.”

lors de l’exécution de

./launcher rebuild mail-receiver

ou

./launcher bootstrap mail-receiver

ou

./launcher start mail-receiver

Je peux le voir ici dans le code source du lanceur

Grrrrrrrrrr – S’il vous plaît, aidez-moi !

J’ai essayé tout ce qui est mentionné dans le post lié ci-dessus concernant la locale, et tout ce que j’ai pu trouver ailleurs.

./launcher rebuild app___ fonctionnent tous très bien !

J’ai un indice possible : cela a commencé à se produire immédiatement après avoir accidentellement appuyé sur Verr Maj (mais en mettant en majuscules seulement 2 lettres) en nommant le fichier de configuration, que j’avais ensuite immédiatement désactivé Verr Maj et retapé les 2 lettres avant même de l’enregistrer.

Difficile d’imaginer comment cette brève faute de frappe/correction a pu causer cela, mais peut-être que les majuscules sont bloquées dans un tampon quelque part, ou ???

C’est bien au-delà de mes connaissances, mais je suis surpris que le message d’erreur ne sorte pas la variable $config :thinking:
Cela aiderait certainement au débogage.

1 « J'aime »

Merci @Canapin ! - voici ce que j’essaie de configurer :

https://www.perplexity.ai/search/provide-the-code-lJcI4BrFQ2auuD42ehYFwA

Pouvez-vous copier-coller tout le contenu de votre ligne de commande ?

De votre ./launcher start mail-receiver au message d’erreur, ainsi que le nom de fichier .yml exact ?

Si je renomme le fichier de configuration en Mail-receiver.yml, ./launcher start Mail-receiver produira

ERROR: Config name 'Mail-receiver' must not contain upper case characters, spaces or special characters. Correct config name and rerun ./launcher.

Ici, le message d’erreur contient le nom du fichier.

De plus, si vous exécutez ./launcher start aaa, il ne trouvera aucun fichier correspondant et listera ceux disponibles. Il ne les sélectionne que dans le dossier, il n’y a donc rien de magique ici, mais peut-être qu’il affichera quelque chose d’intéressant :person_shrugging:

ERROR: containers/aaa.yml does not exist or is not readable.

Available configs ( app, mail-receiver )

Merci beaucoup – j’ai résolu le problème et ça fonctionne.

Quel était le problème au final ? Pourrait aider d’autres personnes :slight_smile:

Il n’y a eu aucun problème, c’était vraiment juste une courbe d’apprentissage pour comprendre comment les différents composants du serveur interagissent pour le routage des domaines et des e-mails. Je n’avais jamais exploré l’apprentissage de postfix auparavant. C’était amusant et j’ai beaucoup appris.

La recette que j’ai finalement trouvée consiste à utiliser un fichier mail-receiver.yml (un conteneur Docker) associé à chaque instance de Discourse, partageant tous le port 25 en utilisant la fonctionnalité de transport dans postfix pour gérer le routage.

2 « J'aime »

Sur mon serveur dédié (exécutant Ubuntu 22.04, avec Postfix installé) j’utilise un fichier mail-receiver.yml distinct associé à chaque instance de Discourse pour laquelle j’ai activé la fonctionnalité de publication par e-mail.

Cette configuration crée un conteneur distinct pour chaque instance de Discourse sur mon serveur (en plus du conteneur app typique) qui reçoit et traite les e-mails pour son instance Discourse correspondante.

Les e-mails entrants pour tous les forums Discourse sur le serveur sont reçus par Postfix via le port 25 standard, où le fichier de configuration principal de Postfix utilise une “table de transport” pour “relayer” chaque e-mail vers son forum Discourse prévu en analysant le nom de domaine dans l’adresse “To:” de l’e-mail.

Donc, en plus des instructions de ce sujet, j’ai…

  1. modifié le fichier de configuration Postfix existant à : /etc/postfix/main.cf

  2. ensuite, j’ai ajouté le fichier de table de transport Postfix correspondant à : /etc/postfix/transport

  1. enfin, j’ai ajouté les fichiers correspondants pour créer le conteneur d’e-mails pour chacun des forums :
    /var/discourse/containers/mail-receiver-domain1.yml
    /var/discourse/containers/mail-receiver-domain2.yml
    /var/discourse/containers/mail-receiver-domain3.yml
    /var/discourse/containers/mail-receiver-domain4.yml
    /var/discourse/containers/mail-receiver-domain5.yml

3 « J'aime »

Il n’y a pas de DISCOURSE_MAIL_ENDPOINT dans mail-receiver.yml, et il y a aussi DISCOURSE_BASE_URL à modifier.

2 « J'aime »

J’utilise un service de transfert d’e-mails qui prend en charge le transfert d’e-mails au format JSON vers un webhook.

Est-ce une option pour la livraison directe d’e-mails ?

1 « J'aime »