Emails pararam de enviar - fim do arquivo alcançado

Suporte
1

Olá a todos, e peço desculpas se isso for semelhante a alguns dos outros posts que mencionam esse erro.

Nos últimos quatro dias, todos os e-mails deixaram de ser enviados, e o teste de e-mail também falha.

Fiquei navegando pelos tópicos existentes que são semelhantes, mas, no meu caso, nada (que eu saiba) mudou, e o e-mail parou de funcionar depois de ter funcionado por meses sem problemas.

Estamos usando hospedagem na Digital Ocean e estamos usando o relay SMTP do G Suite configurado para retransmitir e-mails do endereço IP do droplet.

O erro exato listado no Sidekiq é um pouco mais detalhado do que o que recebo do discourse-doctor.

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

O discourse-doctor apenas diz: UNEXPECTED ERROR: end of file reached

Também consegui confirmar a conexão com o servidor usando:

telnet smtp-relay.gmail.com 587

Acredito que houve uma breve interrupção há vários meses, quando os e-mails pararam de ser enviados, mas não me lembro do erro (naquela época, consegui reenviar a partir do Sidekiq sem problemas).

Alguém já passou por algo semelhante ou tem uma configuração similar que ainda está funcionando? Obrigado antecipadamente!

2

Ainda não tenho conselhos úteis, mas encontrei exatamente o mesmo problema, com a mesma configuração: um droplet da DigitalOcean, enviando e-mails via smtp-relay.gmail.com, recebendo erros EOF.

O Sidekiq relata o seguinte:

Jobs::HandledExceptionWrapper: Wrapped EOFError: fim do arquivo atingido

Ao verificar em /logs, obtenho um rastreamento de exceção, mas nada que se destaque imediatamente como útil.

Informações:

Exceção do Job: fim do arquivo atingido

Rastreamento:

/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'

Ambiente:

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

O discourse-doctor apresenta a mesma saída geral:

==================== TESTE DE E-MAIL ====================
Para um teste robusto, obtenha um endereço em http://www.mail-tester.com/
Ou apenas envie uma mensagem de teste para si mesmo.
Endereço de e-mail para o teste? ('n' para pular) [[meu e-mail]]: 
Enviando e-mail para [meu e-mail]... 
Testando o envio para [meu e-mail] usando smtp-relay.gmail.com:587.
======================================== ERRO ========================================
                                    ERRO INESPERADO

fim do arquivo atingido

====================================== SOLUÇÃO =======================================
Este não é um erro comum. Nenhuma solução recomendada existe!

Por favor, relate a mensagem de erro exata acima para https://meta.discourse.org/
(E uma solução, se você encontrar uma!)
=======================================================================================

Também consigo fazer telnet no relay na porta 587 (e enviar uma mensagem de teste manualmente — não faço isso há uma década…), e não alterei nada que eu possa lembrar recentemente que pudesse ter afetado o e-mail.

Estou praticamente paralisado em termos de novos usuários e afins, o que é um problema, já que estou usando o sistema também para comentários de blog. Não encontrei nada nos logs do Google que seja muito útil, e estou completamente sem ideias para continuar a solução de problemas. Tudo parece estar configurado corretamente, mas as coisas simplesmente deixaram de funcionar.

3

Bem, é definitivamente um alívio saber que minha configuração não é tão incomum e que não estou sozinho nessas dificuldades. Curioso, o problema começou para você também há cerca de 5 dias? Talvez tenha havido uma atualização de algo comum em nossos pipelines.

Obrigado por compartilhar os detalhes e o rastreamento. Os meus foram muito semelhantes aos seus, e os erros eram idênticos.

Não tentei enviar manualmente um e-mail via telnet, mas suspeito que funcionaria como funcionou para você.

Estou na mesma situação e, por enquanto, estamos ativando manualmente os novos usuários (felizmente, são apenas alguns por dia). Considerando que não alterei nada no G Suite, no Digital Ocean ou na configuração do Discourse, estou hesitante em começar a fazer mudanças sem conseguir identificar exatamente o que está causando o problema. :confused:

4

O primeiro pico real de falhas no Sidekiq ocorreu em 14 de janeiro, ou seja… há 5 dias. Antes disso, eu tinha algumas falhas aleatórias relacionadas a e-mails inválidos ou coisas do tipo, mas nada que aumentasse rapidamente.

Tentei recriar as configurações de retransmissão no Console de Administração do Google e ajustar essas configurações (incluindo o que deveria estar totalmente aberto), sem nenhuma mudança. Tentei também usar portas diferentes para o envio de e-mails, também sem alterações.

Além disso, não alterei nada que eu saiba há 5 dias. :confused:

5

Outro relatório de problemas, DigitalOcean → smtp-relay.gmail.com

Alguém consegue testar facilmente a partir de uma VM que não seja da DigitalOcean? GCE ou algo assim?

6

Acabei de iniciar uma instalação do Discourse no GCE, com minhas credenciais, e obtive o mesmo erro (tendo configurado meu relay para confiar apenas na autenticação).

======================================== ERRO ========================================
                                    ERRO INESPERADO

fim do arquivo atingido

====================================== SOLUÇÃO =======================================
Este não é um erro comum. Não existe uma solução recomendada!

Por favor, relate a mensagem de erro exata acima em https://meta.discourse.org/
(E uma solução, se você encontrar uma!)
=======================================================================================

