Los correos electrónicos han dejado de enviarse: se ha alcanzado el final del archivo

Soporte
1

Hola a todos, y disculpas si esto es similar a algunas de las otras publicaciones que mencionan este error.

Durante los últimos cuatro días, todos los correos electrónicos han dejado de enviarse, y el correo de prueba también falla.

He revisado temas existentes que son similares, pero en mi caso, nada (que yo sepa) ha cambiado, y el correo dejó de funcionar después de haber funcionado durante meses sin problemas.

Estamos utilizando alojamiento en Digital Ocean y usamos el relay SMTP de G Suite configurado para retransmitir correos desde la dirección IP del droplet.

El error exacto que aparece en Sidekiq es un poco más detallado que lo que obtengo con discourse-doctor.

Jobs::HandledExceptionWrapper: Wrapped EOFError: end of file reached

discourse-doctor simplemente dice: UNEXPECTED ERROR: end of file reached

También pude confirmar la conexión al servidor con:

telnet smtp-relay.gmail.com 587

Recuerdo que hubo otro breve fallo hace muchos meses en el que los correos dejaron de enviarse, pero no recuerdo el error (en ese momento pude reintentar desde Sidekiq sin ningún problema).

¿Alguien ha experimentado algo similar o tiene una configuración parecida que siga funcionando? ¡Gracias de antemano!

2

Aún no tengo ningún consejo útil, pero he encontrado exactamente el mismo problema con la misma configuración: un droplet de DigitalOcean enviando correos a través de smtp-relay.gmail.com y recibiendo errores EOF.

Sidekiq informa lo siguiente:

Jobs::HandledExceptionWrapper: Wrapped EOFError: end of file reached

Al revisar los registros en /logs, obtengo un rastreo de la falla, pero nada que destaque inmediatamente como útil.

Información:

Job exception: end of file reached

Rastreo:

/usr/local/lib/ruby/2.7.0/net/protocol.rb:225:in `rbuf_fill'
/usr/local/lib/ruby/2.7.0/net/protocol.rb:191:in `readuntil'
/usr/local/lib/ruby/2.7.0/net/protocol.rb:201:in `readline'
/usr/local/lib/ruby/2.7.0/net/smtp.rb:944:in `recv_response'
/usr/local/lib/ruby/2.7.0/net/smtp.rb:929:in `block in getok'
/usr/local/lib/ruby/2.7.0/net/smtp.rb:954:in `critical'
/usr/local/lib/ruby/2.7.0/net/smtp.rb:927:in `getok'
/usr/local/lib/ruby/2.7.0/net/smtp.rb:826:in `helo'
/usr/local/lib/ruby/2.7.0/net/smtp.rb:600:in `do_helo'
/usr/local/lib/ruby/2.7.0/net/smtp.rb:554:in `do_start'
/usr/local/lib/ruby/2.7.0/net/smtp.rb:518:in `start'
mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session'
mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
mail-2.7.1/lib/mail/message.rb:2159:in `do_delivery'
mail-2.7.1/lib/mail/message.rb:260:in `block in deliver'
actionmailer-6.0.3.3/lib/action_mailer/base.rb:589:in `block in deliver_mail'
activesupport-6.0.3.3/lib/active_support/notifications.rb:180:in `block in instrument'
activesupport-6.0.3.3/lib/active_support/notifications/instrumenter.rb:24:in `instrument'
activesupport-6.0.3.3/lib/active_support/notifications.rb:180:in `instrument'
actionmailer-6.0.3.3/lib/action_mailer/base.rb:587:in `deliver_mail'
mail-2.7.1/lib/mail/message.rb:260:in `deliver'
actionmailer-6.0.3.3/lib/action_mailer/message_delivery.rb:115:in `block in deliver_now'
actionmailer-6.0.3.3/lib/action_mailer/rescuable.rb:17:in `handle_exceptions'
actionmailer-6.0.3.3/lib/action_mailer/message_delivery.rb:114:in `deliver_now'
/var/www/discourse/lib/email/sender.rb:234:in `send'
/var/www/discourse/app/jobs/regular/user_email.rb:70:in `send_user_email'
/var/www/discourse/app/jobs/regular/user_email.rb:25:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
rails_multisite-2.5.0/lib/rails_multisite/connection_management.rb:76:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
sidekiq-6.1.2/lib/sidekiq/processor.rb:196:in `execute_job'
sidekiq-6.1.2/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:143:in `invoke'
sidekiq-6.1.2/lib/sidekiq/processor.rb:163:in `block in process'
sidekiq-6.1.2/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.1.2/lib/sidekiq/job_retry.rb:111:in `local'
sidekiq-6.1.2/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.1.2/lib/sidekiq.rb:38:in `block in <module:Sidekiq>'
sidekiq-6.1.2/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.1.2/lib/sidekiq/processor.rb:257:in `stats'
sidekiq-6.1.2/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.1.2/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.1.2/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.1.2/lib/sidekiq/job_retry.rb:78:in `global'
sidekiq-6.1.2/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.1.2/lib/sidekiq/logger.rb:10:in `with'
sidekiq-6.1.2/lib/sidekiq/job_logger.rb:33:in `prepare'
sidekiq-6.1.2/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.1.2/lib/sidekiq/processor.rb:162:in `process'
sidekiq-6.1.2/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.1.2/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.1.2/lib/sidekiq/util.rb:15:in `watchdog'
sidekiq-6.1.2/lib/sidekiq/util.rb:24:in `block in safe_thread'

