Comment fait-on pour créer une nouvelle définition de conteneur dans ce répertoire !?
Configurer la réception des e-mails en livraison directe pour sites auto-hébergés avec Mail-Receiver
En exécutant les commandes présentées immédiatement après ce texte. Strictement parlant, vous ne créez pas le fichier dans ce répertoire mais à l’intérieur du sous-répertoire containers, tout comme app.yml.
3 « J'aime »
Merci, au début, ceux-ci ne semblaient pas fonctionner, mais j’ai maintenant accédé à l’éditeur de texte avec :
Il semble y avoir un problème avec cela, lors de l’exécution de
./launcher logs mail-receiver
il signale discourse_base_url=https://discourse.example.com, au lieu du domaine spécifié dans l’éditeur de texte.
J’ai essayé de reconstruire/relancer le bootstrap de mail-receiver mais le domaine correct n’a pas été modifié.
1 « J'aime »
J’ai un peu de mal, pourriez-vous me donner un conseil !
root@JEN /var/discourse # ./launcher start mail-receiver
x86_64 arch detected.
starting up existing container
+ /usr/bin/docker start mail-receiver
Error response from daemon: driver failed programming external connectivity on endpoint mail-receiver (721279d807e22a80580f2357fae40cc): Error starting userland proxy: listen tcp4 0.0.0.0:25: bind: address already in use
Error: failed to start containers: mail-receiver
puis…
root@JEN /var/discourse # sudo lsof -i tcp:25
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
master 4400 root 13u IPv4 24419 0t0 TCP *:smtp (LISTEN)
master 4400 root 14u IPv6 24420 0t0 TCP *:smtp (LISTEN)
J’ai aussi essayé…
root@JEN /var/discourse # netstat -nlp | grep 25
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 4400/master
tcp6 0 0 :::25 :::* LISTEN 4400/master
et…
root@JEN /var/discourse # ps j 4400
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
1 4400 4400 4400 ? -1 Ss 0 0:02 /usr/lib/postfix/sbin/master -w
Je trouve des instructions en ligne pour arrêter le conteneur et tuer le processus (processus 4400 ?)
Est-ce sûr, et cela corrigera-t-il le problème ?
Dois-je (ou devrais-je, ou ne devrais-je pas) changer le port 25 en un autre port dans le fichier mail-receiver.yml ?
1 « J'aime »
Peut-être avez-vous installé postfix et devez-vous le supprimer ?
Vous ne pouvez pas changer le port. Vous devez arrêter tout ce qui l’utilise. Le simple fait de le tuer ne fonctionnera pas car lorsque vous redémarrerez, ce sera une course pour voir quel processus démarre en premier.
3 « J'aime »
C’est ce que je pensais aussi. Je n’arrive pas à imaginer comment il a pu arriver là, mais je vais essayer de le retirer. Sinon, je peux juste utiliser Gmail, qui semble fonctionner parfaitement.
2 « J'aime »
J’ai déplacé mon forum vers un nouvel environnement et, par conséquent, j’ai réinstallé le récepteur d’e-mails. Il semble que ce soit une version plus récente que celle que j’avais installée précédemment. La configuration YML a légèrement changé, avec DISCOURSE_BASE_URL remplaçant DISCOURSE_MAIL_ENDPOINT. Le contenu du fichier YML reflète le changement, mais les instructions en haut de ce fil de discussion doivent être mises à jour.
De plus, lorsque je reçois un e-mail qui est rejeté/refusé, j’obtiens les erreurs suivantes…
Jun 08 11:50:42 mail-receiver postfix/smtp[117]: fatal: unknown service: smtp/tcp
Jun 08 11:50:42 mail-receiver postfix/smtp[118]: fatal: unknown service: smtp/tcp
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: private/smtp socket: malformed response
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: process /usr/lib/postfix/sbin/smtp pid 117 exit status 1
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: /usr/lib/postfix/sbin/smtp: bad command startup -- throttling
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: private/smtp socket: malformed response
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: process /usr/lib/postfix/sbin/smtp pid 118 exit status 1
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
Les messages valides semblent être traités correctement. La version précédente du récepteur d’e-mails ne donnait pas ces erreurs, d’après ce que j’ai pu voir dans les fichiers journaux récents. J’ai fait quelques recherches et j’ai trouvé - https://blog.badgerops.net/smtp-socket-malformed-response-on-a-fips140-2-sytstem/
L’ajout de ce qui suit au fichier mail-receiver.yml semble résoudre le problème pour moi :
## Fix smtp errors
POSTCONF_smtp_tls_fingerprint_digest: sha256
POSTCONF_smtpd_tls_fingerprint_digest: sha256
4 « J'aime »
Je dépose un message ici pour signaler que nous avons ajouté la prise en charge de DMARC au récepteur de courrier via une image discourse/mail-receiver:with-dmarc. Veuillez vous référer à Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver dans le premier message pour plus de détails.
3 « J'aime »
2 messages ont été fusionnées dans un sujet existant : Mail-receiver relay access denied
Je voulais ajouter quelque chose à la section Dépannage.
Mail-Receiver (livraison directe) fonctionnait pour plusieurs domaines, mais ne recevait pas de messages des utilisateurs de Gmail. Je n’arrivais pas à comprendre pourquoi. Il n’y avait rien dans les journaux, sauf une connexion/déconnexion de Google. Tout semblait bon et les outils en ligne confirmaient que le DNS était correct.
Finalement, j’ai créé un enregistrement de rapport SMTP TLS dans le DNS, par exemple :
_smtp._tls.discourse.mydomain.com TXT v=TLSRPTv1;rua=mailto:me@wherever.com
Quelques heures plus tard, Google (Gmail) a envoyé un rapport indiquant qu’il avait mis en cache une politique mta-sts qui ne reflétait pas les enregistrements MX actuels. J’étais inquiet que Google conserve cette politique mise en cache pendant une semaine, car il semblait avoir ignoré mon enregistrement DNS _mta-sts mis à jour qui aurait dû provoquer un rafraîchissement.
Et peu de temps après, tous mes e-mails Gmail sauvegardés ont commencé à arriver dans Discourse sans que je fasse quoi que ce soit. Le rapport m’a aidé à comprendre la perspective de Google sur le problème et m’a évité de me creuser la tête lorsque les messages ont commencé à arriver.
Les rapports SMTP TLS sont émis peu fréquemment, alors soyez patient.
3 « J'aime »
Étant donné que le guide ne dit rien sur la configuration de MTA STS, l’ajout d’étapes de diagnostic pour cela ne confondrait-il pas les 99,999 % et plus d’utilisateurs qui ne le configurent pas ?
2 « J'aime »
Dans mon cas, l’ajout d’un seul enregistrement DNS a suffi à éclaircir mon problème. Étant donné que le guide explique déjà la création d’enregistrements DNS pour l’installation de Mail-Receiver, suggérer un enregistrement supplémentaire dans la section Dépannage en dernier recours ne semble pas excessif. Cependant, je vois que votre publication a deux « j’aime » et la mienne n’en a aucun, donc cela pourrait être la fin de l’histoire.
1 « J'aime »
C’est une bonne nouvelle, cela semble être une bonne information à ajouter au guide, d’autant plus que Gmail est un expéditeur courant.
Le guide explique la création d’enregistrements DNS pour faire fonctionner mail-receiver, pas pour configurer MTA STS. Ainsi, un utilisateur qui suit le guide n’aura jamais le problème que vous avez rencontré. Il n’est donc pas nécessaire de compliquer le guide avec des étapes supplémentaires et inutiles.
1 « J'aime »
En général, le récepteur de courrier est-il capable de traiter les courriels envoyés par Gmail vers de nouveaux sujets ?
Cela semble être un problème majeur, mais pas si la cause est un incident isolé.
J’en suis arrivé à la conclusion que Matt a raison. Mon installation a spécifiquement dû gérer MTA-STS car le courrier régulier de son domaine est géré par Mail In a Box https://mailinabox.email/ qui insiste sur une politique MTA-STS stricte et Gmail applique cette politique. Par défaut, la politique pourrait entrer en conflit avec la configuration de Mail-Receiver. La plupart des domaines n’auront pas de politique. Si un domaine a une politique, elle sera visible à l’adresse
https://mydomain.com/.well-known/mta-sts.txt
Ma politique de travail ressemble à ceci…
version: STSv1
mode: none
mx: mail.mydomain.com
mx: discourse.mydomain.com
max_age: 86400
J’espère pouvoir passer de “mode: none” à “mode: enforce” après un peu plus de travail.
2 « J'aime »
Quelqu’un pourrait-il me rappeler – lorsque nous reconstruisons Discourse en ligne de commande, reconstruit-il automatiquement le conteneur mail-receiver, ou devons-nous le faire séparément ? Merci.
Non, il ne reconstruit que lorsque vous le lui dites. Vous n’avez pas besoin de reconstruire le récepteur de courrier souvent.
2 « J'aime »
Cela m’a vraiment aidé 
1 « J'aime »