Email non inviati - raggiunto il fine file

Supporto
1

Ciao a tutti, scusate se questo è simile ad alcuni degli altri post che menzionano questo errore.

Negli ultimi quattro giorni tutte le email hanno smesso di essere inviate, e anche l’email di test fallisce.

Ho esaminato gli argomenti esistenti simili, ma nel mio caso nulla (per quanto ne sappia) è cambiato, e la posta ha smesso di funzionare dopo aver funzionato per mesi senza problemi.

Stiamo utilizzando l’hosting su Digital Ocean e stiamo usando il relay SMTP di G Suite configurato per inoltrare le email dall’indirizzo IP del droplet.

L’errore esatto elencato in Sidekiq è un po’ più dettagliato di quello che ottengo da discourse-doctor.

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

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

Ho anche potuto confermare la connessione al server con:

telnet smtp-relay.gmail.com 587

Credo ci sia stato un altro breve periodo in cui le email hanno smesso di essere inviate molti mesi fa, ma non ricordo l’errore (in quel momento sono riuscito a riprovare da Sidekiq senza alcun problema).

Qualcuno ha sperimentato qualcosa di simile o ha una configurazione simile che funziona ancora? Grazie in anticipo!

2

Non ho ancora consigli utili, ma ho riscontrato esattamente lo stesso problema, con la stessa configurazione: un droplet DigitalOcean che invia email tramite smtp-relay.gmail.com, ottenendo errori EOF.

Sidekiq riporta quanto segue:

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

Controllando in /logs, ottengo una traccia di errore per il fallimento, ma nulla che risulti immediatamente utile.

Informazioni:

Eccezione del job: end of file reached

Backtrace:

/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

discourse-doctor ha un output generale simile:

==================== TEST MAIL ====================
Per un test robusto, ottieni un indirizzo da http://www.mail-tester.com/
Oppure invia semplicemente un messaggio di prova a te stesso.
Indirizzo email per il test mail? ('n' per saltare) [[la mia email]]: 
Invio email a [la mia email]... 
Test dell'invio a [la mia email] utilizzando smtp-relay.gmail.com:587.
======================================== ERRORE ========================================
                                    ERRORE INATTESO

end of file reached

====================================== SOLUZIONE =======================================
Questo non è un errore comune. Non esiste una soluzione consigliata!

Si prega di segnalare l'esatto messaggio di errore sopra a https://meta.discourse.org/
(E una soluzione, se ne trovi una!)
=======================================================================================

Posso anche fare telnet al relay sulla porta 587 (e inviare un messaggio di prova a mano - non lo facevo da un decennio…), e non ho cambiato nulla che mi venga in mente nella storia recente che avrebbe potuto influenzare la posta.

Sono praticamente bloccato per quanto riguarda nuovi utenti e simili, il che è un problema dato che lo sto usando anche per i commenti del blog. Non ho trovato nulla nei log di Google che sia particolarmente utile, e sono completamente senza idee per continuare la risoluzione dei problemi. Tutto sembra essere configurato correttamente, ma le cose semplicemente non funzionano più.

3

Beh, è sicuramente un conforto sapere che la mia configurazione non è troppo insolita e che non sono solo nei miei guai. Curioso, il problema è iniziato anche per te circa 5 giorni fa? Forse c’è stato un aggiornamento a qualcosa di comune nelle nostre pipeline.

Grazie per aver condiviso i dettagli e la backtrace. I miei erano molto simili ai tuoi e gli errori erano identici.

Non ho provato a inviare manualmente un’email tramite telnet, ma sospetto che funzionerebbe come è successo per te.

Sono nella stessa situazione e al momento stiamo attivando manualmente i nuovi utenti (per fortuna sono solo pochi al giorno). Considerando che non ho apportato modifiche a G Suite, Digital Ocean o alla configurazione di Discourse, esito a iniziare a cambiare qualcosa senza poter restringere il campo su cosa stia effettivamente causando il problema. :confused:

4

Il primo vero picco di errori in Sidekiq si è verificato il 14 gennaio, quindi… 5 giorni fa. Prima di allora, avevo alcuni errori casuali legati a email errate o simili, ma nulla che aumentasse rapidamente.

Ho provato a ricreare le impostazioni di relay nella Console di amministrazione di Google e a modificarle (incluso ciò che dovrebbe essere completamente aperto), senza ottenere cambiamenti. Ho anche provato diverse porte per l’invio di email, ma senza risultati.

Inoltre, non ho apportato modifiche di cui abbia consapevolezza 5 giorni fa. :confused:

5

Un altro rapporto di problemi, DigitalOcean → smtp-relay.gmail.com

Qualcuno può facilmente testare da una VM non DigitalOcean? GCE o qualcosa del genere?

6

Ho appena avviato un’installazione di Discourse su GCE, con le mie credenziali, e ho ottenuto lo stesso errore (avendo configurato il relay per basarsi solo sull’autenticazione).

======================================== ERRORE ========================================
                                    ERRORE INATTESO

fine del file raggiunta

====================================== SOLUZIONE =======================================
Questo non è un errore comune. Non esiste una soluzione consigliata!

Si prega di segnalare il messaggio di errore esatto sopra a https://meta.discourse.org/
(E una soluzione, se ne trovate una!)
=======================================================================================

Configurare l’autenticazione basata su IP per il relay ha dato gli stessi risultati. Quindi non penso che sia un problema specifico di DigitalOcean…

