Aggiornamento del mail-receiver self-hosted a seguito del cambiamento del certificato root Let's Encrypt

Supporto Installazione
,
1

Questa annuncio riguarda esclusivamente gli utenti self-hosted che stanno eseguendo Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver. I clienti con hosting gestito e gli utenti self-hosted che utilizzano POP3 per la posta in arrivo non sono interessati.

Come probabilmente sapete, Let’s Encrypt ha recentemente modificato il proprio certificato radice. Il vecchio certificato radice è scaduto oggi, causando diversi problemi per i client obsoleti su tutto il web. Tutti i nostri sistemi presso CDCK sono aggiornati e non sono stati influenzati dalla scadenza di oggi. Purtroppo, abbiamo trascurato l’immagine Docker del ricevitore di posta pubblica, che non viene aggiornata da alcuni mesi.

Ciò significa che le installazioni esistenti del ricevitore di posta self-hosted non potranno più consegnare la posta ai siti protetti da Let’s Encrypt.

Abbiamo appena pubblicato una versione aggiornata su DockerHub, che include il nuovo certificato radice. Se hai seguito le istruzioni ufficiali di installazione, puoi aggiornare la tua esecuzione eseguendo:

docker pull discourse/mail-receiver:release
cd /var/discourse
./launcher rebuild mail-receiver

Le email ricevute da installazioni non funzionanti sono state temporaneamente accodate sul server di invio. Tali server dovrebbero tentare di ritrasmettere la posta periodicamente, quindi eventuali email perse dovrebbero arrivare poco dopo l’aggiornamento dell’immagine.

Se continui a riscontrare problemi dopo aver seguito questi passaggi, assicurati di eseguire la versione release del ricevitore di posta. Puoi trovare informazioni a riguardo in questo argomento.

Ci scusiamo per il disagio causato! Un grande ringraziamento a @wlandgraf per aver inizialmente segnalato il problema e per averci aiutato a testare la soluzione :heart:

28 Mi Piace
2

Grazie per la correzione! Il mio aggiornamento si è bloccato con il seguente messaggio di errore. Non ho apportato modifiche a questo modello, quindi non sono sicuro di cosa fare?

root@ba /var/discourse # ./launcher rebuild mail-receiver
Assicurazione che il launcher sia aggiornato
Recupero di origin
Aggiornamento del Launcher...
Aggiornamento di 46d899f..990519e
errore: Le tue modifiche locali ai seguenti file verrebbero sovrascritte dall'unione:
	templates/web.letsencrypt.ssl.template.yml
Effettua il commit delle tue modifiche o mettile in stash prima di eseguire l'unione.
Interrompo
aggiornamento fallito
1 Mi Piace
3

Cosa succede se esegui

cd /var/discourse
git diff

Vengono mostrate differenze nel file web.letsencrypt.ssl.template.yml?

In tal caso, puoi reimpostarle usando git reset --hard

3 Mi Piace
4

Ah, ho davvero apportato una modifica :innocent: Sono riuscito ad aggiornarlo ora, grazie!

2 Mi Piace
5

Puoi verificare se stai eseguendo il vecchio mail-receiver in questo modo.

docker exec mail-receiver bash -c "cat /etc/issue|grep Alpine"

Se è Alpine, si tratta della versione vecchia.

docker exec mail-receiver bash -c "cat /etc/issue|grep 'Debian GNU/Linux 11'"

Se è Debian, si tratta della versione nuova.

7 Mi Piace
6

@david, ti dispiacerebbe dare un’occhiata ai problemi riportati di seguito? L’ultimo aggiornamento del mail-receiver ha rimosso la possibilità di implementare ulteriori misure anti-spam, che funzionavano splendidamente nella versione precedente, e il mio forum è di nuovo sotto crescente pressione di spam a causa dell’ultimo cambiamento.

Ho provato a capire qual è il problema alla radice, ma non ho conoscenze abbastanza approfondite di postfix per risolverlo. Ho trovato rapporti simili (client=unknown anche quando il record PTR esiste nel DNS) riguardo a postfix in una gabbia chroot, quindi potrebbe avere a che fare con questo. Inoltre, sembra che dnsutils manchino dalla nuova immagine Debian del mail-receiver, ma installarli non risolve comunque il problema?

Questo dovrebbe essere risolto facilmente:

4 Mi Piace
7

@david Grazie per questa correzione! L’ho appena eseguita e vedo che funziona. :+1:

C’è un modo per vedere quali email non sono state recapitate dal 1° ottobre?

Ho provato questo, ma vedo solo 5 richieste (la più vecchia è stata ricevuta il 26 novembre):

/var/discourse/launcher enter mail-receiver
mailq

Ho anche provato a guardare nei log, ma ho ottenuto solo l’avviso segnalato qui:

3 Mi Piace
8

Penso che qualsiasi cosa non sia ancora in coda dovrebbe essere stata respinta al mittente. Temo di non essere sicuro se il container abbia dei log che risalgano più indietro di quanto hai trovato.

4 Mi Piace
9

L’aggiunta di pull_image dopo la riga 657 risolverebbe la necessità di eseguire esplicitamente il pull dell’immagine prima della ricostruzione? Ad esempio:

  # Se l'immagine che viene avviata non è l'immagine base di Discourse
  if [[ ! X"" = X"$base_image" ]]; then
    image=$base_image
    # Tenta di aggiornare l'immagine
    pull_image
  fi

Ciò causerà sempre un docker pull $image durante un bootstrap/ricostruzione di un container con base_image impostato nel suo file yml. Non credo che ciò possa causare problemi per mail-receiver se dovesse già essere aggiornato, ma non sono sicuro se ci siano altre situazioni in cui ciò potrebbe essere un problema.

2 Mi Piace
10

Sì, un pull incondizionato ha probabilmente senso qui. È un po’ strano che al momento si applichi solo alla nostra immagine di base principale. Cosa ne pensi @Falco?

2 Mi Piace
11

Sarei interessato a sentire una risposta definitiva a questa domanda :slight_smile:

1 Mi Piace
12

Penso che tu possa vederlo interrogando la tabella postgres incoming_emails

2 Mi Piace
13

Sfortunatamente, ciò non mostra nulla nel periodo di tempo pertinente (da ottobre 2021 a febbraio 2022).

Ci sarebbero dei log nel container mail-receiver stesso?

1 Mi Piace