Mail-receiver non consegnerà la posta a Discourse

Ho commesso questo errore e ho lasciato discourse.example.com nel file mail-receiver.yml.

Ora l’ho corretto, ma sembra che mail-receiver non stia “ricevendo” i nuovi dettagli.
Come posso “resettare” mail-receiver (ad esempio, qual è il comando equivalente a ./launcher rebuild app?).

Modifica: Non ho letto attentamente il post precedente, il comando è ./launcher rebuild mail_receiver.

1 Mi Piace

Sto riscontrando un ulteriore problema ora in cui mail-receiver non consegna la posta a Discourse — ho provato a cercare aiuto, ma senza successo.

Log:

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:16:20 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)

Qualche idea su cosa potrebbe causare questo?

Il file mail-receiver.yml è valido e ho controllato la presenza di errori di battitura:

Questa è l’ambito della mia chiave API:

La posta arriva a mail-receiver, ma rimane in mailq:

In alternativa, c’è un modo per eliminare completamente il container mail-receiver e ricominciare da capo?

Il problema potrebbe essere che non hai impostato la chiave API

Grazie per la risposta @pfaffman… è sicuramente impostato nel mio file di configurazione mail-receiver.yml. Dovrebbe essere tra virgolette?

 (Net::OpenTimeout)

Questo è il tuo problema. Il ricevitore di posta non riesce ad accedere all’URL del tuo forum. Quindi o ne hai uno sbagliato in qualche modo o c’è qualche problema di rete in docker tra il ricevitore di posta e il tuo forum, credo.

Come posso risolvere ulteriormente il problema?

ping forum.[mydomain].co.nz

da mailq mostra:

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

e così via, mostrando che una connessione ha successo.
forum.[mydomain].co.nz è dove è ospitato il forum e questo stesso URL viene utilizzato in MAIL_DOMAIN e DISCOURSE_MAIL_ENDPOINT.

Guardando più da vicino le impostazioni di mail-receiver.yml, mi mancano le virgolette o https:// ovunque dove dovrebbero esserci?

## questo è il modello del container del ricevitore di posta
##
## Dopo aver apportato modifiche a questo file, DEVI ricompilare
## /var/discourse/launcher rebuild mail-receiver
##
## FAI MOLTA ATTENZIONE QUANDO MODIFICHI!
## I FILE YAML SONO SUPER SUPER SENSIBILI A ERRORI DI SPAZIATURA O ALLINEAMENTO!
## visita http://www.yamllint.com/ per convalidare questo file secondo necessità

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

  ## Dove la posta al tuo forum dovrebbe essere inviata. In generale, va benissimo
  ## usare lo stesso dominio del forum stesso qui.
  MAIL_DOMAIN: forum.[domain].co.nz
# commenta queste (e il volume sottostante!) per supportare 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 del punto di ricezione della posta del tuo forum Discourse.
  ## Questo è semplicemente l'URL di base del tuo forum, con `/admin/email/handle_mail`
  ## aggiunto. Fai attenzione se stai eseguendo una configurazione in sottocartella -- in quel caso,
  ## l'URL deve includere la sottocartella!
  DISCOURSE_MAIL_ENDPOINT: 'https://forum.[domain].co.nz/admin/email/handle_mail'

  ## La chiave API master del tuo forum Discourse. Puoi ottenerla dalla
  ## scheda "API" del tuo pannello di amministrazione.
  DISCOURSE_API_KEY: 639[rest of API key]884ef

  ## Il nome utente da utilizzare per l'elaborazione della posta in arrivo. A meno che tu non abbia
  ## rinominato l'utente `system`, dovresti lasciarlo così com'è.
  DISCOURSE_API_USERNAME: system

volumes:
  - volume:
      host: /var/discourse/shared/mail-receiver/postfix-spool
      guest: /var/spool/postfix
# commenta per supportare TLS
#  - volume:
#      host: /var/discourse/shared/standalone/letsencrypt
#      guest: /letsencrypt

Stai eseguendo il ping all’interno del container, cioè dopo aver prima eseguito ./launcher enter mail-receiver?

Vale anche la pena notare che il ping (tipicamente ICMP) è diverso dal connettersi a http/https (TCP) e potrebbe comportarsi diversamente a seconda di molti fattori nella configurazione di rete.

Proverei a usare curl dopo essere entrato nel container per vedere se riesce a connettersi al tuo forum tramite https, ad esempio:

cd /var/discourse
./launcher enter mail-receiver
curl -v https://forum.[domain].co.nz

Se funziona, stamperà un sacco di HTML. Se non funziona, mostrerà un errore e -v farà stampare molte informazioni lungo il percorso che potrebbero aiutare a rivelare perché è fallito.

Se fallisce, vale anche la pena provare a eseguire lo stesso comando curl all’esterno del container per identificare se è specifico del container o del sistema host in generale.

3 Mi Piace

Grazie @Simon_Manning, il tuo aiuto è molto apprezzato! Non sapevo che le connessioni tramite ping non fossero necessariamente le stesse delle connessioni tramite curl.

Stavo eseguendo ping all’interno del container, ed è riuscito.

Ho seguito le tue istruzioni ed eseguito curl all’interno del container, ed è fallito:

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

Poi ho eseguito exit e poi di nuovo curl, e ho ottenuto:

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):
...and so on.

Sembra che sia specifico del container e non del sistema host, qualche idea?

Ho anche aperto un ticket di supporto con Vultr (provider VPS per questa istanza) per vedere se è un problema da parte loro!

