J’ai fait cette erreur et j’ai laissé discourse.example.com dans le fichier mail-receiver.yml.
Je l’ai corrigé maintenant, mais mail-receiver ne semble pas « prendre en compte » les nouveaux détails.
Comment puis-je « réinitialiser » mail-receiver (par exemple, quelle est la commande équivalente à ./launcher rebuild app ?).
Modifier : Je n’ai pas lu le message précédent assez attentivement, la commande est ./launcher rebuild mail_receiver.
Je rencontre maintenant un autre problème où mail-receiver n’arrive pas à livrer les e-mails à Discourse — j’ai cherché de l’aide, mais sans succès.
Journaux :
Starting Postfix
Dec 14 03:12:32 forum-mail-receiver postfix/master[1]: daemon started -- version 3.5.6, configuration /etc/postfix
Dec 14 03:15:47 forum-mail-receiver postfix/smtpd[113]: connect from mail-pl1-f169.google.com[209.85.214.169]
Dec 14 03:15:47 forum-mail-receiver postfix/smtpd[113]: 821CB37A659: client=mail-pl1-f169.google.com[209.85.214.169]
Dec 14 03:15:47 forum-mail-receiver postfix/cleanup[120]: 821CB37A659: message-id=<602f2194be912e92b969eacf5eac26e2@frontapp.com>
Dec 14 03:15:47 forum-mail-receiver postfix/qmgr[98]: 821CB37A659: from=<[my personal email address]>, size=4086, nrcpt=1 (queue active)
<23>Dec 14 03:15:47 receive-mail[122]: Recipient: nobody@[my forum URL]
Dec 14 03:15:47 forum-mail-receiver postfix/smtpd[113]: disconnect from mail-pl1-f169.google.com[209.85.214.169] ehlo=1 mail=1 rcpt=1 bdat=1 quit=1 commands=5
<19>Dec 14 03:16:47 receive-mail[122]: Failed to POST the e-mail to [my forum URL]/admin/email/handle_mail: execution expired (Net::OpenTimeout)
<19>Dec 14 03:16:47 receive-mail[122]: /usr/lib/ruby/2.7.0/net/http.rb:960:in `initialize'
/usr/lib/ruby/2.7.0/net/http.rb:960:in `open'
/usr/lib/ruby/2.7.0/net/http.rb:960:in `block in connect'
/usr/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
/usr/lib/ruby/2.7.0/net/http.rb:958:in `connect'
/usr/lib/ruby/2.7.0/net/http.rb:943:in `do_start'
/usr/lib/ruby/2.7.0/net/http.rb:932:in `start'
/usr/lib/ruby/2.7.0/net/http.rb:1483:in `request'
/usr/local/lib/site_ruby/mail_receiver/discourse_mail_receiver.rb:43:in `process'
/usr/local/bin/receive-mail:13:in `<main>'
Dec 14 03:16:47 forum-mail-receiver postfix/pipe[121]: 821CB37A659: to=<nobody@[my forum URL]>, relay=discourse, delay=60, delays=0.17/0.01/0/60, dsn=4.3.0, status=deferred (temporary failure)
Dec 14 03:17:32 forum-mail-receiver postfix/qmgr[98]: 7C67437A663: from=<[my personal email address]>, size=4093, nrcpt=1 (queue active)
Une idée de ce qui pourrait causer cela ?
Le fichier mail-receiver.yml est valide, et j’ai vérifié les fautes de frappe :
Voici la portée de ma clé API :
Les e-mails arrivent bien dans mail-receiver, mais ils restent dans la file d’attente mailq :
Alternativement, existe-t-il un moyen de supprimer entièrement le conteneur mail-receiver et de recommencer ?
Le problème pourrait être que vous n’avez pas défini la clé API.
Merci pour la réponse @pfaffman… c’est bien défini dans ma configuration mail-receiver.yml. Devrait-il être entre guillemets ?
(Net::OpenTimeout)
C’est votre problème. Le récepteur de courrier ne peut pas accéder à l’URL de votre forum. Soit vous avez la mauvaise URL, soit il y a un problème réseau dans Docker entre le récepteur de courrier et votre forum, je pense.
Comment puis-je dépanner davantage ?
ping forum.[mydomain].co.nz
depuis l’intérieur de mailq affiche :
64 bytes from [ip].vultrusercontent.com ([ip]): icmp_seq=1 ttl=64 time=0.113 ms
64 bytes from [ip].vultrusercontent.com ([ip]): icmp_seq=2 ttl=64 time=0.074 ms
64 bytes from [ip].vultrusercontent.com ([ip]): icmp_seq=3 ttl=64 time=0.069 ms
et ainsi de suite, montrant qu’une connexion est réussie.
forum.[mydomain].co.nz est l’endroit où le forum est hébergé, et cette même URL est utilisée dans MAIL_DOMAIN et DISCOURSE_MAIL_ENDPOINT.
En examinant de plus près les paramètres de mail-receiver.yml, est-ce qu’il me manque des guillemets ou https:// là où il le faudrait ?
## ceci est le modèle de conteneur de réception de courrier entrant
##
## Après avoir effectué des modifications dans 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ù le courrier électronique vers votre forum doit être envoyé. En général, il est tout à fait acceptable
## d'utiliser le même domaine que le forum lui-même ici.
MAIL_DOMAIN: forum.[domain].co.nz
# décommentez ceux-ci (et le volume ci-dessous !) pour prendre en charge TLS
# POSTCONF_smtpd_tls_key_file: /letsencrypt/discourse.example.com/discourse.example.com.key
# POSTCONF_smtpd_tls_cert_file: /letsencrypt/discourse.example.com/fullchain.cer
# POSTCONF_smtpd_tls_security_level: may
## L'URL du point de terminaison de traitement des e-mails de votre forum Discourse.
## C'est simplement l'URL de base de votre forum, avec `/admin/email/handle_mail`
## ajouté. Faites attention si vous utilisez une configuration de sous-dossier -- dans ce cas,
## l'URL doit inclure le sous-dossier !
DISCOURSE_MAIL_ENDPOINT: 'https://forum.[domain].co.nz/admin/email/handle_mail'
## La clé API maître de votre forum Discourse. Vous pouvez l'obtenir à partir de
## l'onglet "API" de votre panneau d'administration.
DISCOURSE_API_KEY: 639[rest of API key]884ef
## 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
Exécutez-vous la commande ping à l’intérieur du conteneur, c’est-à-dire après avoir d’abord exécuté ./launcher enter mail-receiver ?
Il convient également de noter que la commande ping (généralement ICMP) est différente de la connexion à http/https (TCP) et peut se comporter différemment en fonction de nombreux facteurs de configuration réseau.
J’essaierais d’utiliser curl après être entré dans le conteneur pour voir s’il peut se connecter à votre forum via https, par exemple :
cd /var/discourse
./launcher enter mail-receiver
curl -v https://forum.[domain].co.nz
Si cela fonctionne, cela affichera une quantité de HTML. Si cela ne fonctionne pas, cela affichera une erreur et -v affichera beaucoup d’informations en cours de route, ce qui pourrait aider à révéler pourquoi cela a échoué.
Si cela échoue, il est également utile d’essayer d’exécuter la même commande curl en dehors du conteneur pour identifier si le problème est spécifique au conteneur ou au système hôte en général.
Merci @Simon_Manning, votre aide est très appréciée ! Je ne savais pas que les connexions via ping n’étaient pas nécessairement les mêmes que les connexions via curl.
Je lançais ping à l’intérieur du conteneur, et cela a réussi.
J’ai suivi vos instructions et lancé curl à l’intérieur du conteneur, et cela a échoué :
root@forum:/var/discourse# ./launcher enter mail-receiver
x86_64 arch detected.
WARNING: containers/mail-receiver.yml file is world-readable. You can secure this file by running: chmod o-rwx containers/mail-receiver.yml
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
root@forum-mail-receiver:/# curl -v https://forum.[domain].co.nz
* Trying [IPv4 address]:443...
* Trying [IPv6 address]:443...
* Immediate connect fail for [IPv6 address]: Cannot assign requested address
* connect to [IPv4 address] port 443 failed: Connection timed out
* Failed to connect to forum.[domain].co.nz port 443: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to forum.[domain].co.nz port 443: Connection timed out
Ensuite, j’ai tapé exit puis curl à nouveau, et j’ai obtenu :
root@forum:/var/discourse# curl -v https://forum.[domain].co.nz
* Trying 127.0.1.1:443...
* Connected to forum.[domain].co.nz (127.0.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
...et ainsi de suite.
Il semble que ce soit spécifique au conteneur, et non au système hôte — des idées ?
J’ai également ouvert un ticket de support auprès de Vultr (fournisseur VPS pour cette instance) pour voir s’il y a un problème de leur côté !
Docker crée des réseaux virtuels pour les conteneurs et en l’absence de spécification, les conteneurs utiliseront le réseau par défaut. Ce réseau par défaut ne permet pas la communication entre conteneurs.
C’est généralement acceptable pour mail-receiver car votre conteneur Discourse aura le port 443 exposé en dehors de ce réseau et lorsque mail-receiver essaiera de se connecter à 1.2.3.4, il quittera le réseau Docker. Le système hôte (ou un réseau plus éloigné) réalisera qu’il doit revenir et finira par entrer dans le conteneur Discourse depuis l’extérieur.
Deux possibilités me viennent à l’esprit. L’une est que mail-receiver est d’une manière ou d’une autre conscient de l’adresse IP du conteneur Discourse lors de la résolution du nom de domaine et qu’une connexion intra-conteneur est donc bloquée. Je pense que c’est peu probable.
L’autre est qu’un pare-feu sur le système hôte bloque les connexions sortant d’un conteneur et entrant dans un autre. Vultr peut utiliser des règles de pare-feu par défaut qui causent cela ou je me souviens aussi vaguement que Docker installe certaines règles dans UFW par défaut, donc cela pourrait être lié si c’est utilisé.
Vous ne pouvez pas utiliser https car vous n’avez pas décommenté ceci :
Cela ne s’applique qu’au support TLS côté serveur de messagerie, c’est-à-dire pour que d’autres serveurs de messagerie puissent livrer des e-mails à mail-receiver via TLS.
Cela vaut la peine d’être fait car le conteneur Discourse a manifestement un certificat, mais cela ne devrait pas affecter la connexion de mail-receiver à Discourse. Potentiellement, la reconstruction pourrait cependant le faire si elle corrige quelque chose dans le réseau du conteneur.
Merci, j’ai décommenté ces lignes, ainsi que la ligne pour le volume.
Mon fichier mail-receiver.yml ressemble maintenant à ceci :
root@forum:/var/discourse# cat containers/mail-receiver.yml
## ceci est le modèle de conteneur du récepteur de courrier entrant
##
## 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ù le courrier électronique destiné à votre forum doit être envoyé. En général, il est tout à fait acceptable
## d'utiliser le même domaine que le forum lui-même ici.
MAIL_DOMAIN: forum.[domain].co.nz
# décommentez ces lignes (et celle du volume ci-dessous !) pour prendre en charge TLS
POSTCONF_smtpd_tls_key_file: /letsencrypt/forum.[domain].co.nz/forum.[domain].co.nz.key
POSTCONF_smtpd_tls_cert_file: /letsencrypt/forum.[domain].co.nz/fullchain.cer
POSTCONF_smtpd_tls_security_level: may
## L'URL du point de terminaison de traitement des e-mails de votre forum Discourse.
## C'est simplement l'URL de base de votre forum, avec `/admin/email/handle_mail`
## ajouté. Faites attention si vous utilisez une configuration en sous-dossier - dans ce cas,
## l'URL doit inclure le sous-dossier !
DISCOURSE_MAIL_ENDPOINT: 'https://forum.[domain].co.nz/admin/email/handle_mail'
## La clé API principale de votre forum Discourse. Vous pouvez l'obtenir à partir de
## l'onglet "API" de votre panneau d'administration.
DISCOURSE_API_KEY: '074[reste de la clé API - oui, j'en ai généré une nouvelle limitée à l'utilisateur système]d98'
## Le nom d'utilisateur à utiliser pour le traitement des e-mails entrants. Sauf si vous avez
## renommé l'utilisateur `system`, vous devriez laisser cela 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
Lorsque j’envoie un nouvel e-mail et que j’exécute ./launcher logs mail-receiver, voici ce que je vois :
Dec 21 22:41:21 forum-mail-receiver postfix/smtpd[132]: connect from mail-pj1-f54.google.com[209.85.216.54]
Dec 21 22:41:23 forum-mail-receiver postfix/smtpd[132]: 16DAC379E42: client=mail-pj1-f54.google.com[209.85.216.54]
Dec 21 22:41:23 forum-mail-receiver postfix/cleanup[139]: 16DAC379E42: message-id=<94fc2bef18b410ae8b121c6af2da2df4@frontapp.com>
Dec 21 22:41:23 forum-mail-receiver postfix/qmgr[100]: 16DAC379E42: from=<[mon adresse e-mail]>, size=5585, nrcpt=1 (queue active)
<23>Dec 21 22:41:23 receive-mail[141]: Recipient: nobody@forum.[domain].co.nzDec 21 22:41:50 forum-mail-receiver postfix/smtpd[143]: connect from mail-oa1-f50.google.com[209.85.160.50]
Dec 21 22:41:52 forum-mail-receiver postfix/smtpd[143]: 2E445379E48: client=mail-oa1-f50.google.com[209.85.160.50]
Dec 21 22:41:52 forum-mail-receiver postfix/cleanup[139]: 2E445379E48: message-id=<6b2f9d646dc46f4fec4af006de01d3ae@frontapp.com>
Dec 21 22:41:52 forum-mail-receiver postfix/qmgr[100]: 2E445379E48: from=<[mon adresse e-mail]>, size=4100, nrcpt=1 (queue active)
<23>Dec 21 22:41:52 receive-mail[147]: Recipient: nobody@forum.[domain].co.nzDec 21 22:41:53 forum-mail-receiver postfix/smtpd[132]: disconnect from mail-pj1-f54.google.com[209.85.216.54] ehlo=2 starttls=1 mail=1 rcpt=1 bdat=1 quit=1 commands=7
Dec 21 22:41:58 forum-mail-receiver postfix/qmgr[100]: 1194937A670: from=<double-bounce@forum-mail-receiver.localdomain>, size=942, nrcpt=1 (queue active)
Dec 21 22:41:58 forum-mail-receiver postfix/smtp[149]: fatal: unknown service: smtp/tcp
Dec 21 22:41:59 forum-mail-receiver postfix/qmgr[100]: warning: private/smtp socket: malformed response
Dec 21 22:41:59 forum-mail-receiver postfix/qmgr[100]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
Dec 21 22:41:59 forum-mail-receiver postfix/master[1]: warning: process /usr/lib/postfix/sbin/smtp pid 149 exit status 1
Dec 21 22:41:59 forum-mail-receiver postfix/master[1]: warning: /usr/lib/postfix/sbin/smtp: bad command startup -- throttling
Dec 21 22:41:59 forum-mail-receiver postfix/error[150]: 1194937A670: to=<postmaster@forum-mail-receiver.localdomain>, orig_to=<postmaster>, relay=none, delay=1192, delays=1191/1/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error)
<19>Dec 21 22:42:23 receive-mail[141]: Failed to POST the e-mail to https://forum.sobercheck.co.nz/admin/email/handle_mail: execution expired (Net::OpenTimeout)<19>Dec 21 22:42:23 receive-mail[141]: /usr/lib/ruby/2.7.0/net/http.rb:960:in `initialize'
/usr/lib/ruby/2.7.0/net/http.rb:960:in `open'
/usr/lib/ruby/2.7.0/net/http.rb:960:in `block in connect'
/usr/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
/usr/lib/ruby/2.7.0/net/http.rb:958:in `connect'
/usr/lib/ruby/2.7.0/net/http.rb:943:in `do_start'
/usr/lib/ruby/2.7.0/net/http.rb:932:in `start'
/usr/lib/ruby/2.7.0/net/http.rb:1483:in `request'
/usr/local/lib/site_ruby/mail_receiver/discourse_mail_receiver.rb:43:in `process'
/usr/local/bin/receive-mail:13:in `<main>'Dec 21 22:42:23 forum-mail-receiver postfix/pipe[140]: 16DAC379E42: to=<nobody@forum.[domain].co.nz>, relay=discourse, delay=60, delays=0.23/0.01/0/60, dsn=4.3.0, status=deferred (temporary failure)
Dec 21 22:42:25 forum-mail-receiver postfix/smtpd[143]: disconnect from mail-oa1-f50.google.com[209.85.160.50] ehlo=2 starttls=1 mail=1 rcpt=1 bdat=1 quit=1 commands=7
<19>Dec 21 22:42:52 receive-mail[147]: Failed to POST the e-mail to https://forum.[domain].co.nz/admin/email/handle_mail: execution expired (Net::OpenTimeout)<19>Dec 21 22:42:52 receive-mail[147]: /usr/lib/ruby/2.7.0/net/http.rb:960:in `initialize'
/usr/lib/ruby/2.7.0/net/http.rb:960:in `open'
/usr/lib/ruby/2.7.0/net/http.rb:960:in `block in connect'
/usr/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
/usr/lib/ruby/2.7.0/net/http.rb:958:in `connect'
/usr/lib/ruby/2.7.0/net/http.rb:943:in `do_start'
/usr/lib/ruby/2.7.0/net/http.rb:932:in `start'
/usr/lib/ruby/2.7.0/net/http.rb:1483:in `request'
/usr/local/lib/site_ruby/mail_receiver/discourse_mail_receiver.rb:43:in `process'
/usr/local/bin/receive-mail:13:in `<main>'Dec 21 22:42:52 forum-mail-receiver postfix/pipe[146]: 2E445379E48: to=<nobody@forum.[domain].co.nz>, relay=discourse, delay=60, delays=0.15/0.01/0/60, dsn=4.3.0, status=deferred (temporary failure)
Dec 21 22:45:45 forum-mail-receiver postfix/anvil[135]: statistics: max connection rate 1/60s for (smtp:209.85.216.54) at Dec 21 22:41:21
Dec 21 22:45:45 forum-mail-receiver postfix/anvil[135]: statistics: max connection count 1 for (smtp:209.85.216.54) at Dec 21 22:41:21
Dec 21 22:45:45 forum-mail-receiver postfix/anvil[135]: statistics: max cache size 2 at Dec 21 22:41:50
Je suis vraiment bloqué maintenant, quelqu’un a-t-il une idée de ce qui pourrait causer cela ? 
Doh ! Oui. J’ai confondu le TLS et le https.
Cela ne fonctionne toujours pas du tout, aucun e-mail n’est transmis de mail-receiver à Discourse.
Puis-je “annuler” mail-receiver pour le remettre à zéro (le réinitialiser entièrement) et recommencer, dans l’espoir que cela fonctionne ?
Comment puis-je faire cela ?
Vous pouvez simplement modifier le fichier et reconstruire le conteneur de messagerie.
Merci pour l’astuce concernant le pare-feu ! J’ai également rencontré des problèmes similaires à ceux de @MathiasFoster, le conteneur mail-receiver ne parvenant pas à atteindre le site du forum dans le conteneur app. Un peu déroutant au début, puisque les conteneurs sont autorisés à écouter le monde extérieur sans problème.
J’utilise également Vultr comme fournisseur de VPS avec leur image système Ubuntu. Une combinaison des paramètres par défaut de l’image système et de Docker semble effectivement bloquer la communication entre les conteneurs.
Quoi qu’il en soit, dans mon cas, il a suffi d’autoriser le HTTPS sur l’hôte :
$ ufw allow https
Après cela, le mail-receiver a pu livrer le courrier comme prévu.