Entorno:

hostname	conversation-app
process_id	736
application_version	e6bbe9b5df4d86fe711aa8b1d886489d30875633
current_db	default
current_hostname	conversation.sevarg.net
job	Jobs::UserEmail
problem_db	default
time	12:42 pm
opts	
type	digest
user_id	30
current_site_id	default

discourse-doctor muestra una salida general similar:

==================== PRUEBA DE CORREO ====================
Para una prueba robusta, obtén una dirección en http://www.mail-tester.com/
O simplemente envía un mensaje de prueba a ti mismo.
¿Dirección de correo para la prueba? ('n' para omitir) [[mi correo]]: 
Enviando correo a [mi correo]... 
Probando el envío a [mi correo] usando smtp-relay.gmail.com:587.
======================================== ERROR ========================================
                                    ERROR INESPERADO

end of file reached

====================================== SOLUCIÓN =======================================
Este no es un error común. ¡No existe una solución recomendada!

Por favor, reporta el mensaje de error exacto anterior en https://meta.discourse.org/
(¡Y una solución si la encuentras!)
=======================================================================================

También puedo hacer telnet al relay en el puerto 587 (y enviar un mensaje de prueba manualmente, ¡no había hecho eso en una década…) y no he cambiado nada que pueda recordar en la historia reciente que haya afectado el correo.

Estoy completamente estancado en cuanto a nuevos usuarios y demás, lo cual es un problema ya que también lo estoy utilizando para comentarios de blog. No he encontrado nada en los registros de Google que sea especialmente útil, y ya se me han agotado las ideas para continuar con la solución de problemas. Todo parece estar configurado correctamente, pero simplemente ya no funciona.}

3

Bueno, es definitivamente un alivio saber que mi configuración no es demasiado inusual y que no estoy solo en mis problemas. Curioso, ¿el problema comenzó hace unos 5 días para ti también? Tal vez hubo una actualización de algo común en nuestros flujos de trabajo.

Gracias por compartir los detalles y el rastreo de la pila. Los míos eran muy similares a los tuyos, y los errores eran idénticos.

No intenté enviar manualmente un correo electrónico desde telnet, pero sospecho que funcionaría como lo hizo para ti.

Estoy en la misma situación, y estamos activando manualmente a los nuevos usuarios por el momento (afortunadamente, son solo unos pocos cada día). Considerando que no había cambiado nada en G Suite, Digital Ocean o la configuración de Discourse, soy reacio a empezar a cambiar cosas sin poder reducir qué es lo que realmente está causando el problema. :confused:

4

El primer pico real de fallos en Sidekiq fue el 14 de enero, así que… hace 5 días. Antes de eso, tuve algunos fallos aleatorios relacionados con correos electrónicos incorrectos o cosas por el estilo, pero nada que aumentara rápidamente.

Intenté recrear la configuración de retransmisión en la Consola de administración de Google y ajustarla (incluyendo lo que debería estar totalmente abierto), sin obtener cambios. También probé diferentes puertos para el envío de correo, sin cambios tampoco.

