Come si fa a creare una nuova definizione di container in quella directory!?
Eseguendo i comandi mostrati subito dopo quel testo. A rigor di termini, non stai creando il file in quella directory ma all’interno della sottodirectory containers, uguale a app.yml.
Grazie, all’inizio non sembravano funzionare, ma ora sono arrivato all’editor di testo con:
Sembra esserci un problema con questo, quando eseguo
./launcher logs mail-receiver
riporta discourse_base_url=https://discourse.example.com, invece del dominio specificato impostato nell’editor di testo.
Ho provato a ricostruire/rilanciare il bootstrap di mail-receiver ma non è cambiato al dominio corretto.
Ho un piccolo problema, potrei avere qualche consiglio!
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
poi…
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)
Ho anche provato…
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
e…
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
Sto trovando istruzioni online per fermare il container e uccidere il processo (processo 4400?)
È sicuro e risolverà il problema?
Devo (o dovrei, o non dovrei) cambiare la porta 25 in una porta diversa nel file mail-receiver.yml?
Forse hai installato postfix e devi rimuoverlo?
Non puoi cambiare la porta. Devi interrompere ciò che la sta utilizzando. Ucciderlo semplicemente non funzionerà perché al riavvio sarà una gara a vedere quale processo parte per primo.
È quello che stavo pensando anch’io. Non riesco a immaginare come sia finito lì, ma proverò a rimuoverlo. Altrimenti posso semplicemente usare Gmail che sembra funzionare benissimo.
Ho appena spostato il mio forum in un nuovo ambiente e di conseguenza ho reinstallato il ricevitore di posta. Sembra che sia una versione più recente di quella che avevo installato in precedenza. La configurazione YML è cambiata un po’ con DISCOURSE_BASE_URL che sostituisce DISCOURSE_MAIL_ENDPOINT. Il contenuto del file YML riflette il cambiamento ma le istruzioni in cima a questo thread necessitano di essere aggiornate.
Inoltre, quando ricevo un’email che viene respinta/rifiutata, ricevo i seguenti errori…
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
I messaggi validi sembrano essere gestiti correttamente. La versione precedente del ricevitore di posta non dava questi errori, per quanto ho potuto vedere dai file di log recenti. Ho fatto qualche ricerca e mi sono imbattuto in - https://blog.badgerops.net/smtp-socket-malformed-response-on-a-fips140-2-sytstem/
Aggiungere quanto segue al file mail-receiver.yml sembra risolvere il problema per me:
## Fix smtp errors
POSTCONF_smtp_tls_fingerprint_digest: sha256
POSTCONF_smtpd_tls_fingerprint_digest: sha256
Sto pubblicando un post per segnalare che abbiamo aggiunto il supporto DMARC al mail-receiver tramite un’immagine discourse/mail-receiver:with-dmarc. Si prega di fare riferimento a Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver nell’OP per maggiori dettagli.
2 messaggi sono stati uniti in un argomento esistente: Mail-receiver relay access denied
Volevo aggiungere qualcosa alla sezione Risoluzione dei problemi.
Mail-Receiver (consegna diretta) funzionava per diversi domini ma non riceveva messaggi dagli utenti Gmail. Non riuscivo a capire perché. Non c’era nulla nei log tranne una connessione/disconnessione da Google. Tutto sembrava a posto e gli strumenti online confermavano che il DNS andava bene.
Alla fine ho creato un record SMTP TLS report nel DNS, ad esempio:
_smtp._tls.discourse.mydomain.com TXT v=TLSRPTv1;rua=mailto:me@wherever.com
Qualche ora dopo, Google (Gmail) ha inviato un report che mostrava che aveva memorizzato nella cache una policy mta-sts che non rifletteva i record MX correnti. Ero preoccupato che Google avrebbe mantenuto quella policy memorizzata nella cache per una settimana perché sembrava aver ignorato il mio record DNS _mta-sts aggiornato che avrebbe dovuto causare un aggiornamento.
E poco dopo, tutta la mia posta Gmail di backup ha iniziato ad arrivare a Discourse senza che io facessi nulla. Il report mi ha aiutato a capire la prospettiva di Google sul problema e mi ha evitato di grattarmi la testa quando i messaggi hanno iniziato a fluire.
I report SMTP TLS vengono emessi infrequentemente, quindi sii paziente.
Dato che la guida non dice nulla sulla configurazione di MTA STS, l’aggiunta di passaggi diagnostici per questo non confonderebbe il 99,999%+ degli utenti che non lo configurano?
Nel mio caso, l’aggiunta di un singolo record DNS è stata sufficiente a far luce sul mio problema. Dato che la guida istruisce già sulla creazione di record DNS per l’installazione di Mail-Receiver, suggerire un record aggiuntivo nella sezione Risoluzione dei problemi come ultima risorsa non sembra un’esagerazione. Tuttavia, vedo che il tuo post ha due “mi piace” e il mio nessuno, quindi potrebbe essere la fine della questione.
Ottime notizie, queste sembrano informazioni utili da aggiungere alla guida, soprattutto perché Gmail è un mittente comune.
La guida istruisce sulla creazione di record DNS per far funzionare mail-receiver, non per configurare MTA STS. Quindi un utente che segue la guida non avrà mai il problema che hai avuto tu. Pertanto non è necessario complicare la guida con passaggi aggiuntivi e non necessari.
In generale, il ricevitore di posta è in grado di elaborare le email inviate da Gmail in nuovi argomenti?
Questo sembra un problema importante, ma non se la causa è un incidente isolato.
Sono giunto alla conclusione che Matt ha ragione. La mia installazione ha dovuto specificamente gestire MTA-STS perché la posta ordinaria del suo dominio è gestita da Mail In a Box https://mailinabox.email/ che insiste su una rigorosa policy MTA-STS e Gmail applica tale policy. Per impostazione predefinita, la policy potrebbe entrare in conflitto con la configurazione di Mail-Receiver. La maggior parte dei domini non avrà una policy. Se un dominio ha una policy, sarà visibile su
https://mydomain.com/.well-known/mta-sts.txt
La mia policy funzionante è la seguente…
version: STSv1
mode: none
mx: mail.mydomain.com
mx: discourse.mydomain.com
max_age: 86400
Spero di poter aggiornare “mode: none” a “mode: enforce” dopo un po’ più di lavoro.
Qualcuno potrebbe ricordarmi – quando ricostruiamo Discourse dalla riga di comando, ricostruisce automaticamente il container mail-receiver, o dobbiamo farlo separatamente? Grazie.
No, lo ricostruisce solo quando glielo dici. Non è necessario ricostruire spesso il mail receiver.
Mi ha decisamente aiutato ![]()
