Actualización del receptor de correo autohospedado tras el cambio en el certificado raíz de Let's Encrypt

Soporte Instalación
,
1

Este anuncio solo afecta a los que se autoalojan y ejecutan Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver. Los clientes de alojamiento gestionado y los que se autoalojan utilizando POP3 para el correo entrante no se ven afectados.

Como es posible que ya sepan, Let’s Encrypt recientemente cambió su certificado raíz. El antiguo certificado raíz venció hoy y ha causado varios problemas en clientes desactualizados en toda la web. Todos nuestros sistemas en CDCK están actualizados y no se vieron afectados por el vencimiento de hoy. Lamentablemente, nos olvidamos de la imagen pública del contenedor Docker para el receptor de correo, la cual no se ha actualizado desde hace unos meses.

Esto significa que las instalaciones existentes de mail-receiver autoalojadas no podrán entregar correo a sitios protegidos por Let’s Encrypt.

Acabamos de subir una versión actualizada a DockerHub, que incluye el nuevo certificado raíz. Si siguieron las instrucciones oficiales de instalación, pueden actualizar su instalación ejecutando:

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

Los correos recibidos por instalaciones rotas habrán quedado temporalmente en cola en el servidor de envío. Esos servidores deberían intentar reenviar el correo periódicamente, por lo que cualquier correo perdido debería llegar poco después de actualizar la imagen.

Si aún siguen viendo problemas después de seguir estos pasos, asegúrense de que están ejecutando la versión release de mail-receiver. Pueden encontrar información al respecto en este tema.

¡Lo sentimos por las molestias ocasionadas! Muchas gracias a @wlandgraf por informar inicialmente del problema y ayudarnos a probar la solución :heart:

28 Me gusta
2

¡Gracias por la corrección! Mi actualización se quedó atascada con el siguiente mensaje de error. No he realizado ningún cambio en esta plantilla, así que no sé qué hacer.

root@ba /var/discourse # ./launcher rebuild mail-receiver
Asegurando que el lanzador esté actualizado
Obteniendo origin
Actualizando el lanzador...
Actualizando 46d899f..990519e
error: Tus cambios locales en los siguientes archivos serían sobrescritos por la fusión:
	templates/web.letsencrypt.ssl.template.yml
Por favor, confirma tus cambios o guárdalos temporalmente antes de fusionar.
Abortando
actualización fallida
1 me gusta
3

¿Qué sucede si ejecutas

cd /var/discourse
git diff

¿Muestra alguna diferencia en el archivo web.letsencrypt.ssl.template.yml?

De ser así, puedes restablecerlas usando git reset --hard.

3 Me gusta
4

¡Ah, sí que hice un cambio :innocent:! Logré que se actualizara ahora, ¡gracias!

2 Me gusta
5

Puedes verificar si estás ejecutando la versión antigua de mail-receiver de la siguiente manera.

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

Si es Alpine, es la versión antigua.

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

Si es Debian, es la versión nueva.

7 Me gusta
6

@david, ¿podrías echar un vistazo a los problemas que se detallan a continuación? La última actualización del mail-receiver eliminó la posibilidad de implementar medidas adicionales contra el spam, las cuales funcionaban a la perfección en la versión anterior, y mi foro vuelve a estar bajo una presión de spam cada vez mayor debido a este último cambio.

Intenté averiguar cuál es el problema raíz, pero no tengo conocimientos suficientes de Postfix para resolverlo. Encontré informes similares (client=unknown incluso cuando existe un registro PTR en DNS) relacionados con Postfix en una cárcel chroot, por lo que esto podría tener algo que ver. Además, parece que las herramientas dnsutils faltan en la nueva imagen Debian del mail-receiver, pero instalarlas aún no soluciona el problema.

Este debería ser fácil de solucionar:

4 Me gusta
7

@david ¡Gracias por esta corrección! Acabo de ejecutarla y veo que está funcionando. :+1:

¿Hay alguna forma de ver qué correos electrónicos no pudieron ser entregados desde el 1 de octubre?

He intentado esto, pero solo veo 5 solicitudes (la más antigua se recibió el 26 de noviembre):

/var/discourse/launcher enter mail-receiver
mailq

También intenté mirar los registros, pero solo obtuve la advertencia informada aquí:

3 Me gusta
8

Creo que cualquier cosa que todavía no esté en la cola debería haber sido devuelta al remitente. Me temo que no estoy seguro de si el contenedor tiene algún registro que vaya más allá de lo que has encontrado.

4 Me gusta
9

¿Simplemente agregar pull_image después de la línea 657 resolvería la necesidad de extraer explícitamente la imagen antes de reconstruirla? Es decir:

  # Si la imagen que se está iniciando no es la imagen base de Discourse
  if [[ ! X"" = X"$base_image" ]]; then
    image=$base_image
    # Intenta actualizar la imagen
    pull_image
  fi

Esto provocará que siempre ocurra un docker pull $image durante el inicio/reconstrucción de un contenedor con base_image establecido en su archivo yml. No creo que eso perjudique a mail-receiver si resulta que ya está actualizado, pero no estoy seguro si hay otras situaciones en las que eso podría ser un problema.

2 Me gusta
10

Sí, un pull incondicional probablemente tenga sentido aquí. Es un poco extraño que solo se aplique a nuestra imagen base principal en este momento. ¿Qué opinas @Falco?

2 Me gusta
11

Me interesaría escuchar una respuesta definitiva a esta pregunta :slight_smile:

1 me gusta
12

Creo que puedes verlo consultando la tabla incoming_emails de postgres.

2 Me gusta
13

Lamentablemente, eso no muestra nada en el período de tiempo relevante (octubre de 2021 a febrero de 2022).

¿Habría algún registro en el propio contenedor del receptor de correo?

1 me gusta