Además, no cambié nada de lo que tenga conocimiento hace 5 días. :confused:

5

Otro informe de problemas, DigitalOcean → smtp-relay.gmail.com

¿Alguien puede probar fácilmente desde una VM que no sea de DigitalOcean? ¿GCE o algo así?

6

Acabo de iniciar una instalación de Discourse en GCE con mis credenciales y obtuve el mismo error (habiendo configurado mi relay para depender únicamente de la autenticación).

======================================== ERROR ========================================
                                    ERROR INESPERADO

se alcanzó el final del archivo

====================================== SOLUCIÓN =======================================
Este no es un error común. ¡No existe una solución recomendada!

Por favor, informe el mensaje de error exacto anterior en https://meta.discourse.org/
(¡Y una solución, si la encuentra!)
=======================================================================================

Configurar la autenticación basada en IP para el relay dio los mismos resultados. Así que no creo que sea un problema específico de DigitalOcean…

Desafortunadamente, “Solución de problemas de correo electrónico en Ruby/Rails” está más allá de mis conocimientos actuales… ¿alguna sugerencia?

7

¿Hay alguna posibilidad de que esto sea un problema de SMTP de Gmail?

8

Parece que sí. No sé cómo solucionarlo, y mis intentos hasta ahora no han dado resultado. Probablemente hayan cambiado algo, Discourse no puede manejarlo y, por supuesto, no hay soporte.

9

Antes he tenido buena suerte en estos foros al ayudar a rastrear y resolver problemas. No sé por qué este está tan tranquilo.

10

Es posible que sea un problema con el SMTP de Gmail/G Suite, pero @Syonyk mencionó que pudo enviar un correo manualmente a través de telnet en su droplet.

No tengo suficiente experiencia para saber cómo G Suite podría interpretar el tráfico enviado desde el sitio en comparación con un mensaje enviado manualmente, pero eso parece indicar que el problema está en el servicio que envía el correo a smtp-relay.gmail, y no en el propio relay.

Por cierto, también tengo la dirección IP del droplet específicamente permitida en la configuración de administración de G Suite, y no he cambiado (ni he cambiado hasta ahora) ninguna configuración en ninguno de los servicios durante varios meses.

La única vez que vi algo similar suceder fue durante un día (quizás dos; no era una página muy activa en ese momento, así que probablemente no lo habría notado si hubiera durado más), pero pareció resolverse bastante rápido.

11

Sin un buen registro de la conversación SMTP de Discourse, no sé cómo seguir solucionando el problema, y tampoco sé cómo obtener esos registros.

12

¿Hay alguna manera de confirmar la cantidad de correos electrónicos que envío desde Discourse cada mes? Si necesito pasar a otro relay SMTP, necesitaría saber qué tipo de presupuesto requeriría. Esto es sumamente frustrante.

13

Bajo /admin/email/sent en tu instancia, deberías poder ver lo que se ha enviado y estimar el uso desde allí.

14

Hmm…

Lancé un tcpdump en el servidor y ejecuté discourse-doctor. Y encontré esto en la salida…

...
0x0030:  d10f f8e4 4548 4c4f 206c 6f63 616c 686f  ....EHLO.localho
	0x0040:  7374 0d0a                                st..
...
	0x0030:  de62 f0c3 3432 3120 342e 372e 3020 5472  .b..421.4.7.0.Tr
	0x0040:  7920 6167 6169 6e20 6c61 7465 722c 2063  y.again.later,.c
	0x0050:  6c6f 7369 6e67 2063 6f6e 6e65 6374 696f  losing.connectio
	0x0060:  6e2e 2028 4548 4c4f 2920 6a31 3673 6d34  n..(EHLO).j16sm4
	0x0070:  3831 3932 3976 736d 2e31 202d 2067 736d  81929vsm.1.-.gsm
	0x0080:  7470 0d0a                                tp..

Y, lo que es más importante, PUEDO reproducir este fallo con telnet.

root@conversation:~# telnet smtp-relay.gmail.com 587
Trying 74.125.137.28...
Connected to smtp-relay.gmail.com.
Escape character is '^]'.
220 smtp-relay.gmail.com ESMTP ls8sm507258pjb.6 - gsmtp
ehlo localhost.localdomain
421 4.7.0 Try again later, closing connection. (EHLO) ls8sm507258pjb.6 - gsmtp
Connection closed by foreign host.