Configurar a autenticação baseada em IP para o relay produziu os mesmos resultados. Então, não acho que seja um problema específico do DigitalOcean…

Infelizmente, “Resolução de problemas de e-mail do Ruby/Rails” está além do meu nível de conhecimento atual… alguma sugestão?

7

Há alguma chance de ser um problema no SMTP do Gmail?

8

Parece que sim. Não sei como solucionar o problema, e minhas tentativas de corrigi-lo até agora não deram em nada. Provavelmente eles alteraram algo, o Discourse não consegue lidar com isso e, claro, não há suporte.

9

Já tive sorte nesses fóruns antes, ajudando a identificar e resolver problemas. Não sei por que este está tão silencioso.

10

É possível que seja um problema de SMTP do Gmail/G Suite, mas @Syonyk mencionou que conseguiu enviar manualmente um e-mail via telnet em seu droplet.

Não tenho experiência suficiente para saber como o G Suite pode interpretar o tráfego enviado pelo site em comparação com mensagens enviadas manualmente, mas isso parece indicar que o problema está no serviço que envia o e-mail para o smtp-relay.gmail, e não no próprio relay.

A propósito, também tenho o endereço IP do droplet explicitamente permitido nas configurações de administração do G Suite, e não alterei (e ainda não alterei) nenhuma configuração em nenhum dos serviços há vários meses.

A única vez que vi algo semelhante acontecer foi por apenas um dia (talvez dois — não era uma página muito movimentada na época, então provavelmente não teria percebido se tivesse durado mais), mas parece que se resolveu muito rapidamente.

11

Sem um bom registro da conversa SMTP do Discourse, não sei como solucionar o problema de forma mais detalhada — e também não sei como obter esses registros.

12

Existe alguma forma de confirmar a quantidade de e-mails que estou enviando a partir do Discourse por mês? Se eu precisar migrar para outro relay SMTP, precisarei saber qual orçamento seria necessário. Isso é extremamente frustrante.

13

Em /admin/email/sent na sua instância, você deverá conseguir ver o que foi enviado e estimar o uso a partir daí.

14

Hm…

Joguei um tcpdump no servidor e executei o discourse-doctor. E encontrei isso na saída…

...
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..

E, o mais importante, eu CONSIGO reproduzir essa falha com o 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.

Se eu enviar um domínio real, obtenho a resposta 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

Então, agora a pergunta é: como fazer o Discourse enviar uma string de domínio adequada no ehlo?

Não sei se é o único problema, mas com certeza parece promissor investigar isso.

15

Isso é muito estranho. De onde isso teria surgido de repente? Eu não fiz nenhuma atualização.

16

Não foi algo que surgiu gradualmente, sempre foi assim. O Google mudou algo.

O discourse-doctor chama o teste em /var/www/discourse/lib/tasks/emails.rake — caso você esteja dentro da imagem.

Mudei:

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

para

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

Agora recebo um erro diferente.

======================================== ERRO ========================================
                                    ERRO INESPERADO

503 5.5.1 sequência de comandos inválida e190sm562849qkd.9 - gsmtp


====================================== SOLUÇÃO =======================================
Este não é um erro comum. Não existe uma solução recomendada!

Por favor, relate a mensagem de erro exata acima em https://meta.discourse.org/
(E uma solução, caso encontre uma!)
=======================================================================================

MAS: o importante é que o tcpdump mostra algo que se assemelha a um fluxo (razoavelmente) sensato.

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..

Portanto, no mínimo, enviar “EHLO localhost” ou “EHLO localhost.localdomain” é parte do problema.

Agora, como diabos se reporta um problema P0 aos desenvolvedores reais?

17

Com certeza já vi esses caras nos fóruns. Pelo que posso perceber, eles os monitoram de perto. Eu diria github, mas parece que os problemas estão desabilitados para o repositório.

18

Ok.

Este é um e-mail de teste de

https://conversation.sevarg.net

A entregabilidade de e-mails é complicada. Aqui estão algumas coisas importantes que você deve verificar primeiro:

Acabei de demonstrar uma correção, mas não sei como enviar isso para o repositório 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

Você precisa encontrar a seguinte seção:

    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
    }

Altere as linhas de domínio.

    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
    }

Não sei qual delas importa, mas alterar ambas resolveu o problema. Obviamente, use seu próprio domínio…

Saia do ambiente do app.

./launcher restart app

Agora ele deve conseguir enviar e-mails.

Espero que isso não sobreviva a nenhuma atualização.

No entanto, agora estou enviando e recebendo e-mails conforme o esperado.

Desenvolvedores? Plz2fix?

19

Com base no bug que registrei, tente o seguinte:

Adicione

DISCOURSE_SMTP_DOMAIN: [seu domínio de instalação]

ao seu app.yml (/var/discourse/containers/app.yml, provavelmente).

Em seguida, reconstrua o aplicativo (cd /var/discourse; ./launcher rebuild app) e tente enviar e-mails.

20

Só para esclarecer: DISCOURSE_SMTP_DOMAIN é o domínio do meu servidor Discourse ou o domínio do e-mail?

Por exemplo, meu servidor está no subdomínio community.acescentral.com e meus e-mails vêm de admin@acescentral.com. Então, DISCOURSE_SMTP_DOMAIN seria o domínio principal acescentral.com ou o subdomínio community?

Muito obrigado por ser tão incansável na busca por essa solução.