E-Mails werden nicht mehr gesendet – End-of-File erreicht

Unterstützung
1

Hallo zusammen, und Entschuldigung, falls dies einem der anderen Beiträge ähnelt, die diesen Fehler erwähnen.

Seit vier Tagen werden keine E-Mails mehr versendet, und der Test-E-Mail-Versuch schlägt ebenfalls fehl.

Ich habe bereits nach ähnlichen bestehenden Themen gesucht, aber in meinem Fall hat sich nichts geändert (soweit ich weiß), und die E-Mail-Funktion hat aufgehört zu arbeiten, obwohl sie zuvor monatelang ohne Probleme funktioniert hat.

Wir nutzen Hosting bei Digital Ocean und verwenden den G Suite SMTP-Relay, der so konfiguriert ist, dass er E-Mails von der IP-Adresse des Droplets weiterleitet.

Die genaue Fehlermeldung in Sidekiq ist etwas ausführlicher als die, die ich von discourse-doctor erhalte.

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

discourse-doctor sagt lediglich: UNEXPECTED ERROR: end of file reached

Ich konnte auch eine Verbindung zum Server mit folgendem Befehl bestätigen:

telnet smtp-relay.gmail.com 587

Ich erinnere mich, dass es vor vielen Monaten bereits einmal eine kurze Unterbrechung gab, bei der keine E-Mails mehr versendet wurden, aber ich kann mich nicht an den Fehler erinnern (damals konnte ich ohne Probleme erneut über Sidekiq versuchen, die E-Mails zu versenden).

Hat jemand Ähnliches erlebt oder verfügt über eine ähnliche Konfiguration, die noch funktioniert? Vielen Dank im Voraus!

2

Ich habe noch keinen nützlichen Rat, bin aber auf exakt das gleiche Problem gestoßen, mit exakt dem gleichen Setup – DigitalOcean Droplet, E-Mail-Versand über smtp-relay.gmail.com, dabei EOFErrors.

Sidekiq meldet Folgendes:

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

Im Verzeichnis /logs erhalte ich einen Traceback des Fehlers, aber nichts, das sofort als hilfreich auffällt.

Info:

Job exception: 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'

Env:

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 liefert das gleiche allgemeine Ergebnis:

==================== MAIL TEST ====================
Für einen robusten Test hole dir eine Adresse unter http://www.mail-tester.com/
Oder sende einfach eine Testnachricht an dich selbst.
E-Mail-Adresse für den Mail-Test? ('n' zum Überspringen) [[meine E-Mail]]: 
Sende E-Mail an [meine E-Mail] . . . 
Teste Versand an [meine E-Mail] über smtp-relay.gmail.com:587.
======================================== FEHLER ========================================
                                    UNERWARTETER FEHLER

end of file reached

====================================== LÖSUNG =======================================
Dies ist kein häufiger Fehler. Es existiert keine empfohlene Lösung!

Bitte melde die genaue Fehlermeldung oben unter https://meta.discourse.org/
(Und eine Lösung, falls du eine findest!)
=======================================================================================

Ich kann auch per Telnet auf Port 587 zum Relay verbinden (und eine Testnachricht manuell senden – das habe ich seit einem Jahrzehnt nicht mehr gemacht…), und ich habe in der jüngeren Vergangenheit nichts geändert, was meiner Meinung nach den E-Mail-Versand beeinträchtigt hätte.

Ich stehe bezüglich neuer Benutzer usw. ziemlich auf der Stelle, was ein Problem darstellt, da ich die Plattform auch für Blogkommentare nutze. In den Google-Logs habe ich ebenfalls nichts gefunden, das wirklich hilfreich wäre, und mir gehen die Ideen zur weiteren Fehlersuche langsam aus. Alles scheint korrekt konfiguriert zu sein, aber es funktioniert einfach nicht mehr.

3

Nun, es ist definitiv ein Trost zu wissen, dass meine Einrichtung nicht allzu ungewöhnlich ist und ich mit meinen Problemen nicht allein dastehe. Ich bin neugierig: Hat das Problem auch bei dir vor etwa 5 Tagen begonnen? Vielleicht gab es ein Update für etwas, das in unseren Pipelines häufig vorkommt.

Danke, dass du die Details und den Backtrace geteilt hast. Meine waren deinen sehr ähnlich, und die Fehler waren identisch.