Si envío un dominio real, obtengo la respuesta esperada.

root@conversation:~# telnet smtp-relay.gmail.com 587
Trying 74.125.137.28...
Connected to smtp-relay.gmail.com.
Escape character is '^]'.
220 smtp-relay.gmail.com ESMTP p10sm668563uaw.3 - gsmtp
ehlo conversation.sevarg.net
250-smtp-relay.gmail.com at your service, [64.227.96.27]
250-SIZE 157286400
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8

Así que, ahora la pregunta es: ¿cómo se hace para que Discourse envíe una cadena de dominio correcta en el ehlo?

No sé si sea el único problema, pero definitivamente parece prometedor investigar esto.

15

Esto es muy extraño. ¿Dónde habría entrado esto de repente? No he realizado ninguna actualización.

16

No ha surgido de la nada, siempre ha sido así. Google cambió algo.

discourse-doctor ejecuta la prueba en /var/www/discourse/lib/tasks/emails.rake si estás dentro de la imagen.

Cambié:

Net::SMTP.start(smtp[:address], smtp[:port], 'localhost', smtp[:user_name], smtp[:password], smtp[:authentication])

por

Net::SMTP.start(smtp[:address], smtp[:port], 'conversation.sevarg.net', smtp[:user_name], smtp[:password], smtp[:authentication])

Ahora obtengo un error diferente.

======================================== ERROR ========================================
                                    ERROR INESPERADO

503 5.5.1 secuencia de comandos incorrecta e190sm562849qkd.9 - gsmtp


====================================== SOLUCIÓN =======================================
Este no es un error común. ¡No existe ninguna solución recomendada!

Por favor, reporta el mensaje de error exacto anterior en https://meta.discourse.org/
(¡Y una solución, si logras encontrar una!)
=======================================================================================

PERO: lo importante es que el tcpdump muestra algo parecido a un flujo (razonablemente) lógico.

22:33:48.393862 IP 64.227.96.27.54610 > 74.125.137.28.587: Flags [P.], seq 1:31, ack 59, win 502, options [nop,nop,TS val 3732187266 ecr 3508646052], length 30
	0x0000:  4500 0052 d4d6 4000 3f06 f237 40e3 601b  E..R..@.?..7@.`.
	0x0010:  4a7d 891c d552 024b 01b4 04a4 94ce dcc7  J}...R.K........
	0x0020:  8018 01f6 74dc 0000 0101 080a de74 a882  ....t........t..
	0x0030:  d121 b0a4 4548 4c4f 2063 6f6e 7665 7273  .!..EHLO.convers
	0x0040:  6174 696f 6e2e 7365 7661 7267 2e6e 6574  ation.sevarg.net
	0x0050:  0d0a                                     ..
22:33:48.408832 IP 74.125.137.28.587 > 64.227.96.27.54610: Flags [.], ack 31, win 256, options [nop,nop,TS val 3508646067 ecr 3732187266], length 0
	0x0000:  4500 0034 5e5d 0000 2b06 bccf 4a7d 891c  E..4^]..+...J}..
	0x0010:  40e3 601b 024b d552 94ce dcc7 01b4 04c2  @.`..K.R........
	0x0020:  8010 0100 a8ae 0000 0101 080a d121 b0b3  .............!..
	0x0030:  de74 a882                                .t..