Purtroppo, “Risoluzione dei problemi di email di Ruby/Rails” è oltre le mie attuali competenze… qualche suggerimento?

7

C’è la possibilità che si tratti di un problema con SMTP di Gmail?

8

Sembra di sì. Non so come risolvere il problema e i miei tentativi finora non hanno portato a nulla. Probabilmente hanno modificato qualcosa, Discourse non riesce a gestirlo e, naturalmente, non c’è supporto.

9

In passato ho avuto fortuna su questi forum nel trovare e risolvere problemi. Non so perché questo sia così silenzioso.

10

È possibile che si tratti di un problema con SMTP di Gmail/G Suite, ma @Syonyk ha menzionato di essere riuscito a inviare manualmente una email tramite telnet sul suo droplet.

Non sono abbastanza esperto per sapere come G Suite potrebbe interpretare il traffico inviato dal sito rispetto a un messaggio inviato manualmente, ma questo sembra indicare che il problema risiede nel servizio che invia l’email a smtp-relay.gmail, e non nel relay stesso.

Per completezza, ho anche autorizzato specificamente l’indirizzo IP del droplet nelle impostazioni di amministrazione di G Suite, e non ho modificato (e non ho ancora modificato) alcuna impostazione in nessuno dei servizi da diversi mesi.

L’unica volta che ho visto accadere qualcosa di simile è durato solo un giorno (forse due — la pagina non era molto trafficata in quel momento, quindi probabilmente non me ne sarei accorto se fosse durato di più), ma sembra essersi risolto piuttosto rapidamente.

11

Senza un buon tracciato della conversazione SMTP da Discourse, non so come procedere con l’ulteriore risoluzione del problema e non so come ottenere tali tracciati.

12

C’è un modo per confermare il numero di email che invio tramite Discourse ogni mese? Se dovessi passare a un altro relay SMTP, avrei bisogno di sapere quale budget mi servirebbe. È estremamente frustrante.

13

Sotto /admin/email/sent nella tua istanza, dovresti poter vedere cosa è stato inviato e stimare l’utilizzo da lì.

14

Mmh…

Ho avviato un tcpdump sul server e eseguito discourse-doctor. Ecco cosa ho trovato nell’output…

...
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, cosa importante, riesco a riprodurre questo errore 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.

Se invio un dominio reale, ottengo la risposta attesa.

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

Quindi, ora la domanda è: come si fa in modo che Discourse invii una stringa di dominio corretta nell’ehlo?

Non so se sia l’unico problema, ma sembra certamente promettente approfondire la questione.

15

È così strano. Come mai è apparso improvvisamente? Non ho effettuato alcun aggiornamento.

16

Non si è insinuato gradualmente, è sempre stato così. Google ha modificato qualcosa.

discourse-doctor chiama il test in /var/www/discourse/lib/tasks/emails.rake - se ti trovi all’interno dell’immagine.

Ho modificato:

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

in

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

Ora ottengo un errore diverso.

======================================== ERRORE ========================================
                                    ERRORE INASPETTATO

503 5.5.1 sequenza di comandi errata e190sm562849qkd.9 - gsmtp


====================================== SOLUZIONE =======================================
Questo non è un errore comune. Non esiste una soluzione consigliata!

Si prega di segnalare il messaggio di errore esatto sopra a https://meta.discourse.org/
(Con una soluzione, se ne trovi una!)
=======================================================================================

MA: è importante notare che il tcpdump mostra un flusso che assomiglia a qualcosa di 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..

Quindi, almeno, l’invio di “EHLO localhost” o “EHLO localhost.localdomain” fa parte del problema.

Ora, come diavolo si fa a segnalare un problema P0 agli sviluppatori effettivi?

17

Ho sicuramente visto questi ragazzi nei forum. Per quanto posso capire, li monitorano abbastanza da vicino. Direi github, ma sembra che le issue siano disabilitate per il repository.

18

Ok.

Questo è un'email di test da

https://conversation.sevarg.net

La consegna delle email è complessa. Ecco alcune cose importanti da verificare per prima cosa:

Ho appena dimostrato una soluzione, ma non so come contribuire questa modifica al progetto principale.

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

Devi trovare la seguente sezione:

    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
    }

Modifica le righe relative al 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
    }

Non so quale delle due sia quella determinante, ma modificando entrambe ho risolto il problema. Ovviamente usa il tuo dominio…

Esci dall’ambiente dell’app.

./launcher restart app

Ora dovrebbe essere in grado di inviare email.

Mi aspetto che questa modifica non sopravviva agli aggiornamenti.

Tuttavia, ora sto inviando e ricevendo email come previsto.

Sviluppatori? Per favore, sistemate la cosa?

19

Dal bug che ho segnalato, prova quanto segue:

Aggiungi

DISCOURSE_SMTP_DOMAIN: [il tuo dominio di installazione]

al tuo app.yml (/var/discourse/containers/app.yml, molto probabilmente)

Quindi ricompila l’app (cd /var/discourse; ./launcher rebuild app) e prova a inviare email.

20

Per chiarezza, DISCOURSE_SMTP_DOMAIN si riferisce al dominio del mio server Discourse o al dominio dell’email?

Ad esempio, il mio server risiede nel sottodominio community.acescentral.com e le mie email provengono da admin@acescentral.com. Quindi, DISCOURSE_SMTP_DOMAIN è il dominio principale acescentral.com o il sottodominio community?

Grazie mille per la tua tenacia nel risolvere questo problema.