Ich habe nicht versucht, manuell per Telnet eine E-Mail zu senden, aber ich vermute, es würde funktionieren, genau wie bei dir.

Ich befinde mich in derselben Situation, und wir aktivieren vorerst neue Benutzer manuell (zum Glück sind das nur wenige pro Tag). Da ich nichts in G Suite, DigitalOcean oder der Discourse-Konfiguration geändert habe, zögere ich, etwas zu verändern, ohne herausfinden zu können, was das Problem tatsächlich verursacht. :confused:

4

Der erste echte Anstieg von Fehlern in Sidekiq war am 14. Januar, also vor 5 Tagen. Davor hatte ich einige zufällige Fehler im Zusammenhang mit fehlerhaften E-Mails oder ähnlichem, aber nichts, was schnell anstieg.

Ich habe versucht, die Relay-Einstellungen in der Google Admin Console nachzubauen und daran herumzuspielen (einschließlich derer, die eigentlich weit offen sein sollten), ohne dass sich etwas änderte. Ich habe auch verschiedene Ports für den E-Mail-Versuch ausprobiert, ebenfalls ohne Erfolg.

Außerdem habe ich mir nichts bewusst vor 5 Tagen geändert. :confused:

5

Ein weiterer Bericht über Probleme: DigitalOcean → smtp-relay.gmail.com

Kann jemand leicht von einer nicht-DigitalOcean-VM testen? GCE oder etwas Ähnliches?

6

Ich habe gerade eine Discourse-Installation auf GCE mit meinen Zugangsdaten gestartet und denselben Fehler erhalten (nachdem ich mein Relay so konfiguriert habe, dass es sich nur auf die Authentifizierung verlässt).

======================================== FEHLER ========================================
                                    UNERWARTETER FEHLER

Ende der Datei erreicht

====================================== LÖSUNG =======================================
Dies ist kein häufiger Fehler. Es existiert keine empfohlene Lösung!

Bitte melden Sie die genaue Fehlermeldung oben unter https://meta.discourse.org/
(Und eine Lösung, falls Sie eine finden!)
=======================================================================================

Die Einrichtung einer IP-basierten Authentifizierung für das Relay ergab dieselben Ergebnisse. Daher glaube ich nicht, dass es sich um ein DigitalOcean-spezifisches Problem handelt…

Leider geht „Fehlerbehebung bei Ruby/Rails-E-Mail-Problemen

7

Gibt es eine Chance, dass dies ein Gmail SMTP-Problem ist?

8

Sieht wohl so aus. Ich weiß nicht, wie man das Problem behebt, und meine bisherigen Versuche, es zu reparieren, haben nichts gebracht. Sie haben wahrscheinlich etwas geändert, Discourse kann damit nicht umgehen, und es gibt natürlich keinen Support.

9

Ich hatte auf diesen Foren schon früher Glück, Probleme aufzuspüren und zu lösen. Ich bin mir nicht sicher, warum es hier gerade so ruhig ist.

10

Es könnte ein Problem mit dem Gmail/G-Suite-SMTP sein, aber @Syonyk erwähnte, dass er in der Lage war, eine E-Mail manuell über Telnet auf seinem Droplet zu senden.

Ich bin nicht annähernd erfahren genug, um zu wissen, wie G-Suite den vom Site gesendeten Verkehr im Vergleich zu einer manuell gesendeten Nachricht interpretiert, aber das scheint darauf hinzudeuten, dass das Problem beim Dienst liegt, der die E-Mail an smtp-relay.gmail sendet, und nicht beim Relay selbst.

Übrigens habe ich die IP-Adresse des Droplets in den G-Suite-Administrator-Einstellungen explizit erlaubt, und ich habe seit mehreren Monaten keine Einstellungen in einem der Dienste geändert (und habe sie immer noch nicht geändert).

Das einzige Mal, dass ich etwas Ähnliches sah, dauerte es nur einen Tag (vielleicht zwei – die Seite war damals nicht sehr aktiv, also hätte ich es wahrscheinlich nicht bemerkt, wenn es länger gedauert hätte), aber es schien sich ziemlich schnell von selbst zu beheben.

11

Ohne eine gute Aufzeichnung des SMTP-Verkehrs von Discourse weiß ich nicht, wie ich weiter vorgehen soll, um das Problem zu beheben – und ich weiß auch nicht, wie ich diese Aufzeichnungen erhalten kann.

12

