Mise à jour du mail-receiver auto-hébergé suite au changement de certificat racine de Let's Encrypt

Cette annonce ne concerne que les utilisateurs en auto-hébergement qui exécutent Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver. Les clients de l’hébergement géré et les auto-hébergeurs utilisant POP3 pour la réception des courriels ne sont pas concernés.

Comme vous le savez probablement, Let’s Encrypt a récemment modifié son certificat racine. L’ancien certificat racine a expiré aujourd’hui, ce qui a causé de nombreux problèmes pour les clients obsolètes sur le web. Tous nos systèmes chez CDCK sont à jour et n’ont pas été affectés par l’expiration d’aujourd’hui. Malheureusement, nous avons manqué l’image Docker publique du récepteur de courriels, qui n’a pas été mise à jour depuis plusieurs mois.

Cela signifie que les installations existantes de récepteur de courriels en auto-hébergement ne pourront plus livrer de courriels vers les sites sécurisés par Let’s Encrypt.

Nous venons de publier une version mise à jour sur DockerHub, qui inclut le nouveau certificat racine. Si vous avez suivi les instructions officielles d’installation, vous pouvez mettre à jour votre installation en exécutant :

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

Les courriels reçus par des installations défectueuses auront été temporairement mis en file d’attente sur le serveur d’envoi. Ces serveurs devraient tenter de livrer à nouveau les courriels périodiquement, de sorte que tous les courriels manqués devraient arriver peu de temps après la mise à jour de l’image.

Si vous rencontrez toujours des problèmes après avoir suivi ces étapes, assurez-vous d’exécuter la version release du récepteur de courriels. Vous trouverez des informations à ce sujet dans ce sujet.

Désolé pour ce désagrément ! Un grand merci à @wlandgraf pour avoir initialement signalé le problème et pour nous avoir aidés à tester la correction :heart:

28 « J'aime »

Merci pour la correction ! Ma mise à jour s’est bloquée avec le message d’erreur suivant. Je n’ai apporté aucune modification à ce modèle, alors je ne sais pas quoi faire ?

root@ba /var/discourse # ./launcher rebuild mail-receiver
Assurer que le lanceur est à jour
Récupération de l'origine
Mise à jour du lanceur...
Mise à jour de 46d899f..990519e
erreur : Vos modifications locales sur les fichiers suivants seraient écrasées par la fusion :
	templates/web.letsencrypt.ssl.template.yml
Veuillez valider vos modifications ou les mettre en réserve avant de fusionner.
Annulation
échec de la mise à jour
1 « J'aime »

Que se passe-t-il si vous exécutez :

cd /var/discourse
git diff

Affiche-t-il des différences dans le fichier web.letsencrypt.ssl.template.yml ?

Si oui, vous pouvez les réinitialiser en utilisant git reset --hard.

3 « J'aime »

Ah, j’ai effectivement fait une modification :innocent: J’ai réussi à le mettre à niveau maintenant, merci !

2 « J'aime »

Vous pouvez vérifier si vous exécutez l’ancien mail-receiver de la manière suivante.

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

Si c’est Alpine, il s’agit de l’ancienne version.

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

Si c’est Debian, il s’agit de la nouvelle version.

7 « J'aime »

@david, pourrais-tu jeter un coup d’œil aux problèmes ci-dessous ? La dernière mise à jour du mail-receiver a supprimé la possibilité de mettre en œuvre des mesures anti-spam supplémentaires, qui fonctionnaient à merveille dans la version précédente. En conséquence, mon forum subit à nouveau une pression croissante de spam à cause de ce dernier changement.

J’ai essayé de comprendre la cause racine, mais je ne maîtrise pas suffisamment Postfix pour y parvenir. J’ai trouvé des rapports similaires (client=unknown même lorsque l’enregistrement PTR existe dans DNS) concernant Postfix dans un jail chroot, ce qui pourrait donc être lié. De plus, les outils dnsutils semblent manquer dans la nouvelle image Debian du mail-receiver, mais leur installation ne résout toujours pas le problème ?

Celui-ci devrait être facile à corriger :

4 « J'aime »

@david Merci pour cette correction ! Je viens de l’exécuter et je vois que ça fonctionne. :+1:

Y a-t-il un moyen de voir quels e-mails n’ont pas pu être livrés depuis le 1er octobre ?

J’ai essayé ceci, mais je ne vois que 5 requêtes (la plus ancienne a été reçue le 26 novembre) :

/var/discourse/launcher enter mail-receiver
mailq

J’ai aussi essayé de regarder les logs, mais je n’ai obtenu que l’avertissement signalé ici :

3 « J'aime »

Je pense que tout ce qui n’est pas encore dans la file d’attente aurait dû être renvoyé à l’expéditeur. Je crains de ne pas savoir si le conteneur a des journaux qui remontent plus loin que ce que vous avez trouvé.

4 « J'aime »

L’ajout de pull_image après la ligne 657 résoudrait-il simplement le besoin de tirer explicitement l’image avant la reconstruction ? C’est-à-dire :

  # Si l'image en cours d'amorçage n'est pas l'image de base de Discourse
  if [[ ! X"" = X"$base_image" ]]; then
    image=$base_image
    # Tenter de mettre à jour l'image
    pull_image
  fi

Cela provoquera un docker pull $image à chaque fois lors d’un amorçage/reconstruction d’un conteneur avec base_image défini dans son fichier yml. Je ne pense pas que cela nuise au récepteur de courrier s’il est déjà à jour, mais je ne suis pas sûr s’il existe d’autres situations où cela pourrait poser problème.

2 « J'aime »

Oui, un pull inconditionnel a probablement du sens ici. C’est un peu étrange qu’il ne s’applique qu’à notre image de base principale pour le moment. Qu’en pensez-vous @Falco ?

2 « J'aime »

J’aimerais connaître une réponse définitive à cette question :slight_smile:

1 « J'aime »

Je pense que vous pouvez le voir en interrogeant la table postgres incoming_emails

2 « J'aime »

Malheureusement, cela ne montre rien pour la période pertinente (octobre 2021 à février 2022).

Y aurait-il des journaux dans le conteneur mail-receiver lui-même ?

1 « J'aime »