22:33:48.469560 IP 74.125.137.28.587 > 64.227.96.27.54610: Flags [P.], seq 59:234, ack 31, win 256, options [nop,nop,TS val 3508646128 ecr 3732187266], length 175
	0x0000:  4500 00e3 5e8a 0000 2b06 bbf3 4a7d 891c  E...^...+...J}..
	0x0010:  40e3 601b 024b d552 94ce dcc7 01b4 04c2  @.`..K.R........
	0x0020:  8018 0100 929f 0000 0101 080a d121 b0f0  .............!..
	0x0030:  de74 a882 3235 302d 736d 7470 2d72 656c  .t..250-smtp-rel
	0x0040:  6179 2e67 6d61 696c 2e63 6f6d 2061 7420  ay.gmail.com.at.
	0x0050:  796f 7572 2073 6572 7669 6365 2c20 5b36  your.service,.[6
	0x0060:  342e 3232 372e 3936 2e32 375d 0d0a 3235  4.227.96.27]..25
	0x0070:  302d 5349 5a45 2031 3537 3238 3634 3030  0-SIZE.157286400
	0x0080:  0d0a 3235 302d 3842 4954 4d49 4d45 0d0a  ..250-8BITMIME..
	0x0090:  3235 302d 5354 4152 5454 4c53 0d0a 3235  250-STARTTLS..25
	0x00a0:  302d 454e 4841 4e43 4544 5354 4154 5553  0-ENHANCEDSTATUS
	0x00b0:  434f 4445 530d 0a32 3530 2d50 4950 454c  CODES..250-PIPEL
	0x00c0:  494e 494e 470d 0a32 3530 2d43 4855 4e4b  INING..250-CHUNK
	0x00d0:  494e 470d 0a32 3530 2053 4d54 5055 5446  ING..250.SMTPUTF
	0x00e0:  380d 0a                                  8..

Así que, como mínimo, enviar “EHLO localhost” o “EHLO localhost.localdomain” es parte del problema.

Ahora, ¿cómo diablos se reporta un problema P0 a los desarrolladores reales?

17

Definitivamente he visto a estos chicos en los foros. Por lo que puedo ver, los monitorean bastante de cerca. Diría que es GitHub, pero parece que los problemas están deshabilitados para el repositorio.

18

Ok.

Este es un correo de prueba desde

https://conversation.sevarg.net

La entrega de correos es complicada. Aquí hay algunas cosas importantes que debes verificar primero:

Acabo de demostrar una solución, pero no sé cómo enviar esto al proyecto principal.

cd /var/discourse
./launcher enter app
vim ./vendor/bundle/ruby/2.7.0/gems/mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb

Debes buscar la siguiente sección:

    DEFAULTS = {
      :address              => 'localhost',
      :port                 => 25,
      :domain               => 'localhost.localdomain',
      :user_name            => nil,
      :password             => nil,
      :authentication       => nil,
      :enable_starttls      => nil,
      :enable_starttls_auto => true,
      :openssl_verify_mode  => nil,
      :ssl                  => nil,
      :tls                  => nil,
      :open_timeout         => nil,
      :read_timeout         => nil
    }

Cambia las líneas relacionadas con el dominio.

    DEFAULTS = {
      :address              => 'conversation.sevarg.net',
      :port                 => 25,
      :domain               => 'conversation.sevarg.net',
      :user_name            => nil,
      :password             => nil,
      :authentication       => nil,
      :enable_starttls      => nil,
      :enable_starttls_auto => true,
      :openssl_verify_mode  => nil,
      :ssl                  => nil,
      :tls                  => nil,
      :open_timeout         => nil,
      :read_timeout         => nil
    }

No sé cuál es la importante, pero cambiar ambas resolvió el problema. Obviamente, usa tu propio dominio…

Sal del entorno de la aplicación.

./launcher restart app

Ahora debería poder enviar correos electrónicos.

Espero que esto no sobreviva a ninguna actualización.

Sin embargo, ahora estoy enviando y recibiendo correos electrónicos como se esperaba.

¿Desarrolladores? ¿Por favor arreglen esto?

19

Desde el error que reporté, por favor intenta lo siguiente:

Agrega

DISCOURSE_SMTP_DOMAIN: [tu dominio de instalación]

a tu archivo app.yml (/var/discourse/containers/app.yml, lo más probable es que sea allí)

Luego reconstruye la aplicación (cd /var/discourse; ./launcher rebuild app) y prueba enviar correos electrónicos.

20

Solo para aclarar, ¿DISCOURSE_SMTP_DOMAIN se refiere al dominio de mi servidor Discourse o al dominio del correo electrónico?

Por ejemplo, mi servidor está en el subdominio community.acescentral.com y mis correos provienen de admin@acescentral.com. Entonces, ¿DISCOURSE_SMTP_DOMAIN es el dominio principal acescentral.com o el subdominio community?

Muchas gracias por ser tan incansable en la búsqueda de esta solución.