Ha habido muchas actualizaciones recientemente. Una estropeó el asunto (ya no incluye la categoría) y ahora no sale ningún correo en absoluto. Los usuarios están muy descontentos. No sé por dónde empezar a depurar este problema. ¿Dónde puedo encontrar los registros de errores y recuerdo que hay alguna página sobre las colas de Sidekiq y demás, pero no la encuentro? Cualquier ayuda será muy apreciada.
Sí, he notado que las notificaciones por correo electrónico no parecen estar activándose en este momento después de una actualización ayer, aunque los resúmenes/digest todavía lo están. ¿Estamos solos en esto?
2 Me gusta
La causa de esto puede ser que Sidekiq no esté procesando los trabajos programados cuando debería.
Identificamos el mismo problema hoy en nuestros sitios de CD. Asegúrate de estar al menos en el commit:
(Creo que este es el commit, no estoy 100% seguro)
Para ver si el problema es el mismo, revisa los trabajos programados en /sidekiq y comprueba si hay alguno del pasado.
3 Me gusta
Sí, nos vimos afectados por eso. Una actualización lo ha solucionado.
2 Me gusta
4 publicaciones se dividieron en un nuevo tema: Email From: los encabezados perdieron su texto “vía NOMBRE_DEL_SITIO”
Confirmo cientos de trabajos de sidekiq fallidos en latest-release +103
corregido en latest-release +153
Estoy actualizado a la última versión y sigo teniendo un problema para enviar correos electrónicos en uno de mis sitios. Simplemente recibo un mensaje de error al enviar un correo electrónico de prueba.
ERROR - se alcanzó el final del archivo
Ahora estoy en el móvil, revisaré sidekiq y los registros cuando esté en mi computadora. ¿Alguna otra sugerencia sobre dónde buscar?
¡Hola Tobias!
Tu problema es diferente: la conexión se está quedando colgada esperando una respuesta poco después de la conexión inicial exitosa.
Me atrevería a adivinar que estás intentando usar el protocolo incorrecto en el puerto incorrecto… ¿qué configuración estás utilizando?
¿La tarea rake emails:test (con la lógica y los mensajes de error actualizados recientemente) muestra algún error diferente?
¡Hola Michael! Gracias por la respuesta. ¡Los extraño mucho! 
Mmm… Acabo de migrar mi sitio de DO a Hetzner y funcionó bien durante un par de semanas. Mi otro sitio también funciona bien. Es un acertijo. Dejó de funcionar hace aproximadamente una semana y cuando lo revisé vi los errores. Me comuniqué con Hetzner (se negaron a ayudar) y con Mailgun. Según Mailgun:
Gracias por su respuesta, el último evento autenticado aceptado que estamos viendo fue el 11 de enero y se envió a través de SMTP.
¿Puede confirmar si se han realizado cambios? Proporcione una captura de pantalla de la configuración de su aplicación de envío para nuestra revisión, así como cualquier error relevante en su aplicación de envío/registros de envío SMTP.
Acabo de cambiar mi contraseña de Mailgun por si acaso y lo intenté de nuevo, pero no funcionó.
Salida de rake emails:test:
root@ubuntu-4gb-nbg1-1-app:/var/www/discourse# rake emails:test
Probando el envío a través de smtp.mailgun.org:587, nombre de usuario: postmaster@domain con autenticación simple.
====================================================================================== ERROR =======================================================================================
¡ERROR DESCONOCIDO!
EOFError: fin de archivo alcanzado
===================================================================================== SOLUCIÓN =====================================================================================
Este no es un error común. ¡No existe una solución recomendada!
Por favor, informe el mensaje de error exacto anterior a https://meta.discourse.org/
(¡Y una solución, si encuentra una!)
====================================================================================================================================================================================
1 me gusta
Creo que está fallando antes incluso de intentar iniciar sesión.
Para eliminar Discourse como factor, intenta desde el host Y desde dentro del contenedor:
$ openssl s_client -connect smtp.mailgun.org:587 -starttls smtp
Deberías obtener una gran cantidad de salida y luego poder intentar autenticarte:
○ → openssl s_client -connect smtp.mailgun.org:587 -starttls smtp
Connecting to 34.160.63.108
CONNECTED(00000003)
…
SSL-Session:
…
---
read R BLOCK
EHLO localhost
250-2ed1d46f4d7dec773e2a97b59f3a3bf8a2d6db54f94eead5dcf49e3ea1caac18
250-AUTH PLAIN LOGIN
250-SIZE 52428800
250-8BITMIME
250-SMTPUTF8
250 PIPELINING
AUTH PLAIN bWljaGFlbABtaWNoYWVsAHBhc3N3b3Jk
501 Username used for auth is not valid email address
535 Authentication failed
closed
Las cadenas que escribirías son:
EHLO localhost
AUTH PLAIN bWljaGFlbABtaWNoYWVsAHBhc3N3b3Jk
(esa cadena son las credenciales michael/password, por lo que obviamente no funcionará, pero puedes ver esta publicación para aprender a construir la cadena para tus credenciales reales si quieres intentarlo manualmente)
Espero que ver de primera mano lo que funciona y lo que falla ayude.
También te recomiendo intentar usar swaks si está disponible; probablemente sea un paquete del sistema operativo que puedas instalar.
Es un poco más fácil y puedes, por ejemplo:
swaks --to frodo@shire.net --from bilbo@shire.net --auth PLAIN --auth-user bilbo --auth-password ring --server smtp.mailgun.org:587 --tls
excepto que puedes usar tus credenciales reales.
La salida de eso también podría ayudar a revelar el problema.
Intenté usar swaks y obtuve esto:
=== Trying smtp.mailgun.org:587...
=== Connected to smtp.mailgun.org.
*** Remote host closed connection unexpectedly.
Eso me inspiró a verificar desde mi otro servidor, donde swaks mostró “Great success” (¡Gran éxito!) - ¡el mensaje es bastante adorable!
<~ 250 Great success
~> QUIT
<~ 221 See you later. Yours truly, Mailgun
=== Connection closed with remote host.
Así que el problema es o bien que mailgun está bloqueando mi servidor, o mi servidor está de alguna manera mal configurado. Revisaré con mailgun y luego, si no es eso, destruiré y reconstruiré mi servidor.
1 me gusta
Tiene sentido; esto es esencialmente el mismo error que
Como sospechas, la causa más probable es que algo externo esté interfiriendo con la conexión.
1 me gusta
sospecho que necesitas usar el puerto 2525 en lugar de 587
Hetzner declara explícitamente que no bloquean el puerto 587.
Además, si lo hicieran, probablemente se mostraría como un fallo al establecer una conexión.
Eso casi descarta la configuración de Discourse y Mailgun.
En este punto, el diagnóstico más útil es probar un puerto de envío alternativo de Mailgun desde el servidor afectado:
openssl s_client -connect smtp.mailgun.org:2525 -starttls smtp
(o la misma prueba con swaks).
Mailgun admite 2525 específicamente para entornos donde 587 se ve interferido por firewalls, filtrado de salida o reglas de red a nivel de proveedor.
Si:
- 2525 funciona y 587 no → muy probablemente interferencia de red / IP / enrutamiento
- ambos fallan → caso aún más sólido de que algo externo está bloqueando o terminando la conexión
En cualquier caso, el comportamiento coincide mucho más con la “interferencia de conexión externa” que con una regresión de Discourse o Sidekiq.
Aún no he tenido noticias de Mailgun… mi plan, si no pueden ayudar, es empezar de nuevo con un nuevo servidor Hetzner.
Probé swaks con otros puertos y, curiosamente, obtuve el mismo error con 2525, e inmediatamente sin ninguna demora.
=== Intentando smtp.mailgun.org:2525...
=== Conectado a smtp.mailgun.org.
*** El host remoto cerró la conexión inesperadamente.
Pero obtuve un error diferente con 25 y 465, y tardó algunos segundos en llegar la respuesta.
=== Intentando smtp.mailgun.org:25...
*** Error al conectar con smtp.mailgun.org:25:
*** Tiempo de espera agotado para la conexión
=== Intentando smtp.mailgun.org:465...
*** Error al conectar con smtp.mailgun.org:465:
*** Tiempo de espera agotado para la conexión
No estoy seguro de qué pensar sobre eso. Tal vez haya un firewall mal configurado en el servidor bloqueando algunos puertos.
eso es intencional y esperado.
Hetzner bloquea esos puertos por defecto.
1 me gusta
Tiene sentido… pero es interesante que los puertos 25 y 465 tardaran más en fallar que los otros. De todos modos, esto no es urgente y esperaré a tener noticias de Mailgun. Es para mi sitio familiar, así que solo estoy animando a todos a iniciar sesión y comprobar si hay notificaciones por si acaso, ¡y no solo a esperar el correo electrónico!
Mañana viajo a Alemania para visitar a la familia y asistir a un funeral… la próxima semana volveré a revisar esto y probablemente empezaré de nuevo con un servidor nuevo.
¡Gracias por toda la orientación! Aprendí mucho durante este proceso. Realmente me gusta esa herramienta swaks.
El tiempo puede ser información útil, en efecto.
Cuando un puerto (más generalmente, el tráfico) está bloqueado, puede estar bloqueado mediante descarte (rechazo silencioso) o rechazo (se envía un mensaje de “inalcanzable” (por ejemplo, puerto inalcanzable) de vuelta al emisor).
Un descarte silencioso es lo que ves con 25/465: se realiza un intento de conexión y no sucede nada hasta que se alcanza el tiempo de espera.
Un rechazo provoca un mensaje como “Conexión rechazada” o “Puerto inalcanzable”.
Eso es indicativo de un comportamiento intencionado: estás obteniendo una conexión y luego la conexión se cierra inmediatamente.
Has variado el origen, así que algo más que puedes intentar es variar el destino. Intenta el mismo comando contra, por ejemplo, smtp.gmail.com o smtp.office365.com. Deberías obtener un error de autenticación, y esa es una fuerte indicación de que es mailgun quien te está rechazando específicamente.
1 me gusta
Esa explicación de @supermathie es totalmente acertada 
La diferencia de tiempo es en realidad una señal útil, no ruido.
Para resumir lo que estás viendo:
- 25 de 465 se agotan → caída silenciosa (bloqueo a nivel de política de Hetzner, esperado)
- 2525 se conectan y luego cierran inmediatamente → la ruta TCP está bien, pero el lado remoto está terminando la sesión
Ese último es el detalle clave.
Porque:
- el handshake TCP tiene éxito
- la negociación TLS nunca comienza realmente
- y sucede instantáneamente
…sugiere fuertemente que Mailgun está rechazando la conexión temprano, no Discourse, Sidekiq o Ruby.
Esto coincide con algunas cosas que hemos visto recientemente:
- reputación de IP / filtrado basado en la región
- nuevos rangos de IP de Hetzner aún no son de confianza
- o comprobaciones de política del lado de Mailgun antes del intercambio de banner SMTP
Nada en Discourse causaría un cierre de socket remoto inmediato como ese; Sidekiq simplemente entrega el mensaje a Net::SMTP y espera.
Si quieres una confirmación más muy sólida más tarde (sin urgencia en absoluto):
openssl s_client -connect smtp.gmail.com:587 -starttls smtp
Deberías obtener un banner SMTP adecuado y luego un fallo de autenticación, lo que básicamente demostraría que el SMTP saliente en sí está bien y que Mailgun es el único endpoint que se comporta de manera diferente.
Y entiendo completamente pausar esto, especialmente dadas las circunstancias.
Lamento mucho que estés lidiando con eso además de todo lo demás 
Si Mailgun responde con algo útil, genial, pero honestamente, empezar de nuevo o cambiar de proveedor (Brevo, Postmark, etc.) suele ser más rápido que esperar a que se solucionen los problemas de reputación de SMTP.
Ya has depurado esto exactamente de la manera correcta: nada aquí sugiere que te hayas perdido algo o que hayas configurado mal Discourse.
Buen viaje a Alemania y cuídate.
1 me gusta