Docker crea reti virtuali per i container e, in assenza di una specifica, i container utilizzeranno la rete predefinita. Questa rete predefinita non consente la comunicazione tra container.

Di solito questo va bene per mail-receiver perché il tuo container Discourse avrà la porta 443 esposta al di fuori di quella rete e quando mail-receiver tenterà di connettersi a 1.2.3.4, uscirà dalla rete Docker. Il sistema host (o una rete più esterna) si renderà conto che deve rientrare e finirà per entrare nel container Discourse dall’esterno.

Mi vengono in mente due possibilità. Una è che mail-receiver sia in qualche modo a conoscenza dell’IP del container Discourse durante la ricerca del nome di dominio e quindi venga bloccata una connessione intra-container. Penso che sia improbabile.

L’altra è che un firewall sul sistema host stia bloccando le connessioni dall’uscire da un container ed entrare in un altro. Vultr potrebbe utilizzare regole firewall predefinite che causano questo o ricordo anche vagamente che Docker installa alcune regole in UFW per impostazione predefinita, quindi ciò potrebbe essere correlato se viene utilizzato.

2 Mi Piace

Non puoi usare https perché non hai decommentato questi:

Ciò si applica solo al supporto TLS sul lato del server di posta, ovvero affinché altri server di posta possano recapitare e-mail a mail-receiver tramite TLS.

Vale la pena farlo poiché il container Discourse ha evidentemente un certificato ma non dovrebbe influire sulla connessione di mail-receiver a Discourse. Potenzialmente la ricostruzione potrebbe farlo se per caso correggesse qualcosa nella rete del container.

Grazie, ho decommentato quelle righe e la riga per il volume.

Il mio file mail-receiver.yml ora appare così:

root@forum:/var/discourse# cat containers/mail-receiver.yml
## questo è il template del container per la ricezione delle email in entrata
##
## Dopo aver apportato modifiche a questo file, DEVI ricostruire
## /var/discourse/launcher rebuild mail-receiver
##
## FAI *MOLTA* ATTENZIONE QUANDO MODIFICHI!
## I FILE YAML SONO ESTREMAMENTE SENSIBILI A ERRORI DI SPAZIATURA O ALLINEAMENTO!
## visita http://www.yamllint.com/ per validare questo file se necessario

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

  ## Dove le email per il tuo forum dovrebbero essere inviate. In generale, va benissimo
  ## usare lo stesso dominio del forum.
  MAIL_DOMAIN: forum.[domain].co.nz
# decommenta queste (e il volume sottostante!) per supportare 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 dell'endpoint di elaborazione delle email del tuo forum Discourse.
  ## Questo è semplicemente l'URL base del tuo forum, con `/admin/email/handle_mail`
  ## aggiunto. Fai attenzione se stai eseguendo una configurazione in sottocartella - in quel caso,
  ## l'URL deve includere la sottocartella!
  DISCOURSE_MAIL_ENDPOINT: 'https://forum.[domain].co.nz/admin/email/handle_mail'

  ## La chiave API master del tuo forum Discourse. Puoi ottenerla dalla
  ## scheda \"API\" del tuo pannello di amministrazione.
  DISCOURSE_API_KEY: '074[resto della chiave API - sì, ho generato una nuova chiave limitata all\'utente di sistema]d98'

  ## Il nome utente da utilizzare per l'elaborazione delle email in entrata. A meno che tu non abbia
  ## rinominato l'utente `system`, dovresti lasciarlo così com'è.
  DISCOURSE_API_USERNAME: system

volumes:
  - volume:
      host: /var/discourse/shared/mail-receiver/postfix-spool
      guest: /var/spool/postfix
# decommenta per supportare TLS
  - volume:
      host: /var/discourse/shared/standalone/letsencrypt
      guest: /letsencrypt

Quando invio una nuova email ed eseguo ./launcher logs mail-receiver, ecco cosa vedo:

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=<[il mio indirizzo email]>, size=5585, nrcpt=1 (queue active)

23Dec 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=<[il mio indirizzo email]>, size=4100, nrcpt=1 (queue active)

23Dec 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)

19Dec 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
  /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

19Dec 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
  /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

Sono davvero bloccato ora, qualcuno ha qualche idea su cosa potrebbe causare questo? :grinning_face_with_smiling_eyes:

Doh! Sì. Ho confuso TLS e https.

Questo ancora non funziona affatto, nessuna email viene passata da mail-receiver a Discourse.

Posso ‘annullare’ mail-receiver riportandolo all’inizio (resettarlo completamente) e ricominciare, nella speranza che funzioni?
Come posso fare?

Puoi semplicemente modificare il file e ricompilare il container della posta.

Grazie per il suggerimento sul firewall! Ho riscontrato anch’io problemi simili a quelli di @MathiasFoster, con il container mail-receiver che non riusciva a raggiungere il sito del forum nel container app. Un po’ sconcertante all’inizio, dato che ai container viene consentito di ascoltare il mondo esterno senza problemi.

Sto usando anche Vultr come provider di VPS con la loro immagine del sistema operativo Ubuntu. Una qualche combinazione delle impostazioni predefinite dell’immagine del sistema operativo più Docker sembra effettivamente bloccare la comunicazione tra i container.

Comunque, nel mio caso, è stato sufficiente consentire HTTPS sull’host:

$ ufw allow https

Dopodiché, il mail-receiver è stato in grado di recapitare la posta come previsto.

1 Mi Piace