Gibt es eine Möglichkeit, die Anzahl der E-Mails zu bestätigen, die ich monatlich über Discourse versende? Falls ich zu einem anderen SMTP-Relay wechseln müsste, müsste ich wissen, welches Budget dafür erforderlich wäre. Das ist extrem frustrierend.

13

Unter /admin/email/sent auf deiner Instanz solltest du sehen können, was gesendet wurde, und den Verbrauch dort abschätzen.

14

Hm…

Ich habe tcpdump auf dem Server gestartet und discourse-doctor ausgeführt. Dabei fand ich Folgendes im 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..

Und was besonders wichtig ist: Ich kann diesen Fehler mit telnet reproduzieren.

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.

Wenn ich eine echte Domain sende, erhalte ich die erwartete Antwort.

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

Die Frage ist also nun: Wie sorgt man dafür, dass Discourse beim EHLO-Befehl eine korrekte Domänenzeichenfolge sendet?

Ich weiß nicht, ob dies das einzige Problem ist, aber es sieht vielversprechend aus, diesem auf den Grund zu gehen.

15

Das ist so seltsam. Woher ist das plötzlich gekommen? Ich habe keine Updates durchgeführt.

16

Es ist nicht schleichend dazugekommen, es war schon immer so. Google hat etwas geändert.

discourse-doctor ruft den Test in /var/www/discourse/lib/tasks/emails.rake auf – falls du dich im Image befindest.

Ich habe Folgendes geändert:

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])

Jetzt erhalte ich einen anderen Fehler.

======================================== FEHLER ========================================
                                    UNERWARTETER FEHLER

503 5.5.1 bad sequence of commands e190sm562849qkd.9 - gsmtp


====================================== LÖSUNG =======================================
Dies ist kein häufiger Fehler. Es gibt keine empfohlene Lösung!

Bitte melde die genaue Fehlermeldung oben unter https://meta.discourse.org/
(Und eine Lösung, falls du eine findest!)
=======================================================================================

ABER: Wichtig ist, dass der tcpdump etwas zeigt, das einer (zumindest halbwegs) sinnvollen Ablauflogik ähnelt.

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

Also ist zumindest das Senden von „EHLO localhost

17

Ich habe diese Jungs definitiv schon auf den Foren gesehen. Soweit ich das beurteilen kann, überwachen sie sie ziemlich genau. Ich würde GitHub sagen, aber für das Repository scheinen die Issues deaktiviert zu sein.

18

Ok.

Dies ist eine Test-E-Mail von

https://conversation.sevarg.net

Die Zustellbarkeit von E-Mails ist kompliziert. Hier sind einige wichtige Dinge, die Sie zuerst prüfen sollten:

Ich habe gerade eine Lösung demonstriert, aber ich weiß nicht, wie ich dies upstream einreichen soll.

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

Sie müssen den folgenden Abschnitt finden:

    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
    }

Ändern Sie die Domain-Zeilen.

    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
    }

Ich weiß nicht, welche davon wichtig ist, aber das Ändern beider hat das Problem gelöst. Verwenden Sie natürlich Ihre eigene Domain…

Verlassen Sie die App-Umgebung.

./launcher restart app

Es sollte jetzt in der Lage sein, E-Mails zu senden.

Ich erwarte, dass dies bei jedem Upgrade verloren geht.

Allerdings sende und empfange ich nun wie erwartet E-Mails.

Entwickler? Plz2fix?

19

Basierend auf dem von mir gemeldeten Fehler, bitte versuchen Sie Folgendes:

Fügen Sie

DISCOURSE_SMTP_DOMAIN: [Ihre Installationsdomain]

in Ihre app.yml-Datei ein (/var/discourse/containers/app.yml, höchstwahrscheinlich).

Rebuilden Sie dann die Anwendung (cd /var/discourse; ./launcher rebuild app) und versuchen Sie erneut, E-Mails zu versenden.

20

Nur zur Klarstellung: Ist DISCOURSE_SMTP_DOMAIN die Domain meines Discourse-Servers oder die Domain der E-Mail?

Mein Server befindet sich beispielsweise auf der Subdomain community.acescentral.com, und meine E-Mails kommen von admin@acescentral.com. Ist DISCOURSE_SMTP_DOMAIN also die oberste Domain acescentral.com oder die Subdomain community?

Vielen Dank, dass Sie so beharrlich bei der Aufklärung dieses Problems waren.